Rows
Convergent working state
Use rows for structured facts the app reads and changes locally: status, titles, notes, relationships, and file references.
- Local reads and writes
- Queued changes can travel later
- Every opened mesh is a full row replica
Architecture decision 02 · Data scope
Give each kind of data the promise it needs.
Rows are complete local working state that converges. Durable files are exact remote objects fetched on demand. Separate meshes bound replication, trust, and failure together. Model those distinctions before choosing tables or adapters.
- Decision
- Set database boundaries, offline expectations, and practical scale.
- Core boundary
- Opening a row mesh means holding its complete row database locally.
- Completion
- Classify rows, files, and meshes; measure representative snapshots.
Three placement decisions
Rows, files, and meshes solve different problems.
The most important topology choice is not the table shape. It is deciding which data must be available and convergent together, which bytes remain directly remote, and which readers may receive a complete local copy.
Files
Exact remote bytes
Use durable files for documents, media, and other objects whose bytes should not enter row merge or snapshots.
- Uploaded and fetched directly
- No core offline queue or file cache
- Overwrite and delete by application path
Meshes
Replication and trust boundaries
Split databases when groups of endpoints should receive different row sets, keys, lifecycles, or practical size limits.
- No selective table or row sync
- Application owns cross-mesh work
- Each mesh synchronizes independently
Availability map
Offline is a property of the chosen surface.
A local reference to a file can remain available in a row while the bytes still require the remote. Durable local row storage is also required if queued work must survive a process or browser restart.
Rows change locally
The local store owns current rows, receipts, cursors, and the outbox.
Work can wait
Row changes can remain pending until transport is available.
Clients converge
Trusted endpoints pull the same changes and apply the same merge rules.
Bytes need the remote
File upload, download, metadata, and deletion call storage directly.
Long-offline devices
Queued work has a publication horizon.
After the configured finite offline-retention window, a device rebuilds row state from the latest snapshot and quarantines its stale queued operations instead of publishing them automatically. Design review or reapplication for valuable disconnected work.
Practical scale
Size the complete copy, not only one request.
Every endpoint stores the complete row mesh, and compaction creates and uploads a complete snapshot. Device storage, memory, transfer time, provider limits, and snapshot size can all become the limiting factor.
- Build representative rows with realistic field lengths and sync metadata.
- Keep attachment bodies as durable files; rows hold references and useful metadata.
- Compact a representative database and measure the resulting snapshot.
- Leave growth room rather than treating a request limit as a target.
- Split meshes by who needs the data, lifecycle, and practical working-set size.
- Test reopen, catch-up, compaction, and long-offline recovery on target devices.
Canonical detail
Validate the topology against real limits.
Size a representative mesh, confirm which values belong in rows or durable files, then check compaction and Worker limits against the chosen deployment.