Core concepts

These five pages are the mental model. Read them in order — each builds on the last, and together they cover everything a fresh reader (human or AI) tends to get wrong.

1. The two paths — read and write are separate and asymmetric.
2. The write path — stage locally, flush a batch, apply in the database.
3. The read path — shapes stream Postgres → the Circuits engine → durable-streams → the local store, granted by a control plane and gated at the edge.
4. Timestamps — microsecond integers carried as decimal strings.
5. Local schema & DDL parity — what the local store does and does not replicate.

Once you have the model, the Registry entry options page is the field-by-field reference for configuring a sync table — every option, with a short example, what it achieves, and when to use it. And Worker mode covers the browser topology in which tabs attach through a SharedWorker and capability placement chooses a Safari SW-direct or elected Chromium/Firefox engine (defineSyncWorker / attachSyncClient) instead of the calling thread. Postgres builds explains the compiled Postgres the local store runs on, why a store belongs to the build that created it, and what each build refusal means.

Not everything is sync state. The event lane is the second lane beside the sync rail, for high-volume append-only facts that nothing ever reads back down: appendEvent into a local Outbox, flushed to an ingestion endpoint, delivered through a queue to a consumer callback you write.

The canonical vocabulary for all of these lives in the repository’s CONTEXT.md.