For most new systems, PostgreSQL is the default: a permissive licence, a long list of recent features and one predictable support clock. MySQL stays the right call when your stack or your team already assumes it, which means WordPress, many PHP applications and shops with existing MySQL operations skills. The bigger cost is the team and the upgrade cadence you sign up for, not raw speed.
If you're also weighing other parts of the stack, the series Hire developers by tech stack: rates, vetting and interview guides covers them one by one.
The short answer: which should a CTO pick?
These are judgments, not measurements. Match your situation to the nearest one.
Starting a new product with complex queries, JSON documents or vector search on the roadmap: pick PostgreSQL. You'll get the broader feature set without paying a licensing or tooling penalty later.
Running an existing MySQL estate on 8.0: don't panic-migrate, but don't stand still either. Oracle has already moved 8.0 to Sustaining Support, so you need a plan. Details are in the migration section below.
Building on WordPress or a PHP CMS: stay on MySQL. The platform, the plugins and the hosting market around it were built with MySQL in mind, and fighting that buys you nothing.
Shipping an embedded or on-prem product that customers install: read the licensing section before you choose, because the licence terms differ in ways that matter when you distribute.
Small team, nobody who has run a database before: pick a managed service for whichever engine you choose, and spend your attention on schema design and slow queries instead.
Where each stands in October 2026
Both projects are healthy. What differs is the shape of the support promise, and that decides how much upgrade work lands on your team.
PostgreSQL: one major a year, five years each
PostgreSQL's versioning policy gives every major release five years of support after its first release, with minor releases at least every three months. PostgreSQL 18 is the current major, first released on 25 September 2025, with 18.6 the current minor and a final release date of 14 November 2030.
The older majors have fixed end dates on the same page. PostgreSQL 17 ends on 8 November 2029, 16 on 9 November 2028 and 15 on 11 November 2027. PostgreSQL 14 loses support on 12 November 2026, a few weeks from now, and 13 has been unsupported since 13 November 2025. If you're on 14, that's your deadline. PostgreSQL 19 is in beta, and what PostgreSQL 19 changes before it reaches GA is worth a read if you plan to skip a version.
The project's PostgreSQL 18 announcement lists the headline features. An asynchronous I/O subsystem, which the project says gives gains of up to 3x in certain scenarios. Virtual generated columns, now the default. A built-in uuidv7() function. OAuth 2.0 authentication. Skip scan on multicolumn B-tree indexes.
MySQL: LTS releases and Innovation releases
MySQL runs two tracks. According to the MySQL release model documentation, LTS releases get 5 years of premier support plus 3 years of extended support, and features are added or removed only in the first LTS release (8.4.0, for example). Innovation releases are supported only until the next Innovation release, and behaviour changes are expected between them.
The 8.0 line is where teams get caught. Oracle's end-of-life notice says that as of 21 April 2026, MySQL 8.0 is covered under Oracle Sustaining Support, and it encourages users to upgrade to MySQL 8.4 LTS or 9.7 LTS. The 8.4 release notes show 8.4.12 as the latest, dated 18 August 2026. MySQL 9.7.0 shipped on 21 April 2026, and its release notes list 9.7.3 as the latest, also from 18 August.
Oracle's Lifetime Support Policy sets the calendar end dates for 8.4 and 9.7. Work from the 5-plus-3-year rule and confirm the exact dates with Oracle before you commit.
What the lifecycle means for your upgrade budget
PostgreSQL gives each major five years, so you can plan upgrades on a calendar you can read ahead.
MySQL gives you the same calm only if you stay on LTS. Run an Innovation release in production and you've signed up to upgrade whenever the next one lands. That's a fine choice for a team that likes to track the newest features and has the test coverage to do it, and a poor one for a team of three. Whichever engine you pick, put the end-of-support date in the calendar on day one. No sourced figure exists for what a major upgrade costs in hours or money, and anyone quoting one hasn't seen your schema.
Licensing: what do GPL and the PostgreSQL Licence mean for a product company?
PostgreSQL uses what its licence page calls a liberal Open Source licence, similar to the BSD or MIT licences. You can embed it in a product with very few strings attached.
MySQL's server is available under GPLv2. Oracle's OEM licensing page says OEMs, ISVs and VARs that embed MySQL in commercial applications and don't want to be subject to the GPL should buy a commercial licence. Whether your use falls under that is a question for counsel.
Feature differences that change the design
Most comparison pages cover the classic differences, and we won't rehash them. Check the official PostgreSQL and MySQL documentation for how each engine handles JSON, materialized views, transactional DDL and locking, because those details change between versions and a blog post is the wrong place to learn them.
What we can source is what PostgreSQL 18 added, listed above. In our view, skip scan on multicolumn indexes and virtual generated columns are the kind of feature that changes schema design rather than just speed. Vector search is the other design-level question for new systems. PostgreSQL has the pgvector extension, which its project describes as open-source vector similarity search for Postgres, and if you want to see what that looks like in practice, there's a retrieval service built on Postgres and pgvector in our tutorials. MySQL 9.7's manual documents a VECTOR data type of up to 16,383 single-precision float entries; check whether your edition and version support it.
Is PostgreSQL faster than MySQL?
Sometimes, and sometimes not, and no published number will tell you which for your system. Most performance figures on the pages ranking for this query are vendor-asserted or unsourced: percentage ranges with no method behind them, or numbers from a cloud vendor's own managed product. Even the PostgreSQL project's "up to 3x" claim for async I/O is limited to certain scenarios.
Performance depends on your queries, your indexes, your hardware and how well the schema fits the engine. The rule is simple: take your ten slowest real queries and your realistic data volume, run them on both engines, and decide on that. If you can't spare a day for it, performance isn't what will separate the two for you.
Comparison table
| Criterion | PostgreSQL | MySQL |
|---|---|---|
| Current version (Oct 2026) | 18 (18.6 current minor) | 8.4 LTS (8.4.12) and 9.7 LTS (9.7.3) |
| Support model | One major a year, 5 years each | LTS: 5 years premier plus 3 extended. Innovation: until the next one |
| Older versions | 14 ends 12 Nov 2026, 13 already unsupported | 8.0 in Sustaining Support since 21 Apr 2026 |
| Licence | PostgreSQL Licence, similar to BSD or MIT | GPLv2, commercial licence from Oracle for embedding |
| Extensive work in past year, professional devs (Stack Overflow 2025) | 58.2% | 39.6% |
| Extensive work in past year, all respondents (Stack Overflow 2025) | 55.6% | 40.5% |
The team that runs it: who do you need, and does experience transfer?
Core SQL transfers between engines. A developer who writes good joins and understands indexes on MySQL will be productive on PostgreSQL's SQL quickly. What doesn't transfer is the operating knowledge: locking behaviour, replication setup, backup tooling, upgrade procedures and the quirks of the ORM configuration. That's a judgment, and it's why a new MySQL hire is rarely a new PostgreSQL DBA overnight.
Managed services shift some of the work but not all of it. Managed services typically handle patching and failover; check what your provider's service covers. You're still responsible for schema design, slow queries, access control and, above all, major version upgrades, which a managed service will schedule but won't make painless.
On the size of the pool, Stack Overflow's 2025 developer survey shows PostgreSQL was the database environment most professional developers had done extensive development work in over the past year (58.2%), against 39.6% for MySQL (21,126 responses). Among all 26,083 respondents it's 55.6% and 40.5%. Read those carefully. They show what developers say they worked in, not who's available to hire in your city or at what seniority. The survey is self-selected. It's good evidence that PostgreSQL experience is common, and weak evidence about time to hire, for which we have no source.
If you're defining the role itself, our guide on how to tell an SQL developer from a DBA and test either covers the role definitions and screening. If your stack is PHP, it's also worth reading about vetting PHP and Laravel engineers, since that's where MySQL experience usually sits.
Migrating from MySQL 8.0: stay on MySQL or move to PostgreSQL?
The move of 8.0 to Sustaining Support is a natural decision point. Moving 8.0 to 8.4 LTS or 9.7 LTS keeps your SQL dialect, types, tooling and replication setup largely familiar. Moving to PostgreSQL means all of these change: the SQL dialect, data types, driver and ORM configuration, replication and backup tooling, and the monitoring your on-call engineers know by heart.
Our view: if nothing is pushing you off MySQL, such as a feature you need, a licensing concern or a team that already prefers PostgreSQL, take the LTS upgrade. If something is pushing you, the move of 8.0 to Sustaining Support is a good moment to move, because you're likely to do migration work anyway. We haven't found a sourced figure for migration effort in hours or money, so run a spike on one real service before you commit the whole estate.
FAQ
Is PostgreSQL better than MySQL?
For most new systems, it's the better default: a permissive licence, a single predictable support policy and a broad feature set. MySQL is the better choice when your platform, such as WordPress, or your team's skills already point to it. On speed, test your own queries.
Is MySQL 8.0 still supported?
Only under Oracle Sustaining Support. Oracle's notice says that as of 21 April 2026 MySQL 8.0 is covered by it, and encourages users to upgrade to MySQL 8.4 LTS or 9.7 LTS. Plan the upgrade now.
Is MySQL free for commercial use?
MySQL's server is available under GPLv2. Oracle says OEMs, ISVs and VARs that embed MySQL in commercial applications and don't want to be subject to the GPL should buy a commercial licence. Whether your use falls under that is a question for counsel.
Can a MySQL developer work on PostgreSQL?
Yes, usually after a short ramp-up. SQL fundamentals carry over. Expect the friction in operations: locking, replication, backup tooling and upgrade procedures. No source puts a number on how long the ramp-up takes.
Which is more popular with developers?
PostgreSQL, in Stack Overflow's 2025 survey: 58.2% of professional developers reported extensive development work in it over the past year, against 39.6% for MySQL. That's global self-reported data, not a measure of hiring availability.