New capability
Hydrate once, then stay current
SvelteKit can render server data immediately, seed the same rows into browser collections, and keep them live without a duplicate loading pass.
Hydration is a handoff, not another fetch
Generated web collections are seeded from SvelteKit load data with a manifest hash and dependency key. The client can render immediately, preserve type information, and invalidate along normal SvelteKit conventions.
Live reads have a durable spine
Server writes append to _smrt_changes and emit an _events SSE stream. The browser subscriber resumes from a cursor, falls back to polling, and invalidates affected collections and relationships.
- ETags avoid unchanged response bodies.
- Manifest hashes isolate incompatible persisted data.
- updateAvailable tells the app when code and stored client data disagree.
Offline writes replay safely
The IndexedDB outbox coordinates across tabs with Web Locks and replays through the same idempotent sync-apply endpoint used by mobile. Conflict semantics and last-write-wins rules are explicit at the server boundary.
ORM hydration still matters too
On the server, normal list() calls hydrate database rows into the correct STI subclass with inherited fields and relationships. Use list({ select }) when you intentionally want plain projected rows and no object construction.