Tomas Ulin Reflects on VillageSQL: From the MySQL Core to Permissionless Innovation

Abstract purple image of a tunnel
Photo by Kamran Abdullayev / Unsplash

As a key figure in MySQL’s history, Tomas Ulin has a unique perspective. He lived through some of the most dynamic eras of the database's history from the inside. Now, as a member of the VillageSQL team, he hopes to put permissionless innovation in the hands of MySQL developers and the MySQL community so MySQL can find a path forward in the agentic AI era.

Photo of Tomas Ulin
Tomas Ulin

Long before he ran MySQL engineering globally for Oracle, he worked on early computer vision and virtual reality avatars in the 90s. In 2003, he was managing a telecom database project—a highly available, low-latency, in-memory distributed system built for usage tracking and billing—for a Swedish telecom provider. MySQL AB, an independent entity at the time, acquired that project, bringing Tomas along with it. That telecom database eventually evolved into MySQL's NDB Cluster CGE (Carrier Grade Edition), which today powers massive, high-throughput systems for gaming customers and global telecom networks, among others.

The mid-2000s were eventful for the MySQL team. In 2005, Oracle bought InnoDB, MySQL's main storage engine. By 2008, Sun Microsystems had acquired MySQL. Soon after, Oracle acquired Sun. Tomas found himself sitting in a room in Redwood Shores being tapped to run MySQL development globally. He eventually grew the engineering organization to 300+ people.

Meanwhile, MySQL/Oracle’s relationship with the open-source community began to splinter. MySQL lore points to a few key events that caused this fracturing. First, Oracle locked down the public bug database in the name of meeting internal security guidelines. Oracle also stripped down the developer-focused MySQL conference and folded it into executive-heavy Oracle OpenWorld.

The Problem with the Monolith

The biggest challenge Tomas faced came directly from navigating the tension between core database stability and the community demand for fast-paced innovation. The MySQL core is notoriously intricate and historically non-modular and not extensible. Adding new features onto the core can trigger unpredictable side effects.

This structural bottleneck created a 'one-way contribution street.' Current releases were locked down for stability, keeping new ideas stuck in the future and making the community feel sidelined:

  • Upstreaming challenges: Tech giants like Facebook, Google, and Twitter developed sophisticated patches to handle their massive, hyperscale workloads. The core MySQL/Oracle team usually had to reject upstreaming them because those patches were optimized for specific cases and didn’t align with the official roadmap.
  • The maintenance burden: Merging thousands of lines of community code would have strapped a permanent maintenance debt onto the core engineering team. Every future feature or bug fix would have to account for that code, a responsibility the team could not take on.
  • Stability vs. innovation misalignment: Balancing a corporate roadmap focused on long-term stability with the fast-paced innovation needs of the community proved challenging within a monolithic codebase. The net result was a mismatch between community expectations and actual execution.

This situation meant MySQL community members either had to wait years for an official release to support their exact use case, or maintain a custom fork of the database and hope they could handle the merge conflicts when the next major version dropped. MySQL is incredible at scaling, but innovating within its codebase remains difficult.

A Platform for "Permissionless Innovation"

Tomas sees VillageSQL’s approach as the mechanism to break the gridlock. The extension framework is the engine for "permissionless innovation."

VillageSQL treats the database as a programmable platform, not as a static storage layer. By locking down a stable core interface and pushing new capabilities to the edges, developers can finally build what they need independently.

For example, the community wants to tap into the binlog for deep logical replication or event-driven alerting directly from the database. Developers want to wire localized LLMs straight into their queries. With a proper framework, developers can just write an extension that hooks into specific execution points without the developer touching the core engine. Extensions can even provide services to other extensions. The original author or team of authors owns the maintenance, not VillageSQL or even the MySQL core team. The core database stays clean, fast, and completely stable for everyone else who ignores those specific features.

Drop-in Replacement via the Tracking Fork

Tomas spent his career navigating the tension between core database stability and the community's relentless demand for features. The ecosystem has plenty of forks. What he sees as the path forward for MySQL innovation is a unified extension framework that runs cleanly across various distributions.

One of the most critical aspects of this is the "tracking fork" strategy. Rather than creating a permanent hard fork, VillageSQL focuses on maintaining compatibility while providing a path for innovation. This allows existing MySQL-based applications to add new functionality without a complete architectural overhaul or migration. MySQL developers get the tools to push MySQL forward on their own terms, restoring a vibrant ecosystem where innovation doesn't require permission from a central authority.

Ultimately, Tomas believes VillageSQL is the path forward because it transforms MySQL from a restricted monolith into a platform for permissionless innovation. By decoupling new features from the core through an extension framework, VillageSQL empowers the community to build the future of MySQL on its own terms.

Ready to start building? We’re building VillageSQL for the community. To start authoring extensions, fork the vsql-extension-template. It provides the C++17 scaffold, CMake configurations, and VEF headers needed to build a binary-compatible extension. Try building an extension and let us know how it goes. Tell us what you're building by sending us a note on Discord. We are compiling a list of community-built extensions and plan to publish a directory. If you find what we are doing interesting, please star the project on GitHub.

Read more