In May we hosted the first MySQL Contributor Summit 2026. We arrange such Summits every quarter, and it’s a forum where contributors come together and make proposals, and then discuss them, on what they wish to work on, or see someone else work on, in future MySQL versions.
All of the presentations are now published as well, so you can follow the discussion even if you weren’t at the summit yourself.
Proposed features were categorized into 4 work streams, and you can now find each of them on the MySQL Community Roadmap project board on GitHub.
Why is this important?
Nurturing an active contributor community is an important factor in the success of the MySQL open-source project. There are many ways and reasons you can contribute to MySQL:
- To avoid having to maintain a patch, which fixes some problem you had with MySQL
- To increase your career market value and professional development
- To get feedback and users for your ideas and projects, as MySQL is the most wide-spread open source database
Regardless of your reasons, MySQL thrives off of your contributions. With your contributions:
- Bugs get fixed faster and more efficiently,
- Users can gain custom features that were requested by users, but that would never have been developed if the only option was to wait for the MySQL engineering team at Oracle to do it,
- MySQL can be a platform that helps you and your ideas reach and collaborate directly with a much larger user community
- Can grow a larger base of developers, who over time grow into senior MySQL or database developers
Where can you participate?
To follow what’s happening , or better yet, if you want to participate in the planning and development of the next version of MySQL , the best place to start is MySQL Community GitHub Discussions . These GitHub discussion threads are the central point for discussions related to actually writing code that goes into MySQL Server. But the discussion is not just about code, rather also including technical topics, proposals, roadmap feedback, and contribution process related questions.
The MySQL Community Slack is a popular space for general community discussions and engagement. In other words, this is a good place for general discussions related to using MySQL as your database.
Depending on your intended level of involvement, you should also sign up for a centralized Oracle user account, which gives you access to the discussion forums, the MySQL bug database, and other MySQL services. We keep maintaining the good old bugs database, and it will remain relevant but we will use GitHub issues for new development of features.
And last but not least, more static information is found on the MySQL Community project’s Wiki. Here you can find the new MySQL Governance Model, the Developer Guide, The developer guide takes you through the whole process of submitting a Feature Request or Proposal, and all the way to a Pull Request.
Early Access releases and Monthly Code Drops
As reported on June 25, we now have a documented governance process, that is based on the assumption that there will be contributors, committers and project leads from various employers, and hopefully also some participating as their individual self.
We have made two Early Access releases, 9.7.0 Early Access and 26.7.0 Early Access. Work is already underway to match those releases with a monthly code drop. This is of course essential for anyone who wants to work on some code contribution, to have a relatively recent snapshot of the MySQL source. A lot of work is also going into setting up all the workflow automation into the mysql-server github repository.
Only when all of that is done, and operating somewhat smoothly, is it time for the open development of the MySQL development work to happen working live in the public mysql-server repo. This is scheduled to happen later this year in Phase 3 of the Community Engagement Plan. But for now we are already in good shape to receive pull requests from the MySQL community as part of Phase 2!
From talks to action!
So what is actually happening on the development frontier, now that we know where to look? Let me give you a quick summary of where each of those work streams are, at this moment in time.
But first…MySQL 26.7. is out, and we are excited to report that the first improvement arising out of the May Contributor Summit, (Bug #119222 ) is already merged and will be part of the 26.7. release. The patch is a performance improvement for how MySQL returns data back to mysqlsh after a mysqlsh util.dumpInstance() call. In case of composite primary keys, it now uses all the primary key columns to break the result set into a smoother, more evenly distributed sequence of chunks.
The authors of this first patch to make it into a release, are Sveta Smirnova and Kamil Holubicki from Percona!
Percona – as most readers will know – have over the years already contributed many bug fixes and features to MySQL Server. So it is perhaps no surprise that they were quick to do one also in this new era of community contributions!
Thank you Percona! And we hope to see many more contributions, small and large, as we continue to develop new versions of MySQL, together and in the open.
AI and Cloud
Most of the focus here is on bringing full featured vector indexes, distance functions and search, to MySQL. There were several alternatives on the table in the past months, that have been discussed back and forth. So far there seems to be consensus on the direction that this should be implemented natively, as a builtin index type that is a first class citizen both as far as extending the SQL syntax and parser, and the query optimizer are concerned.
The design phase is still ongoing, and the team is looking into different vector index structures and algorithms in the field. In addition the the widely used HNSW (Hierarchical Navigable Small World) algorithm, there’s considerable interest in an algorithm developed at Google and known as ScaNN (Scalable Nearest Neighbor). Following the syntax design discussion, it also is looking increasingly likely that the team is thinking of supporting multiple different index types.
Notably there also exists a project by Alkin Teyzusal called MyVector, that is implemented as a MySQL Plugin and User Defined Function. We’ll take a closer look at both of these vector indexing algorithms and implementations in the next blog post.
With vector support clearly leading the way as a high priority work item, there’s also a second projectin this category: Official MCP Server for MySQL.
This will allow various LLM based assistants and coding agents to access and explore MySQL in a standard way. The first version will be “read-only” in the sense that it is focused on exposing metrics for observability and on the other hand allowing the AI agents to discover the schema and query the data.
Performance and Observability
Performance improvements remain a constant topic of interest in the MySQL user community. As we have met with many of you both individually and at events like the contributor summit, often the leading topic are various performance improvements.
Currently in the GitHub backlog there are a range of sub-components of the MySQL Server, ranging from InnoDB B+Tree performance to Replication, where contributors proposed performance improvements. But hhere are a couple of interesting themes I thought are worth highlighting:
As a former sales engineer it warms my heart to see proposal from AWS separate performance improvements into “real issues”, that actually happen and cause problems in production, and “perceived problems”, that aren’t really a big problem in production, but cause the database to perform poorly in benchmarks. (In this case, HammerDB.) So with that introduction, you might be thinking the proposal wanted us to focus on the issues that make production slower. But no, the whole point was that users evaluate databases with benchmarks, or at the very least they read about others who did run a benchmark. And this makes the “perceived” problem a very real problem, because it may cause the user to choose some other database, and then they won’t run MySQL in production at all!
And what is it that promises not just 2x or even 4x improvement in HammerDB results just like that: the RETURNING Clause. More specifically this is an extension to DELETE and UPDATE. If you add the RETURNING clause to a DML command, then you will be able select the column who’s values are returned to the caller. In practice this means you avoid doing a separate SELECT, since you can get the result within the single UPDATE or DELETE statement. Single roundtrip instead of many!
In #24 InnoDB-based binary log Vinicius Grippa from ReadySet, presented a proposal to move the entire binary log inside of InnoDB. The main point of this move would be that for the typical MySQL transaction, both the tables and the binlog are now inside and managed by InnoDB, without the need for coordinating an XA-transaction between 2 separate subsystems. And in particular, removing the need for each of those subsystems doing their own fsync to disk. This ticket is one of the most active ones, with engineers from Oracle, Google and Alibaba discussing different approaches.
The Hypergraph optimizer continues to receive a lot of attention. On the one hand there are improvements to the explain output and other observability improvements. Ultimately the goal is to make this optimizer strictly faster than the old MySQL optimizer for every conceivable use case.
Issue #34 describes a service that should monitor also system events, such as disk or memory utilization. At first sight this appears to be an unnecessary feature, since there are already plenty of tools available that know how to monitor the Operating System. But it turns out that a) when you are diagnosing a database, in production, the server may not have the tools installed that you are used to working with, nor is it possible to easily install them either, and b) it’s just really convenient to have system level performance metrics available through the same channel where you get your database performance metrics from too. A single source for all your dashboards and performance comparisons.
Developer and DBA Experience
MySQL Workbench work falls under the Developer and DBA Experience bucket and issue #10 covers various updates needed to this popular GUI tool.
Issue #12 captures a long standing topic that was also brought up at the Contributor Summit: In MySQL the keyword BOOL and BOOLEAN are really just aliases for TINYINT(1). It also proposes to add ARRAY and UUID as native data types.
There’s a built-in tension in that discussion, since generally we encourage new datatypes to be developed as components! But for very primitive types like booleans and arrays, there’s still an argument they should be always available and therefore in the native set.
A very interesting feature in this category is the proposal to add System versioned tables to MySQL. This means the capability to define snapshots in time of a table, and makes it possible to query past snapshots of the table. The proposal is to implement this as defined in the SQL:2011 standard.
Extensibility and tooling
A well designed modular architecture is important for any software project, but doubly so for popular open source projects. The MySQL Component framework is what allows contributors to create new data types, functions, and of course even entire storage engines, in a relatively independent fashion. To ensure that we can scale MySQL as an open source project, we will have to continue to evolve the MySQL Component Framework.
MySQL was always modular
Over its 30 year history, MySQL has introduced several frameworks that allow new functionality to be developed in a modular way. Most famously of course MySQL gave us the concept of pluggable storage engines, which has allowed developers of different database engines to benefit from MySQL providing the standard SQL user interface and functionality, and MySQL and MySQL users in turn benefited from having a rich collection of database engines packaged into a familiar user experience, yet allowing them to choose the best tool for each job.
Another extension framework that’s been around for a long time is the API for adding User Defined Functions. UDFs allow users, or open source contributors, to extend the set of functions – both scalar and aggregate functions – from the default / built in set.
MySQL 5.1 introduced the Plugin API, which made it possible to distribute and install features separately from the MySQL Server itself.
MySQL Component Framework
And finally from MySQL 8.0 onwards we have introduced the MySQL Component Framework, and since then every major version has added APIs to various aspects of MySQL Server functionality, that can be extended with components. For example various methods for password validation, or logging and auditing, have been implemented as components.
The main improvement that components bring to the table: a well defined and enforced API. While for example the storage engine API is well defined in the sense that a storage engine needs to implement and provide certain things, it’s nevertheless the case that a storage engine plugin or a UDF plugin are loaded and live in the same address space as the rest of mysql-server. In principle there’s nothing stopping a plugin from calling any function and accessing any data it wants to.
Components on the other hand do operate against an API, and these client components can only use the methods made available through that API. Of course, there are a couple hundred different such APIs – called services – so a component could call many of those APIs to do what it needs to do.
Doubling down on the MySQL Component Framework
Following the contributor summit, the focus has been on doubling down on the MySQL Component Framework as the mechanism to write extensions to the core MySQL server. There are still areas of the MySQL Server that aren’t yet available through MCF APIs. A big one is the query optimizer (#22).
But what contributors have focused their efforts on so far is a feature that at the same time is much more basic and fundamental, and on the other hand is actually quite sweeping: User Defined Types (#674). The goal here is not just to allow end users to define new custom types for their use cases, but the goal is to make this API so complete and useful, that also built in (aka “native”) types could be implemented as components, without loss of functionality.
For example the Vector data type has been mentioned as an example: The work to add Vector support is implementing it as a native or built in type, because it is such an important and widely requested feature. But this should not be a choice we need to make. In the future, there should not be any downsides to adding a type via the Component Framework.
A vision for MySQL extensibility
While current work is mostly focused on extending the “surface area” of MySQL Component Framework, we are also aware that this is nowhere near the full scope of what we need to build in the coming years.
The ultimate power of the Component Framework is not just its use as a healthy way to practice good, modular, software architecture. The real goal is to unleash a mode of contributing to MySQL Server in a way where a majority of new code and features needn’t be contributed to the core MySQL server at all. In the future, a typical MySQL “contribution”:
- Should be possible to create and develop independently, without needing to coordinate or get “permission” with anyone employed at Oracle
- (In fact…) Should be possible and quite okay for two contributors to both implement the same feature, in slightly different ways, and let the users decide which one they want to use
- Should be possible for such extensions to clearly declare which component APIs they need to use, which they implement, and which versions they are compatible with
- And probably we need to have a way for one component to express the fact that it needs another component to be present. (dependencies)
- Finally, it should be possible for the independent 3rd party developer to publish their extension to MySQL functionality, and for end users to discover and install the extension, pretty much just as easily as they had installed core MySQL itself.
A great example of a project that is showing us the way is MyVector, by Alkin Tezuysal. Alkin presented a talk on his experience implementing HNSW based vector indexing in MySQL, using the MySQL Component Framework.
Utilities are extensions too
But the above is not yet all: MySQL Server can also be extended by software that is completely separate from the MySQL Server. A great example are the different *SQL Proxy products that have provided us with so many powerful features from thread pooling to encryption.
Tools used for observability, schema design, querying, reporting, dashboards… Various shells and clients… All of these are arguably “components” that extend and add value in the MySQL Ecossystem.
And Storage Engines!
While most of the development focus in the extensibility track is on extending the MySQL Component Framework, we shouldn’t forget that MySQL already has the tried and trusted framework that gave us so much cool database innovation over many decades already, The Storage Engine API.
Our efforts to open up MySQL development to community contributions would not be complete without someone proposing to add a new storage engine. And we couldn’t be more excited about the fact that in the past weeks we’ve added not just one, but two, rather powerful and very state of the art engines to our roadmap dashboard: DuckDB (proposed by Alibaba), the database that has been taking the analytics / OLAP market by storm, and TidesDB, a new and very state of the art LSM engine. LSM architecture is typically used for write-optimized, MVCC type OLTP workloads.
Both of these are scheduled to present at the next Contributor Summit.
Upcoming Contributor Summits
If you’ve read this far, and if you are anywhere near as excited as yours truly… You might be asking the question: When and where are these contributor summits happening and where can you buy tickets?
The answer is that these are by invitation request; if you would like to attend, reach out to the Community Team. These events are by and for developers who already are working on new MySQL features, or have made a proposal that they will be presenting and getting feedback on.
The next summit is just around the corner:
- August 5-6 in Colorado and virtually.
- November will be a 100% virtual summit
- February will be in Europe and adjacent to Fosdem and MySQL Belgium Days
- And after that likely in May at a location still to be determined
If you are working on or intend to propose some contribution to MySQL, and you would like to present in the contributor summit, or attend a summit, you can email HENRIK.INGO@ORACLE.COM or LENKA.KASPAROVA@ORACLE.COM.
Get Involved
And if you just want to roll your sleeves and start submitting issues and PRs… Sure, you can do that, there’s no hard requirement to present slides first. You can create a proposal in the mysql/mysql-community repo, and when you are ready to submit your first Pull Request, you’d typically do that against trunk in the mysql/mysql-server repo.
And as a reminder, to try to keep some focus while we open up the development, we’ve chosen four strategic roadmap categories. As you submit your proposals, try to think of which of these your contribution most closely fits into:
In the following blog posts I want to dive deeper into each of these four work streams, and give a bit more context around the rather technical discussions you will see if you start following the discussions in each ticket. Stay tuned for the next episode in MySQL development as it happens.