Browser ↔ edge sync
Synchronizing an in-browser PGLite database with a Silos edge database — an evolving capability, framed honestly.
The natural next step after running Postgres in the browser is syncing that
local data with a Silos edge database — so an app can work locally and offline, then
reconcile with the server. Silos references a sync package, @silos/pglite-sync, for
this purpose.
Browser-to-edge sync is an evolving capability, not a finished, production-proven feature. The direction is real and the package exists, but treat sync as preview: validate it for your use case rather than assuming robust, conflict-free, two-way synchronization today.
The intended shape
The local-first pattern Silos is building toward:
- An app holds a working PGLite database in the browser, persisted locally (see Persistence).
- A sync layer (
@silos/pglite-sync) keeps that local database in step with a Silos edge database, pulling server changes and pushing local ones. - Reads can be served from the local copy for instant, offline-capable UX, with the edge database as the shared source of truth.
What to keep in mind
- Maturity. Sync is evolving. Don't build a workflow that assumes guaranteed, loss-free, bidirectional sync until you've validated it end to end.
- Conflict handling. Any two-way sync has to resolve concurrent edits. Understand how conflicts are handled for your data before relying on it.
- Engine versions. The browser engine is PGLite (PostgreSQL 16-based) and the edge engine is PostgreSQL 18. They're both real Postgres, but keep the version difference in mind for version-specific behavior. See PGLite overview.
A safer pattern today
If you need browser Postgres now but don't want to depend on preview sync:
- Use PGLite locally for prototyping, offline scratch work, and the SQL editor.
- Treat the Silos edge database as the authoritative store and read/write it directly over the wire protocol or HTTP for shared, durable data.
- Adopt browser↔edge sync once it meets your reliability bar.