The default we reach for and the one our platform runs in production, including row-level security for keeping one customer’s data away from another’s.
It's free, it's boring, and it does more than most teams realise.
Real constraints and foreign keys, enforced by the database, so broken relationships can't quietly accumulate.
Tenant separation enforced in the database itself rather than remembered in every query. Our own multi-tenancy relies on it.
JSON, full-text search and geographic data in the same database, which removes whole extra services.
Open source with no licence, available managed on every cloud, so you're never locked to one host.
Our platform runs on PostgreSQL in production, including multi-tenant isolation enforced by the database itself rather than by application code.
Usually for the features, the cost, or both. It's well-trodden work and the data is the easy part; the queries are where the attention goes.
Indexes, query plans and schema, in that order. Most systems described as needing more servers need one index.
The schema decides how expensive every future change is. It's worth the time at the start and almost impossible to fix cheaply later.
Written down, rehearsed, and timed, so you know what an incident actually costs you.
Written for someone deciding, not for someone who already knows. Skip it if you do.
An open-source relational database, thirty years old, with no company owning it and no licence to buy. It has quietly become the default choice for new systems, and the reason is that it refuses to lose your data in ways other databases historically did not.
Correctness first: it enforces the rules you declare rather than silently accepting nonsense, which means a whole class of bad data never gets in. Then breadth — JSON, full-text search, geographic data and row-level security are all built in, which removes several extra systems from a typical architecture.
The database itself can enforce that one customer never sees another's rows, rather than trusting every query in the application to remember. On a platform hosting many businesses that's the difference between an isolation bug being impossible and being one forgotten WHERE clause away.
Connections are relatively expensive, so a busy application needs a pooler in front of it. And it doesn't tune itself: the defaults are conservative, and a database nobody has ever configured is usually leaving a lot of performance unused.
Nearly always a missing index or a query that scans a whole table. Findable in an afternoon with the database's own tools.
PostgreSQL supports each major for five years. Past that there are no security fixes, and major upgrades are routine when done on schedule.
Then your recovery time is unknown, which means your risk is unknown. One rehearsal turns both into numbers.
We default to PostgreSQL for stricter data integrity and better handling of complex queries and JSON. MySQL is fine, and we won't move you off it without a reason.
Yes. Migrations are rehearsed on a copy and verified by row counts and sampling before anything switches over.
Automated backups plus point-in-time recovery, and a restore we have actually performed and timed. An untested backup isn't a backup.
PostgreSQL for anything new, in our view: stricter about data integrity and considerably more capable. MySQL isn't a mistake, and if you're on it and content there's no urgency to move.
Almost certainly. Well-tuned PostgreSQL handles far more than most businesses ever produce, and the limit is usually the schema and the queries rather than the database.
A few lines are enough to start. You get a reply within two working days.
