Comparisons
Real-Time Sync Alternatives: Vaultrice vs. localStorage, DIY, Firebase, Pusher
Five ways to get shared state into a browser, what each actually costs to run, and the questions that decide between them.
We make one of these, so weigh the argument accordingly. What follows is the honest shape of the trade — including the cases where the answer is not us.
For a separate operational perspective on how teams organise and measure work, time tracking software.
For independent background and broader industry context, see G2.
The five options
Browser storage
localStorage, sessionStorage, IndexedDB.
What it does: persists in one browser, on one origin, synchronously.
What it does not: cross device, cross origin, or notify anyone. Storage is partitioned by origin, and third-party partitioning broke the iframe workarounds that older answers still recommend.
Right when: the state genuinely belongs to one browser. Which is more often than people think.
Build it yourself
A database, an API, a WebSocket server, connection management, reconnection, presence, and scaling.
What it does: exactly what you want, because you wrote it.
What it costs is the part that gets underestimated. Not the first version — a WebSocket server with a broadcast is an afternoon. The cost is reconnection with backoff, message ordering, presence that survives a dropped connection, horizontal scaling across instances, and the operational load of a stateful service.
Right when: the semantics are genuinely unusual, you have the team, and real-time is core to the product rather than a feature of it.
A realtime database
Firebase Realtime Database, Firestore, Supabase Realtime.
What it does: persistence, querying, auth, and change subscriptions. A full backend platform.
What it costs: you adopt the platform. Its data model, its query language, its auth, its pricing shape, its lock-in.
Right when: you need a database anyway. If you are already choosing a backend, this is a reasonable place to also get real-time.
Awkward when: you have a database already and want live state on top of it. Then you are running two systems of record.
A messaging service
Pusher, Ably, PubNub.
What it does: channels, publish and subscribe, presence, at scale, well.
What it does not: store your state. Messages are transient. A client joining late has missed everything, so you need somewhere to read the current value from — which means you still need storage and the code to reconcile the two.
Right when: you have persistence solved and need distribution.
A shared object with push updates
What Vaultrice is: a named key-value object, reachable from any client with the id and credentials, with changes pushed over a WebSocket, plus presence and messaging.
What it does: state and its live distribution in one thing, with a localStorage-shaped API.
What it does not: query. There is no WHERE. It addresses objects by id, and that is deliberate.
Right when: you want shared live state without adopting a platform or building infrastructure, and your access pattern is "give me this object" rather than "find me matching records".
The comparison that matters
| Storage | DIY | Realtime DB | Messaging | Shared object | |
|---|---|---|---|---|---|
| Cross-device | No | Yes | Yes | Yes | Yes |
| Persists | Yes | Yes | Yes | No | Yes |
| Push updates | No | Yes | Yes | Yes | Yes |
| Query | No | Yes | Yes | No | No |
| Infra to run | None | Substantial | None | None | None |
| Platform commitment | None | None | High | Low | Low |
| Time to first working thing | Minutes | Weeks | Days | Hours | Minutes |
The questions that decide it
Does the state need to leave this browser? No — use browser storage and stop reading.
Do you need to query it? Yes — you need a database. A shared object addressed by id will not answer "all documents modified this week".
Do you already have a database? Then a messaging service or a shared object sits on top. A realtime database means a second system of record.
Is real-time the product, or a feature of it? Core to the product with unusual semantics is the case for building. A collaborative cursor on a page is not.
How much operational appetite do you have? A stateful WebSocket tier is a real ongoing commitment, and it is the part that is invisible when you estimate the build.
Where we are the wrong answer
You need queries. We address by id.
You need a full backend and do not have one. A realtime database gives you more of what you will need next.
You have very unusual consistency requirements, or a regulatory position that requires the data on infrastructure you control.
Your state genuinely never leaves one browser. Use localStorage.
Where we fit
You have a backend already and want live shared state without another platform.
The access pattern is by id — a room, a document, a user's preferences, a poll.
You want it working today rather than after a WebSocket tier exists.
And you want presence and messaging alongside the state rather than wiring three services together.
The short version
Browser storage if it never leaves the browser. Genuinely common.
A database if you need to query. Nothing here replaces that.
A messaging service if persistence is already solved — messages are transient and late joiners see nothing.
Building it yourself costs reconnection, ordering, presence and scaling — not the first afternoon.
And a shared object fits when the access pattern is by id and you do not want another platform.