04 Data & storage
PostgreSQL
Thirty years of not losing anybody's data, under a licence nobody can revoke.
- Role
- Relational database
- Licence
- PostgreSQL Licence
- Since
- 1996
- Upstream
- Project site ↗
Almost everything we build keeps its durable state in PostgreSQL: Redmine, Nextcloud, every Rails application, and the reporting that sits on top of them.
Why we still choose it
It is the most boring correct choice available, and correctness is all a database is for. It has three decades of development behind it, a development group that answers to nobody’s quarterly targets, and a permissive licence that cannot be withdrawn or repriced.
Over the years it has also taken over most of the jobs people used to run a
second system for. JSONB covers the document workloads that once needed
MongoDB, and full-text search covers much of what people reach for
Elasticsearch to do. With range types, exclusion constraints, materialised
views, logical replication and window functions, the work stays in one place,
with one backup, one restore procedure and one thing to patch.
For an organisation trying to reduce the number of moving parts, that consolidation is worth more than any single feature.
How we run it
On NixOS, declared in your repository alongside everything else.
services.postgresqlBackup writes nightly dumps, which we restore-test monthly
and send you the evidence for. Tuning is written down instead of passed on by
word of mouth, and we add connection pooling when the numbers call for it, not
by default.
On versions
Production runs the current stable release, PostgreSQL 18 at the time of writing, and we track the next major version through its beta cycle so that upgrades are planned in advance. PostgreSQL 19 is in beta as this page is published, and we are testing against it. It will hold client data once it has been released and has had a point release, and not before.
We do this as a matter of policy. With a database, adopting second costs almost nothing and adopting first can cost everything.
Where it falls short
PostgreSQL will not save you from a bad schema, and it is the wrong choice for
very large analytical workloads or for data that fits poorly into relations. It
also rewards someone who knows how to operate it: VACUUM, connection limits
and index maintenance are real responsibilities, and part of what you are
paying us for.