← Capabilities

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.

Web collection
Server loadHydrationSSEIndexedDBSync
Server rows become a live browser collection without another first fetch.

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.