Crafting an Extension Framework for MySQL: a talk from MySQL BR Conf 2026
The design choices behind the VillageSQL Extension Framework, from simpler functions to parameterized types to porting PostgreSQL’s hstore. Watch the MySQL BR Conf 2026 talk.
I opened my MySQL BR Conf 2026 talk creating a new data type that stock MySQL doesn’t have: ROT13. … OK, admittedly, it’s a silly type. With a ROT13 column, you insert plain strings and read back plain strings, but the table stores scrambled text. … OK, it’s very *very* silly. But the point of this example isn’t to convince you extensions are useful; it’s to show a tiny extension that allows exploring design choices we made in designing the VEF (VillageSQL Extension Framework).
What the talk covers
- Simpler functions and aggregates. VDF’s (VEF-Defined Functions) resemble MySQL UDF’s (User-Defined Functions), but are easier to write. I explore how we made it both more ergonomic in C++ and also how we make it harder to mess up.
- Types that take parameters. Some types take parameters; e.g., vectors need a length. To show how to handle this in our existing silly example, I generalize ROT13 into ROT(K).
- The escape path. I show how functions that don’t have tidy, compile-time signatures like printf fit into the VEF. I also describe our design pattern for cases like these. In the talk, I link to a blog post on this blog, which I will also now link here in an example of Linkception: “Happy Path, Escape Hatch, and the Space Between”.
- Porting a PostgreSQL extension. The talk ends with what happened when VillageSQL's Claude Code skill ported PostgreSQL's hstore extension, and what the port cost.
About Daniel Bentley
Dan is a founding engineer at VillageSQL. He has worked at Google and Twitter, and he did a startup called Tilt that focused on Kubernetes developer tools. He is on a quest to make databases delightful to use by translating complex systems into elegant simplicity.
Get started at villagesql.com, read the docs, or talk to us on Discord.
