VillageSQL Features… déjà vu?

At events with the MySQL community, when we were enough “veterans,” we had a little ritual: we played Cards Against the MySQL Community.

A politically incorrect (but still lighthearted) game that followed the same rules as “Cards Against Humanity.“

Those were some really fun, unforgettable evenings!

One of the most popular black cards, which always sparked answers each more outlandish than the last, was:

________? Drizzle had it already!

VillageSQL

Now you might be thinking, “But what does this have to do with VillageSQL?“

First of all, I’d like to emphasize that I have nothing against VillageSQL—quite the opposite! I really like the people who work there and find them to be highly competent. I even worked alongside some of them, and those were years of very fruitful collaboration.

But when I see the features they offer for MySQL or the ones they’d like to add, I can’t help but think, “But MariaDB already has them!”

Please note that Drizzle was a stripped-down version of MySQL, stripped-down unnecessary features, whereas MariaDB is not; in fact, the opposite is true. The MariaDB server offers more storage engines, data types, and SQL features…

This means they are putting a lot of effort into bringing something already available in the Community (and Open-Source). In that particular case, I can’t consider this an innovation, and it might be better to extend what already exists in MariaDB Server. Wouldn’t it be more productive?

Now you might be wondering, “What on earth is he talking about? It’s true that I’m familiar with a few data types that are also available in MariaDB”… but it goes deeper than that—let me show you.

Data Types

One of the first statements I heard from VillageSQL when I met them was about their framework for extending MySQL with new data types via plugins. Currently, in MySQL, it’s not possible to add new data types via an extension.

With their framework, VillageSQL added several new data types, such as UUID, NETWORK, and VECTORS (even though a VECTOR data type is already present in MySQL, only in version >= 9).

MariaDB has had a Type_handler framework for quite some time already (since 2019, MariaDB 10.5.0). [1][2][3][4][5][6]

We use our own dog food, and we have already created several new data types using this framework:

├── type_assoc_array
├── type_cursor
├── type_geom
├── type_inet
├── type_mysql_json
├── type_mysql_timestamp
├── type_test
├── type_uuid
└── type_xmltype

As you can see, MariaDB already had UUID, INET6, and INET4 data types (and more)!

Similarity Search

VillageSQL has implemented a new VECTOR data type and plans to implement an HNSW index for approximate nearest-neighbor (ANN) search.

And once again, MariaDB server already implemented both of them. [1][2][3][4][5]

The MariaDB distance function with the VECTOR index is one of the best on the market [1].

Analytical Capabilities

We can also see in VillageSQL’s roadmap that they plan to add Analytical Capabilities by embedding analytical engines like DuckDB.

And of course, such integration has already been done for MariaDB.

We even have two different options:

• https://github.com/MariaDB/duckdb-engine [1][2]
• https://github.com/eriksquires/holyduck

In the analytics world, there is also the ColumnStore engine.

Built-in Aggregate Support

In VillageSQL’s roadmap, we can also notice “Full Built-in Aggregate Support”.

MariaDB Server already provides 2 ways to create custom aggregate functions:

• Stored Aggregate Functions
• create a UDF function for aggregation.

Extend Using Rust

Recently, VillageSQL blogged about extending MySQL using Rust.

Cool, isn’t it? But in fact, MariaDB is also able to support User-Defined Functions in Rust!

So, once again, nothing really new.

So, what’s the point?

VillageSQL is doing interesting work, and I’m genuinely happy to see people investing energy, ideas, and engineering effort into the MySQL ecosystem. That can only be a good thing for users.

But when many of those ideas already exist in MariaDB Server, I can’t help but wonder whether we are collectively spending too much time reinventing things in parallel rather than building on what the community has already created.

Innovation is not only about adding features. Sometimes, innovation is about collaboration, reducing fragmentation, improving what already exists, and making good technology easier to adopt.

MariaDB already has many of the foundations VillageSQL is exploring: extensible data types, UUID and INET support, vector search, analytical engine integrations, and even Rust-based extensibility. Some implementations differ, of course, and there is always room for improvement. But that is exactly why contributing missing pieces upstream could be so valuable.

VillageSQL has, of course, other features too, but here I was focusing on the main one that has been presented and that already has something similar in MariaDB Server.

We at MariaDB also have some responsibility, as some of our features (like the Rust UDFs I recently discovered or the Type_handler framework) are not well-known enough. We need to evangelize them much more.

So, with all due respect and appreciation for the people behind VillageSQL, I’ll allow myself one last nostalgic reference to our old community game:

VillageSQL? MariaDB has it already!

This article is in no way intended to divide the community or disparage the efforts of the VillageSQL team, but rather to foster discussion about what matters and, above all, how we can collectively drive innovation for the benefit of everyone without reinventing the wheel. MariaDB Server with all the current features could be the building blocks for fostering innovation.