VillageSQL

Porting PostgreSQL Extensions to MySQL using Agent Skills

Adam Levin

Adam Levin

— 3 min read
Share
An ai generated picture of robots moving graphical representations of code from PostgreSQL to VillageSQL

VillageSQL is a tracking fork of MySQL that adds the VillageSQL Extension Framework (VEF). Extensions are written in C++ (with a Rust SDK coming soon), packaged as .veb bundles, and installed with SQL. The fastest way to understand what VEF can do is to build something with it. To make getting started a bit easier, we published a skill you can run in a local CLI agent session (for example, Claude Code) to build new or port an existing extension.

Agents are “smart” so they could probably figure out how to build an extension on their own through trial and error. This skill allows you to save tokens by skipping some of that trial and error and using a framework/workflow that consistently works and has been improved through multiple iterations.

If you don't have VillageSQL installed already, you can get it with this install script:

curl -fsSL https://villagesql.com/shell | bash

Next, install the skill by running:

curl -sSL https://villagesql.com/skills | bash

Then, open Claude Code CLI (or your favorite agent) and run:
/vsql-extension-builder
We did our testing with Claude Code but this uses the Agent Skills standard so it will work with most agent CLIs.

The agent will ask you a few questions about what you want to build. Once you've described your extension, the agent takes it from there — design, scaffold, implementation, tests, docs. You get back a working extension you can install into a running VillageSQL server. For paths and server connectivity, it reads the installer's config and connects automatically. It will ask you for the details if it can’t find that information on its own.

You can give the agent an existing PostgreSQL extension to port or you can design the extension of your dreams. Some examples:

  • "Build a PostgreSQL-compatible citext type — case-insensitive text that preserves original casing."
  • "Implement a webhook function that makes HTTP GET requests and returns JSON responses."
  • "Create a PostgreSQL-style hstore type for key-value storage in a single column."

As the agent goes along, researches, and builds, if there is any surface area that VEF doesn't support yet, it will let you know and prompt you to file an issue with the VillageSQL team (or upvote an existing issue).

What the skill does

The skill doesn't try to do everything at once. It runs seven development phases across five distinct personas, ensuring design, implementation, and review stay separate, with different personas cross-checking the work. Stability and quality are improved by pitting the phases against each other (an antagonistic approach).

  1. Requirements: Gathered by the Product Strategist.
  2. Feasibility & Architecture: Binary layout and function map designed by the Architect.
  3. Scaffold: Extension directory created from the template by the Architect.
  4. Implementation: Built function-by-function by the Team Lead.
  5. Compliance: Reviewed against the VEF spec by the CTO.
  6. Validation: Live database UAT executed by the End-User.
  7. Documentation: README, testing docs, and known limitations written by the Product Strategist.

Each phase has a narrow remit and a checklist, which keeps the agent from collapsing design, implementation, and review into a single pass where bugs hide.

In Phase 1, the skill locates and version-checks the SDK against the running server. At the start of Phase 2, it reads the typed API headers to extract the exact function and type names it will use — no names are hardcoded. Reading the live headers is how the skill stays correct as the SDK evolves and is tailored to the build you are running. The agent proposes a design and binary layout before writing any code. If your idea needs a hook VEF doesn't support yet, it will either implement a safe workaround or stop and explain what's missing — and write that gap into the extension's Known Limitations section.

Environment setup and requirements come first, then feasibility and scaffolding from the vsql-extension-template. Implementation runs function by function: writing the C++, building the .veb, installing it, testing against a live server, then moving on to the next. After that, the CTO phase audits exception safety, thread safety, little-endian portability, and memory bounds. UAT validates the extension end-to-end, and the final phase generates the README and testing docs.

The part that matters most is the implementation loop. Each function gets tested the moment it compiles, which means bugs surface where they happen instead of three functions later in a stack you can't unwind.

The total cost of a run depends on what model you use. With Claude Sonnet 4.6, expect to spend about 30 minutes and around $15 to run this start to finish for porting an extension such as hstore.

We love feedback

In addition to giving you an extension you can run on VillageSQL today, the skill is also meant to surface the opportunity areas of VEF while we're still shaping it. The roadmap gets sharper when we know what people are actually trying to build.

When the agent finishes, the Known Limitations section in the generated README lists every hook it wishes VEF had. Please file those as new issues or upvote existing issues.

Get started on GitHub at villagesql/villagesql-skills. This is the first of multiple skills we plan on publishing to help bring MySQL into the agentic era.

Read more