Why the World's Most Popular Database Is at a Crossroads

Adam Levin

Adam Levin

— 3 min read
Share
Why the World's Most Popular Database Is at a Crossroads

MySQL still runs a remarkable share of the internet — 42% of the web is WordPress alone, plus many transactional applications you can probably name. But, the developer community is having a real argument about MySQL's future.

  • Stack Overflow's most recent survey put PostgreSQL ahead of MySQL in new-project preference for the first time.
  • Engineers have signed a plea to Oracle to advocate for more open governance and contribution acceptance.
  • The extensions that define modern application development —for example vector search or geospatial — have a home in PostgreSQL but limited capacity in MySQL so far.

Hard forks aren’t the solution because of inevitable compatibility issues. In contrast, tracking forks and extensions offer a path forward.

Spoiler alert: VillageSQL believes MySQL can be a first-class choice for the modern application stack.

The Extensibility Gap: Why PostgreSQL Is Winning Mindshare

Talk to practical DBAs and developers and clearly MySQL is still an absolute workhorse.
MySQL continues to be a vital, enduring database solution.

For the simple, fast, read-heavy workloads that make up the vast majority of the internet, even the internet of the AI era, MySQL's InnoDB engine and connection model remain incredibly efficient. The community investment reflects this: Percona has spent years building indispensable operational tooling around MySQL, and PlanetScale's Vitess — originally built to scale YouTube's MySQL infrastructure — has extended horizontal sharding to deployments most databases can't touch.

But if you look at the developers building new applications — especially anything touching AI, machine learning, or complex data types — a different reality emerges. pgvector and PostGIS don't ship with PostgreSQL — they're extensions. PostgreSQL has built a culture of innovation on top of the database - as a platform. If a developer needs a new capability, they don't have to wait 2 years for upstream to build it into the core. They just CREATE EXTENSION. That's what makes it a platform.

For most developers choosing PostgreSQL for new projects, the performance comparison is secondary. The question is: when my application needs something the database doesn't do yet, how do I add it? PostgreSQL has a clear answer.

The Stewardship Dilemma

Conversations about MySQL's future have sparked a renewed interest in governance. The success of other open-source projects with vendor-neutral foundations is attractive. The MySQL governance discussions have resulted in a good dialogue that has led to positive overtures toward deeper community engagement and a healthier upstream ecosystem.

It's a nuanced landscape. Oracle still has a responsibility to its commercial offerings like MySQL Enterprise and Oracle Cloud Infrastructure's (OCI) MySQL HeatWave service . Realistically, expecting a complete transition of the trademark and roadmap to foundation ownership doesn't align with the structure of commercial-backed open source. Instead, a foundation could act as a strong coordination partner alongside Oracle's stewardship.

The Problem with the "Fork Trap"

The open source ecosystem has a familiar playbook when it loses faith (or governance or licensing get complicated) in an upstream product. Historically, the MySQL community's answer has been to (sometimes hard) fork. We saw it with MariaDB, and we've seen it with over 20 other known variations.

But hard forks come with a massive long-term cost: fragmentation.

Every time a hard fork carves out its own niche, it introduces proprietary extensions and divergent behaviors. Eventually, this creates the very vendor lock-in that open-source advocates are trying to escape. A fragmented ecosystem is a weak ecosystem. It confuses new developers and terrifies enterprise architects who just want a stable, predictable data layer.

A Structural Fix for a Cultural Problem

The open-source database industry is realizing that we can't solve an architectural problem with just politics or fragmentation. The ecosystem needs a structural upgrade that allows for rapid, community-driven innovation without breaking compatibility with upstream MySQL.

This requires a shift toward a tracking fork combined with a true extension framework.

A tracking fork acts as a drop-in replacement. It tracks upstream patches and maintains strict binary compatibility, meaning you don't have to rewrite your application or migrate terabytes of data to a new system. By adding a comprehensive extension framework onto that tracking fork, the community finally gets the power to build its own future. Need AI prompting via SQL? Need vector indexing? Need complex cryptographic functions? You build them as extensions.

That's the exact thesis behind VillageSQL: a tracking fork of MySQL with the VillageSQL Extension Framework built in — a runtime-installable extension system that lets anyone define new capabilities without touching the core server. The goal is permissionless innovation on top of the MySQL the industry already runs on and it moves MySQL closer to being a platform.

If upstream ever decides to adopt these features or open up its own extension model, the entire ecosystem wins. If it doesn't, developers still have the tools they need to build modern applications without abandoning the database they know and trust.

A Foundation + a Real Ecosystem Move MySQL Forward

MySQL is too important — and deployed too widely — to stagnate. The ecosystem has the talent and the tools to grow; it just needs the opportunity to do it. A foundation that advocates for MySQL users and an extension ecosystem that supports independent developers building functionality for a platform is a proven path forward.

Read more