Even if MySQL Became the Default Again, It Would Still Lose

In a companion piece, we argued that PostgreSQL is winning not because developers chose it, but because their toolchains chose it for them. The platforms that define the modern developer experience (Supabase, Neon, Render, Railway, Lovable) ship PostgreSQL as the default, and default adoption accounts for a significant share of PostgreSQL's growth from 33% to 49% between 2018 and 2024.^[1]

When that piece was shared on LinkedIn, some readers pushed back: PostgreSQL actually is technically superior. And maybe it is. But here is what matters more from an operational and strategic perspective: even if MySQL somehow reclaimed the default position tomorrow, it would likely still lose. PostgreSQL has two structural advantages that MySQL cannot easily replicate, and neither of them is a feature that ships in a release.

The first advantage: extensibility as architecture

PostgreSQL's extension system, built around CREATE EXTENSION, allows third parties to register custom data types, operators, index access methods, background workers, and foreign data wrappers at the schema level. Extensions become first-class citizens of the database's own type system. They participate in the query planner, they benefit from the transaction model, and they can be installed and upgraded independently of core PostgreSQL releases.^[2]

This architectural decision, made decades ago, turned PostgreSQL from a database into a platform. The extensions that exist today are not add-ons sitting beside the database. They are subsystems running inside it.

What extensibility has produced

The absence column is the point. MySQL has plugins, but the plugin architecture is designed primarily for storage engines and authentication. Plugins cannot add new index types, cannot introduce custom data types at the query planner level, and cannot extend the database's type system. MySQL 8+ introduced a "Component" architecture to overcome some plugin limitations, but it still does not approach the depth of PostgreSQL's extension model.^[3]

You cannot build a TimescaleDB for MySQL. You cannot build a pgvector for MySQL. The architectural hooks simply do not exist. This is not a feature gap that closes with a release. It is a design decision baked into the codebase at a level that would require a fundamental rewrite to change.

Or at least, that has been the conventional wisdom. VillageSQL, an open-source tracking fork of MySQL that launched in early 2026 with $35M in Series A funding, is attempting to close exactly this gap. VillageSQL introduces a new extension framework (VEF) designed to bring PostgreSQL-style extensibility to MySQL, including support for custom data types, custom functions, and vector indexing for AI workloads. Because it is a drop-in replacement for MySQL, existing applications can adopt it without code changes.^[16] Percona, VillageSQL, and other members of the MySQL community have been active in the push for a more transparent, foundation-style governance model, including co-signing an open letter to Oracle alongside over 500 other signatories.^[17]

It is early days, and VillageSQL's extension ecosystem is nascent compared to PostgreSQL's decades of accumulated extensions and community investment. But it represents a serious acknowledgement that MySQL's extensibility gap is real, and that the MySQL community recognises it as an existential problem worth forking to solve. Whether VEF can attract the kind of third-party ecosystem that makes PostgreSQL's extension model powerful (rather than just architecturally possible) remains the open question. As we covered in detail in our MySQL performance guide, VillageSQL is the most significant structural response the MySQL ecosystem has produced to date.

pgvector and the AI inflection point

The extension that best illustrates why this architecture matters right now is pgvector. It enables LLM applications to store and query vector embeddings directly in PostgreSQL, which means a team building a chatbot, a recommendation engine, or a semantic search feature can run the entire data layer in a single database rather than maintaining PostgreSQL for relational data and a separate vector database (Pinecone, Weaviate, Qdrant) for embeddings.^[4]

The adoption numbers reflect this architectural simplification. Vendor reports indicate that pgvector adoption has grown by hundreds of percent since 2023.^[5] A significant share of new Supabase signups are AI builders using pgvector for chatbots, copilots, recommendation systems, and semantic search.^[6] AWS Aurora PostgreSQL supports pgvector with significantly faster embedding loads through parallelism.^[4] pgvector's 0.8.0 release delivered major performance improvements with binary quantisation reducing memory footprint while maintaining high accuracy.^[6]

Many organisations running pgvector alongside their relational data report significantly lower total cost of ownership compared to dedicated vector databases for moderate-scale datasets.^[6] The cost advantage comes from eliminating a separate infrastructure layer: one database to manage, one backup strategy, one set of connection pools, one monitoring stack.

A MySQL-based AI stack requires that separate vector database. That means additional infrastructure, additional operational overhead, a fragmented data model, and the consistency challenges that come with synchronising data across two systems. This is not a temporary gap. Without an extension architecture capable of supporting something like pgvector, it is a permanent structural disadvantage.

The second advantage: governance without an owner

PostgreSQL is governed by the PostgreSQL Global Development Group, a meritocratic community structure with no single corporate owner. The Core Team serves as the central policy arbiter, with an unwritten (and increasingly formalised) rule that no more than 50% of its members should come from a single company. The Contributors Committee curates recognition, and the hackers mailing list remains the primary technical decision-making forum.^[7][8][9]

This distributed model has a practical consequence: no vendor can stall PostgreSQL, delay features for competitive reasons, restrict capabilities to an enterprise edition, or let the project stagnate when corporate priorities shift. The roadmap serves users, not a parent company's quarterly earnings.

MySQL's copyrights belong entirely to Oracle. Oracle decides what merges, what stays proprietary, and where engineering resources go. The GPL protects your right to run MySQL. It does not protect MySQL from its owner's indifference.

The open letter and Oracle's refusal

In February 2026, a consortium of 544+ developers, architects, DBAs, and contributors signed an open letter demanding that Oracle transition MySQL to a foundation governance model. The signatories included Percona co-founder Vadim Tkachenko. Their complaints were specific: MySQL development happens behind closed doors through private code drops with limited visibility into the roadmap; MySQL updates are sparse and do not include features now standard in comparable databases; and declining market share is attributed directly to the closed development model.^[10][11]

In March 2026, Oracle formally refused to restructure control of MySQL. They promised more transparency and offered to roll previously commercial-only features into the community edition, but the governance model remains unchanged: Oracle owns the copyrights, Oracle controls the roadmap, Oracle decides what ships.^[12]

Repository analysis from December 2025 showed declining commit velocity in the MySQL codebase, lending quantitative weight to the community's concerns about stagnation.^[13]

MariaDB exists as a true fork with independent governance, and it represents the strongest counter-argument to the MySQL governance problem. But MariaDB is still fighting for mindshare against the Oracle brand and the MySQL name, and its extension architecture inherits the same fundamental limitations as MySQL's. Independent governance solves one of the two structural problems, but not both.

Why these advantages are structural, not incremental

The distinction matters because structural advantages compound in ways that feature advantages do not. A feature gap can be closed in a release cycle. MySQL could ship a better JSON implementation, a faster replication protocol, or improved partitioning tomorrow. But MySQL cannot retrofit an extension architecture that would allow the community to build a pgvector-equivalent without rewriting the storage and type system layers. And Oracle has demonstrated, as recently as March 2026, that it will not voluntarily surrender governance control.

These are not gaps that narrow over time. They are moats that widen. Each new PostgreSQL extension (and there are hundreds, with new ones arriving regularly) increases the distance between what PostgreSQL can become and what MySQL is structurally limited to. Each year that PostgreSQL operates under community governance while MySQL operates under Oracle's control increases the divergence in community trust, contributor investment, and long-term strategic confidence.

What this means for teams running MySQL

If you are running MySQL in production today, this analysis is not an argument to drop everything and migrate. MySQL at scale is well understood, and the operational tooling around it is mature. The migration trend is real and accelerating, but migration has its own costs and risks, and for many workloads MySQL remains a reasonable choice.^[14][15]

What it is, however, is an argument to be honest about the strategic trajectory. If your AI roadmap includes embeddings, vector search, or retrieval-augmented generation, you will need to evaluate whether MySQL's lack of a pgvector equivalent creates a meaningful architectural constraint. If your organisation values open governance and community-driven development, you should understand that Oracle has explicitly refused to provide that for MySQL. And if you are making a net-new database decision today, you should recognise that the structural dynamics favour PostgreSQL in ways that go beyond feature comparison.

For database reliability engineers and platform teams, the operational implication is worth considering regardless of which database you run. A PostgreSQL fleet that grew through default adoption carries different observability and tuning requirements than one that was architecturally evaluated. And a MySQL fleet operating under Oracle's governance model carries strategic risks that a cost-of-incidents analysis alone will not capture.

Defaults got PostgreSQL here. Structure keeps it here.

The story the industry tells about PostgreSQL's rise focuses on developer preference and technical superiority. The real mechanism is default adoption through toolchains. But the reason the outcome is durable, even if the defaults were to reverse, is that PostgreSQL has accumulated two advantages that MySQL cannot easily match: an extension architecture that lets the database adapt to new workloads (including AI) without waiting for core development, and a governance model that ensures no single company can capture, stall, or abandon the project.

Defaults are powerful but fragile. Structure is what lasts.