Persistence
Keep your in-browser PGLite database across page reloads using IndexedDB or OPFS.
By default, a PGLite database in the browser lives in memory and disappears when the tab closes. To keep data across reloads — for local-first apps or a SQL editor session you want to return to — PGLite can persist to browser storage.
Storage backends
PGLite supports persisting to standard browser storage APIs:
IndexedDB
Widely supported browser database storage. A good default for persisting a PGLite database across sessions.
OPFS
The Origin Private File System — a more file-like, higher-performance option where the browser supports it.
In-memory
The default. Fast and ephemeral — nothing is kept after the tab closes. Ideal for throwaway experiments.
Choosing a backend
- In-memory — for quick experiments and the default SQL editor experience where you don't need to keep anything.
- IndexedDB — for broad compatibility when you want the database to survive reloads.
- OPFS — for better performance and a file-like model in browsers that support it.
Availability and performance of IndexedDB and OPFS vary by browser and platform. Treat OPFS as the faster option where supported and IndexedDB as the broadly compatible fallback.
What persistence does and doesn't do
- Does: keep your tables and rows in the browser across reloads, so a local-first app can hold working data on the device.
- Doesn't: by itself, sync that data to a Silos edge database or to other devices. Browser storage is local to that browser. To move data between the browser and an edge database, see Sync.
Persistence vs. a deployed database
In-browser persistence is for the client-side PGLite engine. It's independent from a deployed Silos database, whose durable state lives as snapshots and WAL in object storage (see Snapshots & WAL). The two only come together when you explicitly sync — covered next.