Almost every UK startup building a web product ends up weighing the same two options. Both databases are mature, both are free to use, and both will comfortably outlive the first version of your app. The real question is which one leaves a small team with less work: less tuning, fewer late-night surprises, and no awkward conversations with your hosting provider. That answer depends far more on your stack, your team and where you deploy than on any benchmark you'll read online.
Start With What Your Stack Already Wants
If you're running WordPress, WooCommerce or most PHP content platforms, the decision has effectively been made for you. They expect MySQL or its fork, MariaDB. Fighting that is not clever, and there's no prize for doing so.
Django is the clearest counter-example. Its most complete feature set targets PostgreSQL, and some capabilities simply aren't available elsewhere. Laravel and Rails support both engines well, though the surrounding ecosystem leans towards MySQL for PHP hosting and PostgreSQL for product teams. Node projects using Prisma, Drizzle or Knex can go either way.
There's a practical point hiding here. If your team has five years of MySQL experience and you're building a straightforward CRUD application, productivity beats theory. Pick the engine you already understand, keep your schema portable, and revisit the question when you have data that justifies it.
Performance: Fewer Surprises Beats Raw Speed
There is no single winner. Benchmark results shift depending on the query, the schema, the indexes and the hardware underneath. What matters is which engine behaves predictably for the workload you actually have.
Where each one tends to shine
MySQL with InnoDB stores rows in a clustered index ordered by primary key, which makes simple lookups by ID extremely quick. It handles high volumes of short transactions well, and replica setup is well-trodden ground. PostgreSQL is stronger on complex joins, aggregations and window functions, and its type system goes further: JSONB with real indexing, arrays, ranges, and extensions such as PostGIS for geography, pgvector for embeddings and pg_trgm for fuzzy search.
The unglamorous differences
PostgreSQL forks a process per connection, so memory use climbs with connection count and you'll want a pooler such as PgBouncer earlier than you might expect — particularly if you deploy to serverless functions that open connections casually. It also writes new row versions on update, which means autovacuum is not optional. Neglect it and tables bloat, plans degrade and the database looks slower than it is.
MySQL uses threads, which is lighter for many idle connections, and its JSON type is a binary document format with a narrower set of indexing options than JSONB. Neither difference usually decides the argument. A well-indexed schema on either engine will handle more traffic than your first year of customers will generate.
Hosting Costs: What You Actually Pay For
Both run comfortably on a small virtual private server with a couple of gigabytes of RAM for an early-stage product. The bill grows through the details: storage, provisioned IOPS, backup retention, read replicas, network egress and — often overlooked — per-IO or per-request billing on serverless plans. A plan that charges per input/output operation looks cheap until a missing index turns every page load into a full table scan. Index first, then blame the database.
Managed options cover both engines: AWS RDS and Aurora, Google Cloud SQL, Azure Database and DigitalOcean, plus newer serverless platforms. Compare backup, restore and point-in-time recovery rather than the headline compute figure, because that's what you'll care about on the worst day of your year. PostgreSQL's per-connection memory can mean paying for a pooler separately, while MySQL's smaller footprint is why cheap shared hosts default to it.
Choose your region deliberately. London regions — AWS eu-west-2, Azure UK South, Google Cloud europe-west2 — reduce latency for UK users and keep data close to home. If you handle personal data, take advice on residency and your UK GDPR obligations; hosting in a UK region is often the simplest path.
Community, Docs and Hiring
MySQL has the larger installed base, endless tutorials and support from virtually every host. The catch is age: a lot of published advice targets MySQL 5.x and long-deprecated PHP APIs, so filter for versions that match your server. MariaDB is broadly compatible but not identical, and it's worth checking particular features before assuming.
PostgreSQL's official documentation is unusually clear, its mailing lists and community chat are active, and the extension ecosystem is a genuine advantage — you can add geospatial search or vector similarity without changing databases. The UK also has a healthy PostgreSQL meetup and conference scene, which helps when you need a second opinion.
On licensing: PostgreSQL uses a permissive BSD-style licence, while MySQL Community Edition is GPLv2 with commercial licences sold by Oracle. For a SaaS product this rarely matters, since you aren't distributing the database itself. If you plan to ship on-premise software or an appliance, speak to a solicitor before assuming.
A Decision Guide for Small UK Teams
Reach for MySQL or MariaDB when:
- You're building on WordPress, WooCommerce or a CMS that requires them.
- Your host only offers MySQL and you want managed hosting sorted this week.
- Your workload is simple, high-volume reads and writes by primary key.
- Your team knows it well and your product doesn't need unusual data types.
Reach for PostgreSQL when:Photo: panumas nikhomkhai / Pexels
