I want to say this up front: Supabase is a good product. This is not a takedown. But I keep meeting developers who like Supabase's model and still can't use it — because of one of a handful of hard constraints that no amount of Supabase configuration removes.
I build Magic Cloud, an MIT-licensed, self-hosted backend platform. Below are the differences that actually matter — specifically the things Supabase users ask for and structurally can't get, and honestly, the places where Supabase remains the better pick.
The quick comparison
| Supabase | Magic Cloud | |
|---|---|---|
| License | Open-core, some features hosted-only | MIT, everything included |
| Self-hosting | Community-supported compose stack | First-class, one backend + one dashboard container |
| Database | PostgreSQL (theirs) | SQLite default; connects to your existing MySQL, PostgreSQL, MSSQL |
| Server-side logic | Deno edge functions, separate deploy | Generated endpoints, live instantly, no build step |
| Access control | Postgres RLS, written per app | Execution-time RBAC enforced by the runtime |
| AI story | pgvector + client libraries | Native RAG, chatbots, MCP server, endpoint generator |
Now the parts a table can't capture.
1. It connects to the database you already have
This is the difference that decides most evaluations, so it goes first.
Supabase is a managed Postgres. You don't connect Supabase to your database — you migrate your data into theirs. If your data lives in a fifteen-year-old SQL Server, or a MySQL instance three other systems depend on, that migration is somewhere between painful and impossible.
Magic points at any existing MySQL, PostgreSQL, SQL Server, or SQLite database and generates a complete, secured CRUD API on top of it. The data stays where it is. Nothing migrates. The CRUD generator reads your schema and emits one endpoint per operation per table, each with authentication and role checks already wired in.
For teams with legacy databases, this isn't a feature comparison — it's the whole decision.
2. Backend logic without a separate runtime
Supabase's answer to "I need server-side logic" is edge functions: Deno, a separate deploy artifact, its own toolchain, and cold starts. It works, but it's a second system bolted onto the first.
In Magic, an endpoint is a file on the server. Create the file, the endpoint is live. No build, no deploy pipeline, no cold start — after first execution the compiled AST is cached and subsequent calls execute in roughly 100–200 milliseconds.
The runtime language is Hyperlambda, and before that triggers an objection: you're not expected to write it. It's generated — by the CRUD generator, or by the Hyperlambda Generator, which compiles plain-English prompts into working endpoints. Think of it like the SQL your ORM emits. Readable, editable, rarely hand-authored.
A side effect worth more than it sounds: since every endpoint is a plain-text file, your entire backend is version-controllable with git, as-is. Supabase's server-side logic lives inside the database as RLS policies and triggers, and extracting it into reviewable migrations is its own discipline. Magic's answer is git add.
3. Sending email is a platform primitive
Small one, but it's a perennial forum question: "how do I send email from Supabase?" The answer is always the same — you can't, beyond auth emails; go sign up for Resend or SendGrid and write an edge function.
Magic has SMTP built in. Endpoints send mail, with MIME attachments, as a one-liner of generated code. Same story for task scheduling: where Supabase offers pg_cron (which runs SQL), Magic has persisted, schedulable tasks that execute arbitrary backend logic — the "every Monday, call this API and email the report" job that SQL-only cron can't express.
4. The AI layer is a platform, not a column type
Supabase's AI story is pgvector plus client libraries: here's a vector column, build your RAG pipeline yourself.
Magic ships the pipeline. Website crawling, vectorization, RAG-backed machine-learning types, an embeddable chatbot widget, and AI functions — configured from the dashboard, no glue code. If the goal is "a chatbot trained on our docs, on our infrastructure," that's a dashboard task, not a sprint.
5. The part I think matters most: agents can safely operate it
Both platforms now have MCP servers, so both let AI agents talk to the backend. The difference is what happens when agents build on it.
Supabase's security model is row-level security: SQL policies, written per application. When a human writes the app, RLS works well. When an AI agent generates the app, every generated endpoint and query has to correctly respect those policies — the security boundary lives inside the generated code, and every generation is a fresh chance to get it wrong. A service-role key where an anon key belonged. A query that sidesteps a policy. The model doesn't have to be malicious, just wrong once.
Magic inverts this. Hyperlambda executes as an AST, and every node must bind to a slot the runtime exposes. Permissions are enforced at execution time: endpoints declare which roles may invoke them, and the whitelisting system controls which slots code in a given context can bind to at all. If a capability isn't whitelisted, generated code cannot call it — not "is instructed not to," but structurally cannot. The worst a bad generation can do is fail.
That means an agent connected over MCP can generate new endpoints, create databases, and wire up logic — and everything it produces runs inside the same runtime-enforced boundaries as human-written code. Security is a property of the platform, implemented once in C#, instead of a property each generated app has to reimplement. I've written up the architecture in detail here.
In one reproducible session, an agent given a single natural-language prompt created a database, generated a public API, wired email notifications, deployed a chatbot widget and landing page, and verified every step over HTTP — and when the platform rejected a malformed widget, the agent read the built-in guides over MCP and fixed its own mistake. No human in the loop between prompt and working system.
6. Nothing is gated
Magic is MIT-licensed end to end. There's no enterprise edition, no hosted-only dashboard features, no open-core split where the self-hosted version quietly lacks SSO or log drains. The hosted cloudlets at AINIRO run the same code you can deploy yourself from the GitHub repo — because there's nothing to gate.
Self-hosting is the primary deployment model, not a community afterthought: one Docker container for the backend, one for the dashboard.
Where Supabase is still the right choice
Credibility requires this section, so here it is, unhedged.
You need Postgres specifically. Extensions, replication, a team fluent in it. Supabase's all-in bet on Postgres is a genuine strength; Magic treats databases as pluggable, which is more flexible but less deep on any single engine.
You rely on the ecosystem. Client SDKs for every framework, enormous community, a tutorial for everything. Magic's community is smaller. If your velocity comes from copy-pasting battle-tested Supabase snippets, weigh that honestly.
You want realtime and storage-with-CDN out of the box. Realtime subscriptions and storage buckets are Supabase strengths without a direct Magic equivalent.
You want a managed service and were never going to self-host. Supabase's hosted product is genuinely good. Most of this article's argument is about the self-hosted path.
Summing up
If your constraints include an existing database, real self-hosting, MIT licensing, or AI agents building and operating backend functionality, Magic Cloud solves problems Supabase structurally can't. If your constraints are Postgres depth and ecosystem gravity, stay with Supabase — sincerely.
The repo is at github.com/polterguy/magic, the docs at docs.ainiro.io, and a longer evaluation-focused comparison at hyperlambda.dev. Spin it up in Docker and point it at a database you already have — that first CRUD generation is the moment the difference clicks.
Top comments (0)