THE DATABASE I CHOSE WHEN EVERYONE ELSE CHOSE POSTGRES

The database decision should be driven by the shape of your data and the constraints of your domain, not by what the tooling defaults to. Most of the time both point at Postgres. Sometimes they do not.

The problem is a graph, not a retrieval task

Pivot AI analyses matrimonial financial disclosure for UK family law firms — the documents in which both parties declare assets, income and liabilities. It sounds like a retrieval problem. It is not. The data does not sit in rows; it sits in a web of competing claims, conflicting valuations and typed relationships between entities across adversarial documents.

These cases are built on contradiction. One party declares an asset; the other disputes its valuation. A pension is valued differently depending on methodology. A business interest appears in one document and is absent from another. The analytical task is the detection and classification of those conflicts. That structure is a graph, and forcing it into relations means fighting the data model every day.

The constraints arrive before the first line of code

Most database comparisons are written from a standing start: greenfield application, team with choices. Regulated work does not offer that. The firms using the platform are SRA-regulated, and their clients' complete financial histories are among the most sensitive personal data that exists. In a multi-tenant platform on top of that data, isolation stops being a feature and becomes a legal obligation.

Row-level security implements multi-tenancy as a policy layer on a shared engine. It works and it is well understood. But it makes isolation a rule applied to a shared system rather than a structural property of the architecture. In a regulated context, "we have a policy that prevents access" is a weaker guarantee than "the data physically cannot be reached from another tenant's context." A namespace-per-firm model gives you the harder boundary — enforced in the engine, not on top of it.

The multi-model argument

The standard comparison also misses the operational cost of extensions. A vector extension is very good software, but adding it means another thing to operate, version and reason about — before you account for the semantic search layer, the graph layer and the document store all pointing at different systems with different consistency models.

The platform needs three things from its primary store: a graph for ontological relationships and conflict-detection edges, a vector index for semantic similarity over document content, and document storage for structured extraction output. In a relational architecture those are three systems, three connection pools, three failure modes. In a single ACID-compliant multi-model engine they are one query — a material reduction in what can go wrong.

The honest trade-off

The Postgres consensus exists for good reasons. Every AI coding tool writes it fluently; the training data is saturated with it. Every framework assumes it. Every new hire knows it. The ecosystem is vast and mature.

For this specific problem — graph-native conflict detection, structural multi-tenancy in a regulated context, multi-model queries without extension juggling — the architectural fit is worth that cost. For a conventional SaaS application with a relational data model, the answer would be Postgres with everyone else.

Adapted from "The database I chose when everyone else chose Postgres" by Jonathan Aiken, first published in Nodes & Edges, 20 April 2026.