A UK SaaS team choosing a database usually ends up weighing the same two options, and both are defensible. PostgreSQL and MySQL are mature, well documented, and available as managed services in or near the UK. Either will happily serve your first thousand customers.
The differences start to bite later — when you have real tenants, a security questionnaire from a bank or an NHS trust, and a cloud bill you actually read every month. Here is what to weigh before you commit.
Start with the workload, not the logo
Both engines are relational, both speak SQL, both are fast enough for ordinary SaaS traffic. The split comes down to what else you want the database to do.
MySQL is a comfortable fit for read-heavy CRUD: accounts, subscriptions, invoices, dashboards. Its replication is straightforward, the tooling around it is mature, and if you ever need to shard, Vitess gives you a well-trodden path.
Postgres tends to win when you want one system doing several jobs. JSONB handles semi-structured payloads without a second document store. PostGIS covers location features. Full-text search and pgvector cover search and similarity. If the alternative is running three extra services, Postgres is often the cheaper and simpler decision — not because it is faster, but because you have fewer moving parts to patch, monitor and pay for.
How they scale in practice
For most SaaS products, scaling pain arrives long before the engine does. N+1 queries, missing indexes and unbounded tables will hurt you on either platform. Assuming your queries are sane, here is where the two diverge.
- Connections. Postgres uses a process per connection, so several hundred short-lived connections from serverless functions or edge workers can exhaust memory quickly. Budget for PgBouncer from early on. MySQL's thread model handles many idle connections more cheaply, though a proxy still helps for high availability.
- Replicas and failover. MySQL read replicas and managed failover are well understood. Postgres has streaming replication and logical replication for selective copying between versions or tenants, which is genuinely useful during migrations.
- Sharding. Neither ships with automatic sharding. MySQL teams usually reach for Vitess; Postgres teams reach for Citus or partition tables by tenant.
- Maintenance. Postgres needs attention to autovacuum and table bloat. MySQL's InnoDB is more forgiving by default but has its own pitfalls with large alterations.
Multi-tenancy is the deciding factor for many products
Postgres row-level security lets you enforce tenant isolation inside the database, so a bug in application code is less likely to leak another customer's rows. MySQL has no equivalent; you enforce tenancy in the application layer or split tenants across schemas or databases. That is workable, but it puts more weight on code review.
Compliance, UK GDPR and audit trails
No data protection regime names a database engine. What regulators and enterprise buyers care about is whether you can encrypt data in transit and at rest, control who can reach production, log access, and delete or export a person's records on request. Both engines can support all of that.
The practical differences sit in the fine detail. Postgres offers row-level security, granular role grants and the pgAudit extension for detailed logging. MySQL has roles and an audit plugin, with more of the mature audit tooling sitting behind commercial editions or community alternatives. If your buyers are regulated, expect questions about who can run SELECT against production and whether that is logged. Postgres tends to need less custom work to answer them.
Data residency deserves its own check. A UK region in the provider's menu is not the whole story — ask where backups, monitoring and support access sit, and whether anyone outside the UK can reach customer data. Transfer questions like that are best put to your solicitor or data protection lead; engineering guidance is not legal advice.
Hosting costs: the parts startups miss
For equivalent instance sizes, managed UK Postgres and managed MySQL land in a similar range. The invoice diverges elsewhere:
- Connection pooling. Postgres usually needs PgBouncer or a provider's built-in pooler, which may mean an extra small instance.
- Replica count. Read replicas are the biggest lever on your bill, and both engines need them for reporting or analytics traffic.
- Storage and IOPS. High-throughput workloads pay for provisioned performance on either platform.
- Extension savings. Postgres extensions can replace paid search, queue or geospatial services, which often outweighs a slightly larger database instance.
- Cross-availability-zone and egress traffic. Keep application servers and replicas in the same region.
Reserved capacity or committed-use discounts are worth taking once your instance size has been stable for a quarter.
Day-to-day development and hiring
Every mainstream framework — Django, Rails, Laravel, Prisma, TypeORM — supports both. Laravel has historically leaned MySQL; Django's documentation leans Postgres. Neither creates a hiring problem in the UK. Interview for query plans, indexing and migration discipline rather than engine trivia; a competent engineer moves between the two in a week.
One difference does affect your release process. Postgres supports transactional DDL, so a failed migration rolls back cleanly. MySQL's DDL is atomic per statement in version 8 but you cannot wrap a multi-step migration in a transaction and expect a clean rollback. Large table changes need online schema tools such as gh-ost or pt-online-schema-change. On Postgres, watch for locks and use CREATE INDEX CONCURRENTLY.
A quick decision checklist
- JSON documents, geospatial, search or vector similarity in the same database? Choose Postgres.
- Straightforward read-heavy CRUD and a team already fluent in MySQL? Stay with MySQL.
- Selling to regulated UK buyers and want isolation enforced at the database level? Postgres row-level security will save you work.
- Thousands of short-lived connections from serverless functions? Whatever you pick, add a connection pooler.
- A partner, acquirer or legacy system mandates one engine? Follow the constraint and revisit later.
Decide, document, then instrument
Write the choice down in a short decision record with the reasoning, and move on. The database is rarely what stalls a SaaS product; slow queries, runaway tenant growth and hand-rolled deployments are. In your first month, turn on slow query logging, set up connection pooling before you need it, add a tenant_id column to every table from day one, and rehearse a restore from backup so you know it works. Get those habits right and either engine will carry you a long way.
Photo: Christina Morillo / Pexels
