One Postgres, no PostGIS: why the whole platform runs on one database
Ledger, events, embeddings, simulations, queue, geo cache — one pool, one migration story.
Most platforms accumulate databases. A team adds Redis for caching, Elasticsearch for search, a separate Postgres for the geo layer, and a queue database for jobs. DEINO runs on one Postgres — a Timescale pg17 image that bundles pgvector — for everything. Not because one database is cool, because one database is one migration story and one operational surface.
The whole platform runs on one Postgres instance. The Ledger is there. The events are there. The embeddings are there (pgvector, bundled in the Timescale image). The simulations and their scenarios are there. The jobs and whisper delivery queue is there. The World Monitor geo cache is there. One pool, one migration story, one set of operational skills. That is not a limitation; it is a decision, and the decision is load-bearing.
Why one, not many
Every database you add is a database you operate, back up, monitor, upgrade, and migrate. It is also a database whose data has to stay consistent with the others, which means distributed transactions or eventual consistency, and both are more complex than either is sold as. One database removes the consistency problem — everything is in one transaction — and concentrates the operational problem, which is easier to solve once than to solve across N stores. The trade is single-store scaling limits for multi-store coordination cost, and at POC scale the coordination cost is the larger one.
Every database you add is a database you operate, back up, upgrade, and reconcile. One database is one migration story — and the migration story is the operational risk.
- Ledger, events, embeddings, simulations, queue, geo cache — one pool, one transaction.
- Timescale pg17 bundles pgvector — time-series and vector search in one image, not two.
- One migration story — every .up.sql has a .down.sql, one tool, one history.
Timescale + pgvector, bundled
The image is Timescale pg17, which bundles pgvector. That gives time-series capability (Timescale) and vector similarity search (pgvector) in one database, without running two. The Ledger is time-series-shaped (events over time); the embeddings are vector-shaped (similarity search over node representations). One image, both capabilities. Running two databases — a time-series store and a vector store — would split the data and add the coordination cost. Bundling them in one image keeps the data co-located and the transaction boundary intact.
No PostGIS — and why
The World Monitor routes on geohash prefixes, computed in deino-core::geo, not on PostGIS. That is a deliberate non-dependency. PostGIS is a powerful extension, but it is also an extension that ties geo logic to the database layer — which is the layer DEINO keeps behind a port. Routing in deino-core keeps the geo logic in the pure domain, where it is testable without a database and where the type system governs it. The database stores the geohash; the domain computes with it. That is the hexagonal rule applied to geo: the logic is in the core, the storage is behind the port.
What this costs, and what it buys
The cost of one database is a scaling ceiling — a single Postgres instance has limits, and a platform that grows past them has to shard or split. The payoff at POC scale is that the operational surface is one thing: one backup, one migration tool, one set of schemas, one transaction boundary. The day we outgrow one instance is the day we have a problem worth having — it means the POC earned the scale. Until then, one database is the honest answer to how many operational surfaces a pre-revenue platform should own. We are building the POC; one Postgres is built, and the migration story is one story.
One database is a decision, not a limitation. The limitation is single-store scaling; the decision is that the coordination cost of many stores is the larger risk, and the migration story is the operational risk you only want to own once.
— database design note