In February 2026, nearly 200 developers, companies, and community leaders published an open letter to Oracle Corporation with a simple but urgent message: the world's most widely deployed open source database is at risk, and something has to change.
The letter, spearheaded by Percona and published after two MySQL Community Summits held in San Francisco and Brussels, represents the most coordinated community pushback against Oracle's stewardship of MySQL in the sixteen years since the acquisition. It arrived against a backdrop of team layoffs, months of stalled GitHub commits, and PostgreSQL steadily eating MySQL's market share.
At CODERCOPS, we work with databases daily across client projects spanning startups and enterprises. This situation is not abstract for us. It affects real technology decisions that our teams and clients have to make right now. Let us walk through what happened, why it matters, and what you should do about it.
The MySQL community is at a crossroads — and the outcome will shape the database landscape for years to come
A Timeline of MySQL Under Oracle
To understand the current crisis, we need to look at how MySQL got here. The history of MySQL under Oracle is a story of gradual disengagement that finally reached a tipping point.
| Year | Event |
|---|---|
| 1995 | MySQL 1.0 released by Michael "Monty" Widenius and David Axmark |
| 2008 | Sun Microsystems acquires MySQL AB for $1 billion |
| 2010 | Oracle acquires Sun Microsystems (and MySQL) for $7.4 billion |
| 2012 | Monty Widenius forks MySQL to create MariaDB |
| 2018 | MySQL 8.0 released with major architectural improvements |
| 2023 | MySQL 8.1 marks shift to Innovation Release model |
| 2024 | MySQL 9.0 Innovation Release; community concerns grow about pace |
| Sep 2025 | Oracle conducts widespread layoffs across the MySQL engineering team |
| Sep 2025 | GitHub commits to the MySQL Server repository stop entirely |
| Oct 2025 | MySQL 8.0 end-of-life looms with limited migration guidance |
| Jan 2026 | MySQL Community Summit in San Francisco convenes |
| Jan 2026 | DevClass reports: "Open source MySQL repository has no commits in more than three months" |
| Feb 2026 | MySQL Community Summit in Brussels |
| Feb 11, 2026 | Oracle publishes "A New Era of Community Engagement for MySQL" response |
| Feb 17, 2026 | The open letter is published, signed by nearly 200 community members |
The pattern is clear. Oracle has progressively reduced its investment in MySQL's open source edition while concentrating innovation in its commercial HeatWave product.
What the Open Letter Actually Says
The open letter, hosted by Percona and signed by developers, DBAs, and companies from across the MySQL ecosystem, makes several concrete criticisms and proposals.
The Core Complaints
1. Lack of transparency. The community has no visibility into MySQL's roadmap, release decisions, or engineering priorities. Development happens behind closed doors, and external contributors have limited ability to participate.
2. Resource starvation. The September 2025 layoffs reportedly affected 60 to 70 percent of the MySQL engineering team. Monty Widenius himself posted that he was "heartbroken" about the cuts but "not surprised" given Oracle's trajectory.
3. Stalled open source development. The MySQL Server GitHub repository went months without a single commit after the layoffs. While Oracle eventually pushed new releases (9.6.0, 8.4.8, 8.0.45), the gap shattered confidence.
4. Missing modern features. MySQL lacks built-in vector search capabilities in the Community Edition — a feature that has become essential for AI-powered applications. Oracle reserves this for HeatWave, its commercial offering.
5. Aging contributor base. New developers overwhelmingly choose PostgreSQL. The MySQL community is getting older without sufficient new contributors joining.
The Proposed Solution: A MySQL Foundation
The letter proposes creating a neutral, non-profit foundation to govern MySQL's future. Two governance models are on the table:
Model 1 — Centralized Governance (Oracle-Led): Oracle leads the foundation similar to the OpenELA model, retaining strategic control while distributing operational maintenance across industry partners.
Model 2 — Collaborative Partnership: Oracle joins as a strategic partner and board member, but the industry establishes and manages the consortium. A technical steering committee would represent Oracle, fork providers, cloud vendors, and the broader contributor community.
The foundation would oversee roadmap planning, release governance, and contributor access. Oracle would retain its commercial MySQL offerings and trademarks.
Oracle's Response
Oracle preempted the letter by six days with a blog post titled "A New Era of Community Engagement for MySQL," published on February 11, 2026. Under SVP Jason Wilcox, Oracle announced a three-pillar strategy:
- Innovation in the Community Edition — promising more features in the open source release
- Expansion of the developer community — new programs for contributor engagement
- Increased transparency — better communication about roadmap and priorities
The community response has been cautiously skeptical. Oracle has made similar promises before, and the gap between corporate statements and engineering investment has widened over time.
Why This Matters Beyond MySQL
This is not just a database dispute. It is a litmus test for how corporate stewardship of open source projects works — or fails.
Database choices ripple through every layer of your technology stack
The Corporate Open Source Paradox
When a company acquires an open source project, a fundamental tension emerges. The company needs to generate revenue, which means differentiating commercial offerings. But the open source project needs investment, which means the free edition must remain competitive.
Oracle's approach with MySQL mirrors patterns we have seen elsewhere:
- Redis Labs relicensed Redis modules under non-open-source terms
- MongoDB switched to the Server Side Public License (SSPL)
- Elastic moved Elasticsearch away from Apache 2.0
- HashiCorp abandoned the Mozilla Public License for BSL
MySQL's GPL v2 license makes a license change extremely difficult given the distributed copyright ownership. But Oracle can starve the Community Edition of features, which is effectively what the community is alleging.
The Broader Stakes
MySQL still runs an enormous portion of the internet. WordPress alone — which powers roughly 40% of all websites — defaults to MySQL. Legacy enterprise systems, SaaS applications, and countless web platforms depend on it. A governance failure does not just affect database enthusiasts; it affects the entire web.
The Rise of the Alternatives
The MySQL governance crisis has accelerated migration trends that were already underway. Let us examine the competitive landscape.
PostgreSQL: The New Default
PostgreSQL's ascent has been decisive. In the 2025 Stack Overflow Developer Survey, PostgreSQL reached 55.6% adoption among developers — up from 48.7% in 2024 — opening a 15 percentage point gap over MySQL at 40.5%. Among professional developers specifically, PostgreSQL hits 58.2%.
PostgreSQL won the DB-Engines Database of the Year award again, marking its third consecutive year as the most admired and most desired database.
What makes PostgreSQL's position so strong:
- Extensibility: pgvector for AI, PostGIS for geospatial, TimescaleDB for time series, Apache AGE for graph
- Standards compliance: Closest implementation of the SQL standard
- Community governance: Independent, foundation-backed, no single corporate owner
- Cloud ecosystem: Neon, Supabase, CockroachDB, AlloyDB, and Aurora all speak Postgres protocol
- Performance: PostgreSQL 18 introduces async I/O for 2-3x improvement in sequential scans
A Comprehensive Comparison of Database Alternatives
Here is how the major MySQL alternatives stack up in 2026:
| Feature | MySQL 9.x | PostgreSQL 18 | MariaDB 11.x | PlanetScale | Neon | Supabase |
|---|---|---|---|---|---|---|
| License | GPL v2 | PostgreSQL (MIT-like) | GPL v2 + BSL (some) | Commercial | Commercial (Postgres) | Apache 2.0 (Postgres) |
| Governance | Oracle | Community Foundation | MariaDB Foundation | Startup | Startup | Startup |
| Vector Search | HeatWave only (paid) | pgvector (free) | Limited | No | pgvector (free) | pgvector (free) |
| Branching | No | No (native) | No | Yes | Yes | Yes (via branches) |
| Serverless | No | No (native) | No | Yes | Yes | Yes |
| JSON Support | Good | Excellent (JSONB) | Good | Good | Excellent | Excellent |
| Extensions | Limited | Excellent | Limited | Limited | Good | Good |
| Replication | Good | Good | Excellent (Galera) | Excellent (Vitess) | Good | Good |
| Free Tier | Self-hosted | Self-hosted | Self-hosted | Limited | Yes | Yes |
| AI/ML Integration | HeatWave (paid) | pgvector + pgml | Limited | No | pgvector | pgvector + Edge Functions |
| Best For | Legacy apps, WordPress | New projects, modern apps | MySQL compatibility | MySQL at scale | Serverless Postgres | Full-stack apps |
MariaDB: The Original Fork
MariaDB was born from the original MySQL governance concern when Monty Widenius forked the project after the Oracle acquisition. It maintains wire-level compatibility with MySQL while adding features like Galera Cluster for multi-master replication and ColumnStore for analytics.
However, MariaDB has had its own challenges. The company went through financial difficulties, and some Enterprise features moved to the Business Source License (BSL). It remains a viable MySQL drop-in replacement, but it has not captured the momentum that PostgreSQL has.
PlanetScale: MySQL at Scale
PlanetScale, built on Vitess (the MySQL scaling layer developed at YouTube), offers managed MySQL with database branching, non-blocking schema changes, and horizontal scaling. In a notable move, PlanetScale recently added PostgreSQL support — a tacit acknowledgment of market direction.
PlanetScale is excellent for teams that need MySQL compatibility at scale but want modern developer experience. However, removing their free tier pushed many developers toward alternatives.
Neon: Serverless Postgres
Neon represents the new generation of database platforms — serverless PostgreSQL with branching, autoscaling, and a generous free tier. It separates storage and compute, enabling instant database branching for development and CI/CD workflows.
Supabase: The Full-Stack Platform
We use Supabase ourselves at CODERCOPS, and it exemplifies the modern database platform approach. Built on PostgreSQL, it bundles authentication, real-time subscriptions, storage, and edge functions alongside the database. For most web applications, it provides everything you need in one platform.
The Technical Case for Migration
If you are considering moving away from MySQL, here are the practical realities.
What Migrates Cleanly
- Basic CRUD operations and simple queries
- Standard SQL joins and aggregations
- Most ORM-based applications (Prisma, TypeORM, Sequelize all support Postgres)
- REST API backends
What Requires Careful Handling
- MySQL-specific syntax:
REPLACE INTO,INSERT ... ON DUPLICATE KEY UPDATE, backtick quoting - Auto-increment behavior: PostgreSQL uses
SERIALorGENERATED ALWAYS AS IDENTITY - Date handling: MySQL's loose date validation vs PostgreSQL's strict mode
- Group By behavior: MySQL's non-standard
GROUP BYextensions - Stored procedures: Syntax differs significantly between MySQL and PL/pgSQL
- Character set handling: MySQL's
utf8is actuallyutf8mb3; PostgreSQL'sUTF8is real UTF-8
Migration Tools and Approaches
| Tool | Purpose | Notes |
|---|---|---|
| pgLoader | Direct MySQL to PostgreSQL migration | Handles schema conversion, data types |
| AWS DMS | Database Migration Service | Supports ongoing replication during cutover |
| Prisma | ORM-level migration | Change provider in schema, regenerate |
| pg_chameleon | Replica-based migration | MySQL to Postgres replication |
| Manual | Schema-first approach | Most control, most effort |
The "Stay on MySQL" Case
Not every project should migrate. Valid reasons to remain on MySQL include:
- WordPress or LAMP-stack applications where MySQL is deeply integrated
- Legacy enterprise systems where the migration cost outweighs the benefit
- High write-throughput workloads where MySQL still has an edge at extreme scale
- Existing expertise where your team knows MySQL deeply and PostgreSQL learning curve is a cost
- Regulated environments where database changes require extensive compliance review
What Oracle Should Do
We do not think Oracle is acting in bad faith — we think it is acting in rational corporate self-interest that happens to conflict with the open source community's needs. Here is what a constructive path forward looks like:
1. Engage with the Foundation Proposal
The community is not asking Oracle to give up MySQL. They are asking for shared governance. The Linux Foundation, Apache Software Foundation, and CNCF all demonstrate that corporate participation and community governance can coexist. Oracle retaining commercial MySQL offerings while a foundation governs the Community Edition is a model that works for everyone.
2. Restore Engineering Investment
The September 2025 layoffs decimated the team. Oracle needs to either rehire or empower the foundation to attract contributors. The months-long commit gap was devastating to confidence.
3. Vector Search in Community Edition
Locking vector search behind HeatWave while PostgreSQL offers pgvector for free is accelerating migration. AI-powered applications are the growth segment, and MySQL is excluded from it at the community level.
4. Transparent Roadmap
Publish a public roadmap. Accept community RFC proposals. Let the ecosystem plan around MySQL's direction instead of guessing.
What Developers Should Do Right Now
The open source community's strength lies in collective action and informed choices
Based on our experience working with clients across various industries, here is our practical guidance:
For New Projects
Default to PostgreSQL. The ecosystem, governance, cloud availability, and feature set all favor it. Use Supabase or Neon if you want a managed platform. Use raw PostgreSQL on your cloud provider if you want maximum control.
For Existing MySQL Projects
Do not panic-migrate. MySQL is not going to disappear overnight. It is GPL-licensed, and the source code cannot be un-open-sourced. Evaluate your situation:
- Audit your MySQL dependency depth. How much MySQL-specific SQL do you use? How tightly coupled is your ORM?
- Test PostgreSQL compatibility. Set up a read replica with pgLoader and see what breaks.
- Evaluate Percona Server. If staying on MySQL, Percona provides better tooling and community alignment.
- Plan, do not rush. Set a 6-12 month evaluation timeline.
For Technical Leaders
- Watch the March 2026 deadline. The foundation governance decision will signal MySQL's trajectory.
- Factor governance risk into database decisions. Single-vendor control is a risk vector, same as single-cloud dependency.
- Invest in database abstraction. ORMs and query builders that support multiple backends reduce lock-in.
- Upskill your team on PostgreSQL. Even if you do not migrate, PostgreSQL literacy is increasingly essential.
For the MySQL Community
Sign the open letter. Support the foundation proposal. Attend community events. Contribute to MariaDB or Percona if you want to invest in MySQL-compatible open source. The community's voice is strongest when it is united.
Our Prediction
We believe the most likely outcome is a compromise. Oracle will increase transparency and restore some Community Edition investment without fully embracing the foundation model. The community will continue to fragment — some teams migrating to PostgreSQL, others adopting Percona or MariaDB, and the rest staying on Oracle's MySQL with a closer eye on governance.
The real winner of this episode is PostgreSQL. Every week that MySQL's governance remains uncertain, another team makes the switch. PostgreSQL's adoption crossed 55% for a reason — it is not just a better technical choice, it is a safer institutional bet.
The database landscape in 2026 is consolidating around one truth: governance matters as much as features. A database you cannot trust to be maintained is a database you cannot trust with your data.
Let Us Help You Navigate This
At CODERCOPS, we have guided multiple clients through database migration projects — from MySQL to PostgreSQL, from self-hosted to managed platforms like Supabase and Neon, and from monolithic databases to purpose-built architectures.
Whether you need a migration assessment, a proof-of-concept PostgreSQL deployment, or help optimizing your current MySQL setup, our database engineering team can help.
Get in touch with us to discuss your database strategy. We will help you make the right call — not the reactive one.
Comments