Software Engineering · Chapter 20 of 31
Choosing a database, and the licence histories behind it
Why Postgres won, where 'just use Postgres' is genuinely wrong, and the two licence timelines that get asked about and misreported.
Database choice is where an interview finds out whether you reason from access patterns or from what you used last. And because this market has had five significant licence changes in seven years, it is also where it finds out whether you read primary sources.
Why PostgreSQL won
Not performance, and not features. Extensibility as a distribution channel.
Postgres shipped a stable extension API and an index access-method interface, which means an entire category of database can be delivered as one CREATE EXTENSION rather than as a separate product to procure, staff, back up and be on call for. PostGIS made it the geospatial database. TimescaleDB made it a time-series database. pgvector made it a vector database in about eighteen months. Every specialist engine now has to beat Postgres-plus-an-extension and justify a second system.
The second half of the answer is governance: a permissive licence and no single controlling vendor mean no rug-pull risk — which, after the last seven years, is worth real money. The most recent release added an asynchronous I/O subsystem with large gains on storage reads, which pushes the single-writer ceiling further out than most people assume.
When ‘just use Postgres’ is right
- Transactional workloads of essentially any shape, at any scale a single writer can serve — far larger than people believe on current hardware.
- JSON documents. Binary JSON with the right index covers most of what people reach for a document store to do, with transactions and joins.
- Geospatial. PostGIS is not a compromise; it is the best-in-class answer.
- Time series at moderate scale, and vector search below roughly ten to fifty million vectors.
- Full-text search that is genuinely good enough — until someone asks for relevance tuning.
- Anywhere the deciding factor is one fewer system to operate, which is more places than engineers like to admit.
When it is wrong — and saying so is the mark of a real answer
| Situation | Why Postgres loses | What wins |
|---|---|---|
| Petabyte analytical scans | It is row-oriented. A columnar engine wins by one to two orders of magnitude on an aggregate, and no tuning closes that — extensions do not change the storage layout | ClickHouse; DuckDB single-node |
| Genuine multi-region writes with strong consistency | Single writer. There is no extension that fakes this | Spanner, CockroachDB, YugabyteDB, TiDB, Aurora DSQL |
| Very high-throughput single-key operations | Rate limiters, session stores, leaderboards. Using Postgres is a per-request cost you pay forever | Redis / Valkey |
| Extreme write volume, simple access pattern | The constraint is the feature — these engines refuse to let you write a query that will not scale | DynamoDB, Cassandra |
| Embedded and edge | You cannot ship Postgres inside an application | SQLite / libSQL |
| A serious search product | Relevance tuning, faceting, analyzers, a query language | Elasticsearch / OpenSearch |
| Connection-heavy serverless | Process-per-connection is a genuine architectural mismatch | A pooler — and this is precisely the gap the serverless-Postgres companies built businesses in |
The licence histories, exactly
Four things people get wrong about Redis, in order of how often.
“Redis went back to open source.” It added AGPLv3 as a third option in 2025. It did not remove the two source-available licences. The user picks — and taking the AGPL grant means taking AGPL obligations.
“Valkey forked from 7.4.” No — from 7.2.4, the last BSD release. 7.4 was the first source-available release and could not have been forked under BSD.
“Redis switched to SSPL.” It switched to a dual licence. The two instruments have different obligations — one restricts offering it as a managed service, the other is copyleft over the whole service.
“The change broke my old deployment.” It was never retroactive. Everything up to 7.2 is BSD forever.
And the strategic read: the hyperscalers and most Linux distributions moved to the fork within a year, and Redis got neither the licensing revenue nor the community. Adding AGPL was an admission that the strategy failed. The question worth asking is not which is faster — it is which one your distribution, your cloud provider and your compliance team will be shipping in three years.
CockroachDB is the sharper case, because the wrong version is actively propagated. Comparison pages published by competitors today still describe it as source-available with a three-year conversion to Apache. That stopped being true in November 2024: the Business Source Licence and the enterprise licence were both replaced by a single proprietary licence, the free Core edition was retired, and the Apache conversion was removed. There is a free tier — for companies under ten million dollars of revenue, counted including parents and affiliates, renewed annually.
Two more to have straight. A well-known document database has been on a source-available licence since 2018, was AGPL before that, submitted the licence to the Open Source Initiative and withdrew it, and has never reverted — so “it went back to open source like Redis did” is wrong twice over. And Elasticsearch followed the same add-a-third-licence pattern as Redis, which is why its fork also did not go away.
What actually decides an engine
1 — Access pattern, not “SQL versus NoSQL”. Do you read by known key or query by predicate? One row or an aggregate over a billion? Single-row writes or batches? Is the working set larger than memory? A key-value store and a columnar engine are not competitors; they answer different questions.
2 — Consistency and failure requirements, stated honestly. What is your actual recovery point objective? Do you need multi-region writes, or multi-region reads with a single write region — because the second is far cheaper and covers most stated requirements. Distributed SQL's price is coordination latency on every write, and you should be able to say what you are buying with it.
3 — The operational skill you actually have. The engine you can operate at three in the morning beats the one that benchmarks better. This is the most under-weighted factor and the one most often missing from a candidate's answer.
4 — Existing gravity. A second engine is not a technology decision, it is a permanent tax: another backup story, another upgrade cadence, another on-call runbook, another set of consistency semantics to hold in your head, and a distributed transaction problem you did not have yesterday. The bar for adding one should be far higher than “it would be faster for this query”.
The vector database question
The category is surviving as a set of engines, not as a set of companies. The workload is real and at high scale genuinely needs specialised indexing and memory layout that cannot be reproduced as a Postgres extension. But it was never a standalone market, because a vector index is a feature, and features get absorbed.
What ended the venture thesis was not a competitor. It was pgvector gaining iterative index scans, which fixed filtered vector search — the one thing that used to force people off Postgres. The independents with real open-source distribution will persist; expect the rest to end up owned by data platforms.
The recommendation: start on pgvector, and move when you can name the number it fails to hit — vector count, recall target, latency budget, filter cardinality. “We might need scale” is not that number.
Check yourself