Hey Database! Go Fine Tune Yourself | Max De Marzi

Max De Marzi

Graphs, Graphs, and nothing but the Graphs

Home<br>About

Contact

Services

Videos

May 29 2026

Leave a comment

By maxdemarzi

database, Problems, RelationalAI

Hey Database! Go Fine Tune Yourself

Everyone expects AI prices to go down in the long term. But in the short term, we have three things going on. Token prices keep dropping, hurray for that. Subscription fees are going up and dumping their all you can eat plans for volume based pricing. There more you use, the more you pay. I guess that’s fair. Third, hardware component pricing is going up and big companies are borrowing billions to build the greatest and latest AI data centers. What’s going on? Are we in the pets.com era of selling $40 dollars worth of dog food for $20 bucks and making it up in volume? The real question is, how do we close this giant chasm of a value gap?

Molham Aref argues that enterprises must make agents smarter and cheaper. We have to solve two problems at the same time: making agents smart enough to handle real business decisions, and ensuring they are cost-effective enough to scale enterprise-wide. It sounds simple enough on the surface, but… it’s not. I’m going to talk about one of the ways we are doing that. But before I start, about six months ago, Greg Diamos and Naila Farooqui at RelationalAI wrote a blog post "Introducing Superalignment for Relational Databases". If you haven’t read it yet, please take the time to do it now or you may be a little lost on what follows. There is a line in there people sometimes overlook, even thought it’s literally highlighted in bold:

The training dataset is the database itself .

The high level version is that RelationalAI takes a look at your database, your schema, your data, your business rules, your queries and fine tunes an LLM with your specific attributes. Then when you need to ask your database hard questions, you route them to your smaller smarter model which writes the queries needed to answer them. Because you’ve post-trained the LLM on your specific data, you can stop wasting tokens telling it what the schema is or how it’s connected, or what this field or that field mean, and so on. It saves you a ton of money and it’s more likely to give you good queries that answer your questions correctly. Now here comes the interesting part. One of the things we are doing to fine tune LLMs is generating bad queries.

If the whole point of Text to SQL is to generate GOOD queries that answer the question, why do we need BAD ones? Because there is this fine tuning concept called Direct Preference Optimization. I already asked you to read two blog posts, so I’m not going to ask you to read an academic paper, instead just think of Morpheus from the movie "The Matrix".

In the movie, Morpheus tells Neo, "You take the blue pill, the story ends… You take the red pill, you stay in Wonderland." In DPO, it enforces this same binary constraint. DPO completely skips the step of calculating a floating-point "score" for the text. It has to choose between the two options. The model’s active weights represent Neo standing in front of the choice. Neo takes the red pill. By penalizing the blue pill, your network learned to drop its log-probability, making it harder for the model to choose that option in production.

Question: Which users are we able to sell alcohol to in the United States? The correct answer is the red pill, the almost correct answer is the blue pill.

Alright, now you know why we need bad queries. Not invalid queries mind you, the LLMs are way past the stage where you ask them to answer a database question and they give you the recipe for Portuguese Octopus or an invalid SQL query. In fact, we are at the stage where we can ask the LLMs to tell us exactly how they mess up SQL queries and use that information to make our bad queries ourselves.

Obviously I can’t show you exactly what we do at RelationalAI, but I built a Temu version of it using VillageSQL again. Introducing the vsql-corruptor extension. If you missed my previous blog post, VillageSQL is a MySQL change tracking fork that adds the ability to make extensions to the database quite easily.

The way it works is you pass in a SQL query and optionally you can specify which SQL corruption type you want to apply or leave it blank and it will randomly pick one, and you can either pass in a database schema in text or pass in the name of an existing database name in your VillageSQL server and it will get the schema from that database automatically.

SELECT vsql_corrupt(<br>'SELECT first_name FROM customers WHERE first_name = \'Alice\'',<br>'TYPE_INCOMPATIBILITY',<br>'customers:first_name VARCHAR,id INT'<br>);<br>-- Returns: SELECT first_name FROM customers WHERE (first_name = 1234)

That’s pretty neat. Or you can create a database with some tables:

CREATE DATABASE test_corrupt_db;<br>USE test_corrupt_db;

CREATE TABLE customers (<br>id INT PRIMARY KEY,<br>first_name VARCHAR(50),<br>last_name...