Most people building with AI know how to build. Very few know how to manage a database.
I say this with love, because I lived it: when I started, the database was the layer I didn't look at. Things worked, so I kept going, building as I went. That's how most of us start, especially without a technical background: blind to the part that holds everything.
Then this past year, it became my actual job. I've helped more than 1,000 developers untangle exactly these problems, most of them building with AI tools, many without a technical background. The pattern repeats every week: nobody pays attention to the database until the day it demands attention. And once real people and real client data live in your tables, not understanding it stops being a knowledge gap and becomes a responsibility.
So if an AI is going to build and manage your database, three questions matter. Who should you trust it to? Which one actually does it better? And what do you need to learn so you're not just crossing your fingers? Until last week, every answer was somebody's opinion. Now there's data.
Supabase open sourced Evals, their benchmark for AI coding agents. An eval is exactly what it sounds like: an evaluation, a graded exam. Same tasks, same conditions, every agent takes it, and everyone can see the grades on a public leaderboard at supabase.com/evals. The tasks aren't multiple choice. They're real backend work, done in a real Supabase environment, and the scoring checks things that matter in real life, like whether the wrong user can see data they shouldn't.
The exam has four parts
This is my favorite thing about how Supabase designed it, because the four parts map exactly to the life of a real app. I pulled these from the actual test scenarios in the repo:
Build. Can the agent create things from scratch? Set up a database, add login, write the security rules that decide who sees what, build a little to-do app where each user only sees their own todos.
Deploy. Can it take what it built and put it live? Ship a function with its secrets configured correctly, get the whole stack running, wire up monitoring.
Investigate. Detective mode. Something is wrong and nobody knows why yet. A deleted user somehow still has access. Errors spiked overnight. The live updates stopped arriving. The agent has to find the cause, not fix it, just correctly figure out what's happening.
Resolve. The repair. The problem is known, now fix it without breaking anything else. A security rule leaking data between users. A slow query eating the CPU. A migration history that doesn't match reality.
Build is the demo. Investigate and Resolve are Tuesday night when your app is down. Keep that in mind for what comes next.
Who manages it better?
The short version: the top agents are genuinely good at this. This is the live leaderboard, captured August 4, 2026, with no extra guidance loaded:
These agents can build and deploy a working backend, with authentication and security rules, essentially on their own. That sentence would have been science fiction two years ago. It's worth sitting with it for a second.
If you're wondering who wins: Supabase doesn't actually crown a winner in their launch post. I went to the repo and the leaderboard, and the numbers do it for them. Right now Codex with GPT-5.6 sol is the only agent passing all four parts at 100%, including the one where everyone else dropped points. The leaderboard is live, so this photo may age, but that's what the data says today.
And look at where everyone else lost points. Almost every agent scored 100% on Build and Deploy. Three of the top four dropped to 67% on Investigate. The agents are excellent at the part where you feel productive, and weakest at the part where you feel lost.
What Supabase found along the way
The ranking is honestly the least interesting part. The observations are where the value is.
Agents skip the documentation. Claude Code consulted the docs in under 40% of scenarios, reading about 2 pages per task. Codex read around 8. These tools are confident enough to build without checking the manual, and most of the time they get away with it. Most of the time.
Agents build with yesterday's knowledge. Supabase caught two specific habits here, and they're worth unpacking because if you're not technical they sound harmless. They're not.
First: agents hand-write migrations. A migration is a list of step-by-step instructions for changing your database. Add this column, create that table. Hand-writing those steps works today, but months later you have a pile of instructions and no single clean picture of what your database is supposed to look like. The recommended way, a declarative schema, is the opposite: one document describing the final shape, and the steps get generated from it. One source of truth instead of an archaeology dig. Supabase's exact finding makes the point better than I could: even in projects that already used declarative schemas, agents tried to hand-write migrations anyway. The habit is that strong.
Two practical notes on this. It's a day-one decision: adopting declarative schemas when you start a project is easy, and switching later is documented and doable, just more work. And one honest caveat from the docs: the tool that generates the steps doesn't capture everything, notably your security rules, so those always need their own verification.
Second: agents reach for older tools. When checking who's logged in inside Edge Functions, they kept hand-rolling the verification with the classic supabase-js library instead of using @supabase/server, a newer package built exactly for that job.
Neither habit breaks your app today. Both cost you later. And they share a root cause worth understanding even if you never write a line of code: an AI's knowledge has a date. The model knows the world as it looked when it was trained, and these tools move monthly. Unless something forces it to consult current information, it will confidently build you the best backend of last year.
Guidance fixes most of it. When Supabase loaded their agent skills, basically curated instructions the agent can pull in, Sonnet 5 jumped from 78% to 100% on building tasks. The smaller the model, the bigger the lift. And even the instructions needed iteration: one skill was only activating in 10% of sessions until Supabase rewrote its description. Then it hit 60%.
So, who should you trust?
Here's my honest read. At the top, the differences are small. Any of the leading agents will build you a working backend. The trust question isn't really "which agent," it's "which stage." Trust them to build. Verify when they investigate. Because when your app breaks at 11pm and the agent starts guessing, you are in the exact stage where these tools score the worst.
And one more thing the exam can't measure: it grades tasks with clear success criteria, written by the people who built the platform. Your app is not a benchmark. Nobody wrote the success criteria for it except you. A 95% score does not mean 95% of what you personally ship is right, especially the security rules, where a mistake isn't a bug, it's an incident.
What I did about it
The Investigate gap has a structural fix: don't let the builder grade its own homework. I turned that into a skill, open sourced as a work in progress: db-supervisor (a name I fully intend to improve someday). Now anything database-related my agent builds triggers a second pass from a fresh session playing the investigator. It proves who can see which data with real queries, runs the security and performance checks, verifies the migration history against reality, consults today's docs instead of trusting its memory, and hands me a small table with a verdict: OK, or needs attention, with every failure explained in one plain-language sentence. Nothing ships without the OK.
And my favorite part: the skill checks the live leaderboard and hands the investigation to whichever agent is best at it today. Right now that's Codex, even though Claude does the building. Route by stage, not by loyalty.
Ok, I have this information. Now what?
This is the part I care about most, because it's the part you control. And if you're not technical, and a lot of the people I help every week are not: you don't need to learn to code. You need to learn to ask. Everything on this list is askable.
- Load the [Supabase agent skills](https://github.com/supabase/agent-skills). One command, for everyone, technical or not: it's how your agent gets today's best practices instead of yesterday's training data. And still, don't assume it read the docs. The data says it probably didn't.
- Ask your agent to explain what it built, and to draw it. In your language, at your level. Tables, arrows, who connects to what. You don't need to write it. You need to be able to see it.
- Make it prove who can see which data. With real queries, not by reading the policy and nodding. If the answer surprises you, you found it before your users did.
- Put fresh eyes on anything database-related. A second pass from a session that didn't build it: another agent, my skill, or simply a new conversation. The builder never grades its own homework.
- Debug one broken thing per week alongside the agent, instead of just pasting "fix it." That's the Investigate stage, the exact muscle the exam says the agents haven't developed. Turns out it's the one worth developing in yourself.
- Check the [live leaderboard](https://supabase.com/evals) the day you're choosing an agent. Not once forever. The standings have a date, and that's the point.
What to understand, even if you never write it
The exam itself hands you the study list. Based on what the benchmark tests:
- [RLS (Row Level Security)](https://supabase.com/docs/guides/database/postgres/row-level-security): the rules for who can see which data. This is the one where a mistake is an incident, not a bug.
- [Migrations and declarative schemas](https://supabase.com/docs/guides/local-development/declarative-database-schemas): how your database's shape gets defined and changed, and why one document beats a pile of patch instructions. If you're a vibe coder, this is the one we most often just leave alone.
- [Auth verification](https://supabase.com/docs/guides/auth/choosing-a-server-package): where your app checks who's logged in. Supabase wrote this guide after watching the agents take shortcuts on exactly this.
- [The four stages](https://supabase.com/evals): build, deploy, investigate, resolve. Knowing which stage you're in tells you how much to trust the agent at that moment. I've taken these four personally: they've become the lens I use for everything I build with AI, not just databases.
Use this in your favor
Now you have this: the data, the stages, the actions, the study list. My last recommendation ties it all together: set up a small daily agent whose only job is checking what changed. Supabase refreshes the eval results daily, updates their agent skills, and ships new things every month. An agent that checks those sources each morning and tells you what moved keeps your whole setup honest. And it's exactly the kind of boring, repetitive job agents are perfect for.
Because that's the mindset shift this benchmark really points to: you have to take care of what your agents are seeing and consuming, not just trust them more and more. Their knowledge has a date. Their instructions go stale. The people getting the most out of AI agents aren't the ones trusting them hardest. They're the ones feeding them best.
The agents got graded last week. They did well. The interesting question is what grade the way you use them would get.
If you want to go deeper, the launch post is readable even if you're not deeply technical, and the whole exam is open source if you want to see how it works. And if you want to see exactly what the skills teach the agents, Supabase published the 30 Postgres rules behind them, with wrong-vs-right examples for each one.