You’ve spent weeks cleaning data, engineering features, and tuning hyperparameters just to predict customer churn. Meanwhile, your competitor just typed one line of SQL and got a better answer.
We’ve been conditioned to believe that machine learning is a separate, sacred discipline. You extract data from your database, export it to a Python notebook, pray to the XGBoost gods, and then struggle to deploy the model back into production. It’s a fragmented, exhausting ritual.
The real innovation isn’t a better model architecture—it’s killing the ML pipeline altogether.
Enter RelativeDB. Built on Stanford’s Relational Transformer architecture, this open-source query engine treats the foundation model itself as a database. You don’t build a model; you just ask your database a question.
Want to predict churn? You write a query:
PREDICT NOT EXISTS(orders.*) OVER (90 DAYS FOLLOWING) FROM customers
That’s it. The engine automatically traverses your foreign keys, finds the relevant context across related tables, and returns a prediction. No manual feature engineering. No extracting tables to CSVs. The database just answers.
We’ve been treating structured data like a dumb filing cabinet, when it was actually a graph of human behavior waiting to be understood.
In early tests, RelativeDB is outperforming traditional ML approaches like XGBoost—using only a tiny amount of relational context. Why? Because tabular models traditionally fall apart when they can’t see the join graph during inference. They look at a single table in isolation. RelativeDB looks at the entire relational context.
This isn’t just a neat technical trick. It’s a paradigm shift. For the analysts, engineers, and data scientists pulling their hair out over bespoke ML projects: your job is about to change. The friction of deploying fraud detection, demand forecasting, and recommendations is collapsing into a single command.
If you can write a SELECT statement, you are now a data scientist.
The project is still early, and the optimizer needs work to decide when to use a foundation model versus a fine-tuned one. But the direction is undeniable. Machine learning is no longer a separate engineering task; it’s a database operation. And the companies that realize this first will ship predictions at a speed their competitors simply can’t match.
FAQ
Q: How does it handle foreign key traversal at inference time if the join graph wasn't seen during pre-training?
A: This is exactly where traditional tabular models fail. RelativeDB's relational transformer architecture is designed to dynamically adapt to new databases and traverse these relational contexts at inference time, which is why it outperforms isolated tabular models.
Q: What does this mean for my data team?
A: It means you can stop extracting data into bespoke Python ML pipelines. Complex predictions like churn or fraud can be handled directly in the database layer, drastically reducing deployment friction and the need for specialized feature engineering.
Q: Is this the end of data scientists?
A: Not the end, but a massive evolution. If querying a prediction becomes as easy as a SQL SELECT, the value of a data scientist shifts from feature engineering and model tuning to asking the right business questions and designing the relational schema.