Magic Cloud covers the ground Supabase does — database, generated APIs, auth, RBAC, file handling — as one MIT-licensed system where self-hosting is the primary deployment model, not the community afterthought. It adds what 2026 demands: a runtime AI agents can safely build on. This page is an honest evaluation, comparison table included — along with the cases where you should stay on Supabase.
Self-hosted Supabase is a docker-compose stack that behaves as a single project, with community-documented gaps in logging, backups, and dashboard features. The hosted platform is the product; self-hosting reflects that honestly.
Parts of the Supabase experience are only available — or only complete — on the hosted platform. If you need self-hosting for compliance or sovereignty, you are running a reduced version in production.
Supabase is PostgreSQL, full stop. If your data lives in SQL Server or MySQL — as most enterprise data does — there is no path that does not start with a migration.
The hosted platform is priced per usage, and at scale the bill becomes an engineering topic of its own. Self-hosting Magic costs whatever your server costs.
Supabase security is row-level policies written per app. When an AI agent generates the app, every generation must correctly reimplement that boundary — and probabilistic authors are sometimes wrong. This one gets its own section below.
None of the above is a scandal. Supabase is excellent at what it is: a hosted-first Postgres platform with a massive ecosystem. The question this page answers is what to pick when the qualifiers — self-hosted, open, agent-operated — matter to you.
Including the rows Supabase wins. Both rows are called plainly — ecosystem and Postgres depth go to them, and we say so.
| Feature | Supabase | Magic Cloud |
|---|---|---|
| License | Open source core; parts of the experience gated to the hosted platform | MIT, everything included — self-hosted runs the same code as hosted |
| Self-hosting story | Community-supported docker-compose stack; single project per instance; observability and backup gaps | First-class — self-hosted is the primary deployment model |
| Database | PostgreSQL only | SQLite by default; PostgreSQL, MySQL, SQL Server connected |
| API generation | PostgREST over your schema | Generated Hyperlambda endpoints per table — readable files, customizable after generation |
| Access control | Postgres row-level security, written per app | Framework-enforced RBAC, checked by the runtime at execution time |
| Custom backend logic | Edge functions, database functions — written by you | Described in plain language, generated by the Hyperlambda Generator — live without a deploy cycle |
| Realtime | Native Postgres-change subscriptions | SignalR — programmable events published from writes, tasks, or any logic |
| Auth | GoTrue — email, OAuth providers | JWT, users, roles, full OIDC and OAuth support |
| Frontend hosting | Not part of the product | Static sites and SPAs served from the same cloudlet |
| AI & agent story | Client libraries, vector store, MCP integrations | Native MCP server; agents generate new tools for themselves inside runtime-enforced permissions |
| Ecosystem | Supabase wins — SDKs for every framework, huge community, thousands of tutorials | Smaller — one team, one architecture |
| Postgres depth | Supabase wins — if you need Postgres extensions and expertise, their all-in bet is a feature | Postgres is one supported engine among four, not the platform's core identity |
| Managed option | Supabase Cloud — polished, mature | AINIRO cloudlets — same code as self-hosted, nothing gated |
Supabase security is row-level security: SQL policies written per table, per app. When a human writes the app, this works — the human understands the policy and knows which queries respect it. When an AI agent writes the app, every generated endpoint and query must correctly reimplement those assumptions. The security boundary lives inside the generated code, which means every generation is a new opportunity to get it wrong: a service-role key where an anon key belonged, a query that silently sidesteps a policy, a check that a generation simply forgot. The model does not have to be malicious. It has to be wrong once.
Magic inverts this. Hyperlambda is not text that gets executed — it is an AST, and every node must bind to a slot the runtime exposes. Endpoints declare the roles that may invoke them, and whitelisting constrains exactly which capabilities a piece of code can bind to at all. An agent generating code on a Magic backend cannot generate its way out of its permissions — the worst a bad generation can do is fail, structurally, before execution. Security stops being a property of each generated app and becomes a property of the runtime, implemented once, deterministically.
The deep dive is in why secure AI code execution requires runtime whitelisting — and there is a standing $100 bounty on breaking the sandbox. Nobody has.
This carbon calculator is a complete application on a Magic cloudlet — SQLite database, public and role-gated API endpoints, and the frontend itself, all served from one system. An AI agent built it autonomously during a live client meeting: database, endpoints, SPA — deployed and smoke-tested before the call ended.
That is the full-stack half of the Supabase comparison in one screenshot: the parts Supabase covers, plus the frontend it does not, built by an agent the platform could safely let build.
You need PostgreSQL specifically. If you depend on Postgres extensions, replication topology, or a DBA team that knows it deeply, Supabase’s all-in bet on Postgres is a feature. Magic supports Postgres as one engine among four; it is not a Postgres-native platform.
You rely on the ecosystem. Client SDKs for every framework, auth helpers, community extensions, an enormous volume of examples. That gravity is real, and if your team’s velocity comes from it, do not give it up lightly.
You want a managed service with a huge community. Supabase Cloud is genuinely good. The pain described on this page is specifically the self-hosted path — if you were never going to self-host, most of this comparison does not apply to you.
Magic connects to external PostgreSQL databases — including the one under your Supabase project. Point a cloudlet at it, and Magic generates endpoints, agents, and tools on top of your existing schema without moving a byte. Evaluation does not require migration, and neither does coexistence: plenty of sensible architectures run Supabase for what it does well and Magic for the agent layer. The step-by-step is in how to run AI agents on your existing Supabase database.
The full-length evaluation this page condenses — architecture, RLS-vs-runtime access control, and when to pick which.
Point Magic at the Postgres under your Supabase project and generate the agent layer on top — step by step.
Watch an agent build a complete, role-secured CRM — the concrete demonstration of everything this page argues.
Yes. The entire platform is MIT-licensed — database layer, CRUD generation, auth, RBAC, AI features, and the dashboard. There is no enterprise edition holding features back and no platform flag disabling functionality when you self-host.
Yes, and self-hosting is the primary deployment model, not a community afterthought. One Docker command brings up the full stack, and the self-hosted version is the same code the hosted cloudlets run — nothing gated.
Yes. SQLite is built in, and you can connect PostgreSQL, MySQL, and Microsoft SQL Server. Once connected, the platform treats an external database like a local one for querying, design, and code generation — including a Supabase project’s underlying Postgres.
For most applications, yes, with a different model. Magic ships JWT authentication, full OIDC and OAuth support, and role-based access control enforced by the runtime at execution time. Where Supabase expresses row-level rules in per-app SQL policies, Magic expresses access rules as endpoint and slot-level constraints — and row-shaped filters are implemented in the generated endpoint, enforced server-side.
Yes, natively. Magic includes an MCP server, so Claude and any MCP-capable agent can connect directly and use the platform’s tools — creating databases, generating endpoints, managing files, scheduling tasks — inside the RBAC boundaries of the authenticated user. Agents can also generate new tools for themselves through the Hyperlambda Generator.
Yes. AINIRO runs hosted cloudlets with the same codebase as the self-hosted version — no feature differences, because there is nothing gated to gate.
No. Magic can connect to a Supabase project’s underlying PostgreSQL database and generate agents, endpoints, and tools on top of it without moving anything. Many teams run both while they evaluate.
The whole platform — database, generated APIs, auth, frontend hosting, and the MCP server — on your own hardware, MIT-licensed. Still evaluating? The n8n and PocketBase matrices are written the same honest way as this page.
Hyperlambda
# When it’s up: log in at http://localhost:5555 with root/root.
$ curl -fsSL https://hyperlambda.dev/docker-compose.yaml | docker compose -f - up