Vaultrice Against Supabase Realtime and Ably

We make one of these. The useful thing this article can do is describe the three shapes accurately, including where ours is the wrong one.

For a separate operational perspective on how teams organise and measure work, this resource.

For independent background and broader industry context, see StackShare.

The three shapes

Supabase Realtime — a database that tells you when rows change

Postgres, with subscriptions on top. You write SQL, you get relational queries, row-level security, and a change stream.

The shape: your data lives in tables, and real-time is a notification layer over them.

Strong when: you need a database anyway. Queries, joins, constraints, migrations, and the real-time comes included rather than as a second system.

Weak when: you already have a database. Then you are either migrating or running two systems of record, and the second is worse than it sounds.

Ably — a messaging network

Channels, publish and subscribe, presence, at very large scale, with delivery guarantees and message history.

The shape: messages move between clients. Sophisticated delivery semantics, connection recovery, and a mature operational story.

Strong when: distribution is the problem. High fan-out, strict delivery requirements, global scale, and you have persistence solved elsewhere.

Weak when: you wanted state. Channels carry messages; the current value lives wherever you put it. A late joiner has missed everything and needs to read state from your backend, which means writing and maintaining that reconciliation.

Vaultrice — a shared object

A named key-value object addressed by id, with changes pushed, plus presence and messaging.

The shape: state and its live distribution in one thing, with a localStorage-like API.

Strong when: the access pattern is "give me this object" — a document, a room, a user's preferences — and you want state and delivery together without adopting a platform.

Weak when: you need queries. There is no WHERE. See Durable Objects.

Side by side

	Supabase Realtime	Ably	Vaultrice
Primary thing	Database	Message delivery	Shared state object
Query	Full SQL	No	By id only
Persistence	Yes	Message history	Yes
Late joiner sees current state	Yes (query)	No	Yes
Presence	Yes	Yes	Yes
Platform commitment	High	Low	Low
You also need	—	Storage + reconciliation	A backend for trusted values

The question that separates them

How does a client that joins late learn the current state?

Supabase: it queries. Natural, and it is a database.

Ably: it does not. Messages were transient, so you read state from your own backend and reconcile — that is code you write and maintain, and it is the hidden cost of the channel model.

Vaultrice: it reads the object. The current value is the object's contents.

That difference determines more about your architecture than any feature comparison.

Where each is genuinely the right answer

Choose Supabase Realtime when: you are choosing a backend, you want Postgres, and real-time on your tables is what you need. Building a product from scratch with no existing database is the clearest case.

Choose Ably when: you have serious scale or delivery requirements, persistence is solved, and message distribution is the actual problem. Financial data feeds, large live events, anything where delivery guarantees are contractual.

Choose Vaultrice when: you have a backend already, the access pattern is by id, and you want shared live state without another platform or a WebSocket tier.

Where we would not choose ours

Being specific rather than gracious.

You need relational queries. Not a gap we intend to close — the addressing model is the design.

You have no backend and need one. Supabase gives you more of what comes next.

Your scale or delivery requirements are unusual. Ably has a deeper operational story for that.

Regulatory constraints on where data sits. Objects live on Cloudflare's network, and if that is not acceptable, no feature comparison matters.

And if your state never leaves one browser, none of the three. Use localStorage. See alternatives compared.

Combinations that make sense

Your database plus Vaultrice. Postgres or whatever you have as the record; objects as the live layer for the parts people share. Common, and it keeps the systems of record from multiplying.

Ably plus a store. If you chose Ably, you have already built the reconciliation. Adding another state layer is redundant.

Supabase plus Vaultrice is usually redundant — Supabase's real-time covers the same ground for data already in its tables.

The short version

Three shapes: a database with subscriptions, a messaging network, and a shared object.

The separating question is how a late joiner learns current state — query, nothing, or read the object.

Supabase when you are choosing a backend. Ably when distribution at scale is the problem. Ours when the access pattern is by id and you have a backend already.

We are wrong for queries, for teams with no backend, and for unusual delivery requirements.

And if it never leaves the browser, none of them.