Hyperlambda
Earlier this week I published an honest feature matrix against n8n. That one was easy mode, honestly — n8n and Magic are barely in the same category, so most rows were category differences wearing feature costumes.
This one is hard mode. PocketBase is the closest architectural sibling Magic has. Same MIT license, all of it, nothing gated. Same SQLite-first instinct. Same self-hosted-first philosophy. Same "the whole backend in one box" architecture. If you lined up every backend platform on Earth and asked which one shares the most DNA with Magic, PocketBase is the answer — and it is a genuinely excellent piece of software.
Which makes the interesting question the one the matrix has to answer: if the DNA is that similar, where do they diverge, and why?
One sentence of thesis before the table: PocketBase and Magic made opposite bets on who extends the backend. PocketBase bet on a human with a Go compiler. Magic bet on an AI agent with a prompt. Watch the rows cluster around that bet.
The matrix
| Feature | PocketBase | Magic Cloud |
|---|---|---|
| License | MIT, everything — explicitly including offering it as a paid service | MIT, everything — dead-even row |
| Deployment unit | One Go binary, zero dependencies, no Docker required | Docker containers — backend and dashboard |
| Footprint | Tens of megabytes, runs on nearly anything | Heavier — a .NET runtime underneath |
| Database | Embedded SQLite only | SQLite by default, plus SQL Server, MySQL, PostgreSQL |
| Schema management | Visual collection builder in the admin UI, automatic migrations | Dashboard, SQL, or agent-driven DDL over MCP |
| API generation | Automatic REST API per collection | Generated CRUD endpoints per table — real files you can open, read, and customize |
| Custom business logic | Write Go and recompile, or JavaScript hooks (ES5, in a VM) | Inject custom logic directly into generated CRUD endpoints, or describe a new endpoint and the Hyperlambda Generator writes it — live in production, no compile, no deploy |
| Realtime | Native SSE subscriptions — automatic per-collection record-change events, zero code | SignalR — publish events from writes, tasks, or any logic; programmable rather than automatic |
| Auth | Email/password plus a turnkey OAuth2 provider list (Google, GitHub, and friends) | Full OIDC and OAuth support, JWT, users, roles |
| Access control | Declarative per-collection API rules as filter expressions | Endpoint-level role gating plus runtime slot whitelisting |
| Code execution safety | Hooks run arbitrary Go or JavaScript — full trust | Whitelisted slots — generated code structurally cannot exceed its permissions |
| File storage | Built in, with thumbnail generation | Server-side file system, upload tickets, image resize and convert |
| Frontend hosting | Serves static files, but hosting is not the story | First-class static and SPA hosting per cloudlet |
| Client SDKs | Official JavaScript and Dart SDKs, genuinely polished | None — you consume plain REST with OpenAPI specs |
| Scheduling | Cron hooks, written in code | Persistent task scheduler, drivable by agents over MCP |
| AI and RAG | None | ML types, website crawling, native vectorization, deployable chatbots |
| MCP and agents | Third-party community MCP servers doing record and collection CRUD; the capable one is paid and defaults to read-only | Native MCP server; agents generate new tools for themselves at runtime, inside RBAC |
| Extending means redeploying? | Yes for Go; JS hooks reload, but you are writing ES5 in a VM | No — generation is live in production |
| Write scalability | Single-writer SQLite ceiling | Same ceiling on SQLite — but moving to PostgreSQL or SQL Server is a configuration change, not a platform migration |
| Managed hosting | None — self-host only | AINIRO runs hosted cloudlets |
| Community | Large, active, and deservedly beloved | Small |
Where PocketBase wins, stated plainly
Deployment simplicity. A single binary with zero dependencies is a genuinely better story than Docker containers. Download one file, run one command, backend is live — no container runtime, no compose file, nothing to orchestrate. For a laptop, a $5 VPS, or air-gapped infrastructure, PocketBase's deployment story is the best in the entire category, and I include Magic in that sentence.
Client SDKs. The official JavaScript and Dart SDKs are polished, typed, and maintained. Magic gives you REST and an OpenAPI spec, which is fine — but "fine" is not an SDK that autocompletes in your editor and handles auth token refresh for you.
Turnkey realtime for the vanilla case. If your need is "tell the client when this record changes," PocketBase does it declaratively with zero code. Magic's SignalR model covers that case too, but you publish the event yourself — more power, more typing. For the plain case, PocketBase's ergonomics win.
Consumer OAuth ergonomics. PocketBase's OAuth2 provider list is a checkbox UI. Magic speaks full OIDC and OAuth — the more capable protocol surface — but PocketBase makes "sign in with GitHub" a two-minute job.
Community. Larger, older in its niche, and full of people who love it for good reasons. Ecosystem gravity is real, and it is not on my side of this table.
Per the rules of this series: no rebuttals in this section. They live below.
Where the opposite bets diverge
The extension model is the whole ballgame. When you outgrow what PocketBase generates for you, the platform's answer is: write code. Go with a recompile, or ES5 JavaScript executing in an embedded VM. That is a fine answer for the developer PocketBase was designed for. But notice what it assumes — that the person extending the backend has a compiler, knows the hook system, and ships a deploy for every change.
Magic's answer has three tiers, and none of them require any of that. Take the generated CRUD as-is. Or inject custom business logic directly into the generated endpoints — they are readable files, not black boxes. Or describe an entirely new endpoint in plain language and the Hyperlambda Generator produces it — saved, secured, live, without a compile step or a deploy cycle. This is the same catalog-versus-generator asymmetry the n8n article was built on, wearing different clothes: PocketBase enumerates what you can do without code, and everything past the enumeration costs a compiler. Magic generates.
The escape hatch. PocketBase's all-in bet on embedded SQLite is a huge part of its simplicity — and a wall. SQLite is single-writer; when your write throughput outgrows it, outgrowing SQLite means outgrowing PocketBase, and your exit is a migration to a different platform. Magic starts on SQLite for the same good reasons, but the day you need PostgreSQL or SQL Server, that is a connection string, not a farewell letter. You keep the platform, the generated endpoints, the auth, the frontend. Your 25-year-old legacy database is welcome too.
The agent story, which is really a security story. Here is the widest gap in the matrix, and the one that follows directly from the opposite bets. PocketBase has no native MCP server — what exists is third-party tooling doing record and collection CRUD against the API, with the capable option paid and defaulting to read-only. And that read-only default is not timidity. It is the correct engineering response to PocketBase's trust model: hooks and extensions run with full trust, so there is no runtime boundary that makes agent-written code safe. The only safe agent is a spectator.
Magic was built the other way around. Hyperlambda executes as an AST where every node must bind to a whitelisted slot — an agent generating code on a Magic backend cannot generate its way past its permissions, because the runtime, not the prompt, holds the keys. That is why Magic's agents hold production credentials and build things — new endpoints, new integrations, new tools for themselves — while PocketBase's agents read records. There is a standing $100 bounty on proving that boundary wrong.
Realtime, called fairly. I put this row as a model difference rather than a win, and I mean it. Declarative auto-subscriptions (PocketBase) are better ergonomics for record-change notifications. Programmable events (Magic's SignalR) express things auto-subscriptions cannot — domain events, computed notifications, events fired from scheduled tasks or agent-generated logic. Which model you want depends on which sentence describes your app.
The decision rule
Choose PocketBase if: you are a developer shipping an MVP, a mobile backend, or a side project; you want the simplest possible deployment on Earth; the JS or Dart SDK matches your stack; and you are comfortable that custom logic means writing Go or JS. In that lane it is superb, and picking Magic instead would buy you complexity you do not need yet.
Choose Magic if: you expect to outgrow SQLite without wanting to outgrow your platform; you need enterprise identity (OIDC), real frontend hosting, or RAG; or — the structural one — you expect AI agents to be building and operating the backend. PocketBase was designed before that question existed. Magic was designed as the answer to it.
The test that decides it in one question: who writes your next endpoint — a human with a compiler, or an agent with a prompt? Answer that and the matrix answers itself.
The fine print
What the table does not capture: PocketBase's community momentum compounds; its simplicity is a feature you feel every single day; and "small community" is a cost I pay on my side of the table every single day too. PocketBase also ships breaking changes at a healthy clip — the specifics above (JSVM behavior, provider lists, MCP tooling) were verified the day this was published, and if you are reading this much later, re-verify before quoting.
Magic is MIT-licensed and open source — the repository is at github.com/polterguy/magic, with documentation at docs.ainiro.io. Testing the generator-versus-compiler thesis yourself takes one copy-paste on a $6 DigitalOcean droplet.
FAQ
Is Magic Cloud a PocketBase alternative?
Yes, more directly than any other comparison in this series. Both are MIT-licensed, self-hosted, SQLite-first backends shipping database, generated APIs, auth, and file handling in one system. The divergence is the extension model — code-and-compile versus generate-and-review — and the agent story that follows from it.
Which is easier to deploy?
PocketBase, full stop. One binary, no dependencies. Magic runs as Docker containers, which is more moving parts — the trade is that those containers include frontend hosting, multi-engine database support, an ML layer, and a native MCP server the binary does not.
Can PocketBase work with AI agents like Claude?
Through third-party MCP servers, yes — for querying and managing records and collections. What it lacks is a runtime permission model for agent-written code, which is why those tools sensibly default to read-only. Magic's whitelisted execution model is what lets agents safely generate and run new code in production.
Do both really use the same license?
Yes — both are MIT, with nothing held back. This is the rare comparison where licensing is a dead-even row, which is exactly why the interesting differences are architectural rather than legal.