Concept
Where Ablo fits in a multi-agent system
Ablo Team7 min read
Your Postgres stays the system of record
Ablo is not a database you migrate to. It is the typed transaction and realtime layer on top of the Postgres you already run — so adopting it never means handing over your data.
Key takeaways
- In production, your own Postgres is the system of record; Ablo syncs a subset of models against it.
- Ablo adds typed model methods, realtime fanout, claims, and offline support on top — without owning your data.
- Realtime data is scoped to sync groups derived from your existing identity, so tenancy and auth stay yours.
- Adopt existing tables with pull/check, or let Ablo provision its own — either way your other tables are untouched.
A fair question about any sync engine is: where does my data actually live? With Ablo the answer is deliberately boring — in your Postgres, the same database that backs your auth, audit, and log tables. Ablo is the transaction layer on top, not a destination you migrate into. That choice shapes everything about how it is adopted.
A layer, not a destination
Ablo defines your data once with a schema and gives every actor — people, server actions, agents — the same typed model client. But the committed rows land in your Postgres. Ablo syncs a subset of your models; the rest of your tables are left exactly as they are. There is no lift-and-shift and no second source of truth to keep reconciled.
Tenancy from your own identity
Realtime fanout is scoped to sync groups derived from your existing identity and authorization — not a parallel permission system you have to mirror. The data a client sees live is the data your own auth already says it can see. Keep the database connection string inside your infrastructure, or expose a signed Data Source endpoint so it never leaves at all.
Adopt or provision
Most teams already have the tables — often Prisma- or Drizzle-managed — so Ablo adopts them with a pull/check step. Prefer Ablo to own its own tables? It can provision them in your Postgres. Either path leaves the rest of your schema untouched, which is what makes “in production, your database is the system of record” a literal description rather than a slogan.
Filed under Architecture
By Ablo Team
Frequently asked questions
Does adopting Ablo mean migrating my data to a new database?
No. In production your own Postgres remains the system of record. Ablo syncs a subset of your models against it and adds a transaction and realtime layer on top; every committed row lives in your database, and your other tables are left untouched.
Can I keep my database connection string off third-party infrastructure?
Yes. Keep the connection string inside your own trusted runtimes, or expose a signed Data Source endpoint and omit the database URL entirely, so the connection string never leaves your infrastructure.
The collaboration layer for humans and agents
Let people, server actions, and AI agents work on the same data without overwriting each other — on top of the Postgres you already have.