Supabase is a good product. I have written about it approvingly, I have shown how to run AI agents on top of an existing Supabase database, and none of that changes today.
But there is a list of things Supabase does not have. Not "does worse" — does not have. And instead of writing that list as a feature matrix, I recorded a video where every item on it gets used, in one conversation, by an AI agent building a complete CRM from a single prompt.
The prompt was one paragraph: create an app named crm6 — a database with three tables, a CRUD web API, the ability to send emails to contacts, and a modern frontend, with the whole API restricted to users in the "guest" role. The agent — Claude, connected over Magic's MCP server — did the rest. This article walks through what it built, and points out, at each step, the capability it leaned on that Supabase does not ship.
What got built
- An SQLite database with three tables — contacts, deals, and activities — with foreign keys, defaults, and seed data.
- Sixteen HTTP endpoints: full GET/POST/PUT/DELETE plus record counts for every table, and a send-email endpoint — every one of them restricted to the "guest" role.
- Email dispatch that looks up a contact by id and sends through the platform's SMTP integration.
- A designed frontend — JWT login against Magic's built-in auth, a KPI dashboard with a pipeline chart, searchable contacts with an email composer, a drag-and-drop deals kanban, and an activities list.
Total hand-written backend code: zero lines. The CRUD layer was produced by the crudifier — twelve declarative calls, 722 lines of generated Hyperlambda, each call returning in well under a second. The send-email endpoint was generated from a plain-English prompt in 7.6 measured seconds. The only thing authored line by line was the frontend, and the agent wrote that too.
Watch the build
Now the list.
1. A backend that generates itself
Supabase gives you PostgREST: a generic REST reflection of your schema. That is genuinely useful, and it is also where it ends. The moment you need an endpoint that is not a table projection — "look up this contact's email address and send them a message, and throw if the contact does not exist" — you are writing an edge function by hand, in TypeScript, with your own error handling, and deploying it yourself.
On Magic the agent described that endpoint in one English sentence, and the Hyperlambda Generator produced it, saved it, and put it on the wire — role-gated like everything else — in 7.6 seconds. The backend is not a reflection of the schema. It is generated, customizable code, produced from intent.
2. Access control the agent cannot code its way out of
This is the structural one, and the reason the video is possible at all.
Supabase's security model is row-level security: SQL policies you write per table, per app. When an AI agent generates your application code, every generated query and every generated function has to correctly respect those policies — and the service-role key that bypasses them is sitting right there in the environment. The security boundary lives inside generated code, which means every generation is a fresh chance to get it wrong.
Magic enforces access at execution time, in the runtime. Every endpoint in this build declares that it requires the "guest" role, and the check runs before any endpoint logic — the agent's generated code never gets the option of forgetting it. After the build, anonymous requests against the CRUD layer and the email endpoint were fired as verification: 401, access denied, every time.
That is why you can hand an agent production credentials on this platform and watch it work. The platform, not the prompt, decides what those credentials can do. Supabase has nothing equivalent — not because their engineers are not capable, but because their architecture places authorization inside the application, and the application is now written by a probabilistic author.
3. A native MCP server
Everything in the video happens over one MCP connection. Creating the database, generating endpoints, uploading files, verifying the result — the agent operates the platform through the same tool surface you are using when you talk to your own Magic cloudlet from Claude.
Supabase has MCP as an add-on for development workflows. Magic's MCP server is the platform: every capability, scoped to the authenticated user's roles, with the agent able to generate new tools for itself when the existing ones do not fit. There is no "integration" step in the video because there is nothing to integrate.
4. Email as a platform primitive
The CRM sends email to contacts. On Supabase that feature means an edge function, a third-party mail API, an API key to manage, and retry logic you own forever. On Magic, SMTP is configured once at platform level, and the generated endpoint simply sends — the agent never saw a mail-provider credential, because there is none in the application.
5. A web server
The frontend in the video is served by the same system that serves the API. The agent wrote three files — HTML, CSS, JavaScript — into the platform's file system, and they were live at their URL the moment they were written. No Vercel, no Netlify, no storage-bucket-pretending-to-be-a-website, no CORS configuration between your frontend host and your backend host, because there is only one host.
Supabase Storage holds files. It is not a web root, and Supabase does not want to be your web server. Magic is one deployable unit that is your database, your API, your auth, your mail, and your frontend host — which is precisely what lets one agent in one conversation ship the whole thing.
6. The boring ones that add up
- JWT auth with ticket rotation built in — the frontend logs in against the platform's auth endpoint and refreshes its ticket on a ten-minute window. No auth library was installed anywhere in this build.
- Task scheduling, logging, and a server-side file system — not used heavily in the video, but they are the reason the agent never had to leave the platform for anything.
- MIT license, one container, nothing gated — the entire stack in the video is the open-source product. There is no hosted-only feature making the demo prettier than your deployment.
What Supabase has that Magic does not
Fairness cuts both ways, and this list is real: realtime subscriptions over Postgres replication, the depth of the Postgres extension ecosystem, client SDKs for every framework under the sun, and a community large enough that every question you will ever have is already answered somewhere. If your product is built around live-updating Postgres data and your team's velocity comes from that ecosystem, Supabase remains the right call — I said so in the comparison article, and it still holds.
But none of those close the gap the video demonstrates. They make Supabase a better database platform. They do not make it a system an AI agent can safely operate end to end.
The point
The interesting question in 2026 is no longer "which backend has the better dashboard." It is: when the next developer on your team is an agent with a prompt, what can it actually do — and what stops it from doing what it should not?
In this build the answer was: everything, and the runtime. A database, sixteen role-secured endpoints, email dispatch, and a designed, working frontend, from one paragraph of intent — with every operation bounded by execution-time RBAC the agent could not generate its way around. That combination — generation, enforcement, MCP, mail, and hosting in one self-hosted, MIT-licensed unit — is the system that has everything Supabase does not.
Magic is open source at github.com/polterguy/magic, documentation at docs.ainiro.io, and hosted cloudlets at ainiro.io if you would rather not run it yourself.
This article was originally published on hyperlambda.dev.
Top comments (0)