CrescoDB vs PocketBase
This is the comparison we get asked about most, and the one where we have to be most careful, because PocketBase is genuinely excellent and it is free. Both of us reject the same premise — that your backend has to live in somebody else's cloud. The differences are real but they are narrower than any of the others on this list.
The quick answer
\nSkip to the bottom line — then dig into the workflow below.
\nChoose CrescoDB if you…
\n- \n
- expect to outgrow SQLite — the same schema and API run on PostgreSQL and MySQL \n
- want the schema to be a file you write and commit, not a dashboard that emits one \n
- want working code in your repo —
cresco create authwrites register.js and login.js \n - want an MCP server so your coding agent can drive the whole thing \n
- want managed deploys, restore-verified backups and alerts as an option \n
Choose PocketBase if you…
\n- \n
- want one binary and no runtime — no Node, no npm, nothing to install \n
- want it genuinely open source (MIT) with no company in the loop at all \n
- want it to be free, permanently, with no plan above it \n
- are happy with SQLite and know your app fits on one machine \n
- would rather extend a backend in Go than in JavaScript \n
Side by side
\nBoth do more than fits here. This is where they actually diverge.
\n| Capability | CrescoDB | PocketBase |
|---|---|---|
| Runs without a cloud account | ✓ | ✓ — this is the shared premise |
| Runtime needed | Node 20+ for the CLI | ✓ none — one static binary |
| Databases | SQLite, PostgreSQL, MySQL | SQLite only |
| Path when you outgrow SQLite | Change one line; same schema, same API | Rewrite onto something else |
| Horizontal scaling | Postgres/MySQL behind several app nodes | ✕ single node, vertical only |
| Where the schema lives | ✓ schema.cresco, in git, human-readable | Dashboard UI, emitted to pb_migrations |
| Migrations | SQL files you write, checksummed; refuses to boot on drift | JS files generated from the UI |
| Generates app code you own | ✓ cresco create auth|blog|payments | ✕ you write against its API |
| Instant REST API | ✓ | ✓ |
| Realtime | ✓ (SSE) | ✓ (SSE) |
| Auth + rules | ✓ per-table RBAC | ✓ collection API rules |
| File storage | ✓ local or S3 | ✓ local or S3 |
| Admin dashboard | ✓ | ✓ built into the binary |
| Extend it in | JavaScript / any language over HTTP | Go or JavaScript hooks |
| MCP server for AI agents | ✓ cresco mcp | ✕ |
| Licence | MIT (CLI & engine) | ✓ MIT, fully open source |
| Version | 1.x | 0.x — 1.0 not yet released |
| Price | Free locally; paid plans for deploys & backups | ✓ free |
Where the schema lives, and why we think it matters
\nThis is the real philosophical split, and it is worth more than any row in that table.
\nCrescoDB
\n- \n
- You write
schema.cresco, a plain JSON file, in your editor. \n - It is in git. It reviews in a pull request. It diffs. \n
- Two developers on two machines converge because they merged a file. \n
- Production refuses to boot if the real database does not match it. \n
PocketBase
\n- \n
- You design collections in the admin UI. \n
- PocketBase writes a JS migration into
pb_migrations, which you commit. \n - That file is generated output — reviewable, but not really editable by hand. \n
- The source of truth is the running instance you clicked in. \n
Neither is wrong. PocketBase's way is faster for one person\n moving quickly, and the UI is better than most paid dashboards. Ours is better when the schema is\n something a team argues about in review, or when you want to diff what changed between two releases\n without reading generated JavaScript.
\n', '\nThe honest bottom line
\nUse PocketBase if you want one file on a server and nothing else — no runtime, no company, no plan. It is MIT, it is free, it has been used in production by a lot of people for years, and the single-binary story is genuinely better than ours. If that is what you are optimising for, take it, and you will not regret it.
\nUse CrescoDB if the SQLite ceiling worries you, if you want the schema to be a file your team reviews rather than a dashboard someone clicked, or if you want the backend written into your repo as code you can read and edit. Those are the three things we do that PocketBase does not.
\nTwo caveats in each direction, so you have the whole picture. PocketBase's own docs say it is pre-1.0 and does not guarantee backward compatibility yet, and SQLite means one node. CrescoDB needs Node installed, is built by a much smaller team, and has paid plans above the free local tier where PocketBase has none. Pick the trade you would rather live with.
\nTry CrescoDB in 30 seconds
No account, no cloud project. One command.