/comparison/ · Cratefield next to the alternatives
Cratefield next to Supabase, Vercel, Railway and Firebase.
Cratefield is the backend you would otherwise have to build. Every app you make gets a database of its own, sending data to your users costs nothing, and the code is open source, so you can take it with you.
Here it is beside four backends people often choose instead, with InsForge and hosted Postgres joining them in the fair list below. Each of them is better than us at something, and that is named further down. Our hosted service is not running yet, so its column is what it is being built to be; the open-source half you can run yourself today. The other four columns are each company's own published behaviour and prices, checked September 2026.
Coming from Supabase? Step 1 shipping
Users with their passwords, tables with PostGIS, files into R2, and a switch you can undo. Not one click yet: the read-only first step runs today from source, the other four are designed.
The short version
Four things Cratefield does differently.
01
The pieces are already written Shipping
A waitlist with its confirmation emails, sign-ups with double opt-in, a content store with an editor. You add the crate; the routes and the pages come with it, inside your backend rather than beside it. The modules, one by one.
02
Every app gets its own database Shipping
One customer's data sits where no other customer's app can reach it. You do not set that up, so you cannot forget to. How the boundary works.
03
No bill for data going out Shipping
A Harness backend runs on Cloudflare, which makes no charge for sending data to your users. The four below all charge for it, some from the first gigabyte.
04
Yours to take away Shipping
Every piece is MIT licensed, one command writes your data back out, and the same backend runs on a machine of your own. How it is built.
Side by side
The six things worth comparing.
| Question | Cratefield | Supabase | Vercel | Railway | Firebase |
|---|---|---|---|---|---|
| Features you do not have to build | Shipping Sign-in with passkeys or Google. A waitlist with its confirmation emails, positions and referral codes. Sign-ups with double opt-in and unsubscribe. A content store with an editor. Notifications, webhooks, telemetry and more — 17 published modules, each adding its own pages | Sign-in, an API over your tables, file storage and live updates. The waitlist, its emails and its admin page you write | Hosting, and templates to start from. The features are yours to write | One-click deploys of ready-made apps, running alongside yours | Sign-in, a database, file storage and functions. The features are yours to write |
| A database of its own for every app | Yes, one per app | One database for all your customers, with rules that decide who sees which rows. Or a separate project each | Something you do in your own code | One container per service | One shared database, with rules that decide who sees what |
| Charged for data going out | No charge | 250 GB included on Pro, then $0.09/GB | Yes, billed as bandwidth | Yes, $0.05/GB from the first byte | Yes, at Google Cloud rates |
| What an app nobody is using costs | Its storage, and nothing else | Paid projects stay up; free ones pause after a week idle | Functions cost nothing while idle | The memory and CPU it holds, while it is up | Functions cost nothing while idle; the database bills per operation |
| Open source | Yes, MIT. Run it yourself | Yes, the platform is open source | No | No | No |
| Can you use it today | Planned Not the hosted service. The open-source half runs today | Yes | Yes | Yes | Yes |
supabase.com/
Being fair
When one of the others is the better answer.
- Supabase, when you want a database with an API, sign-in and live updates working this afternoon, a large community around it, and SQL you already know. It is the faster start, and its free tier is generous. The long version, row by row. Already on Supabase? How a move would work, step by step.
- Vercel, when the project is mostly frontend. Next.js, a preview of every change, the nicest frontend experience there is. Cratefield is a backend, not somewhere to put your frontend, and the two sit together fine.
- Railway, when you want to run whatever you like, in any language, and you do not need a separate database for each customer. It is simpler when that is not the point.
- Firebase, when you are building a phone app that needs live updates, works offline, and wants ready-made libraries for it. Those libraries are hard to beat. The long version, row by row.
- InsForge, when you want the closest open-source peer: Postgres, PostgREST, Deno functions and a model gateway, with a hosted service running today and an MCP server for coding agents. The long version, row by row.
- Hosted Postgres (Neon, RDS and the like), when you already have an application tier and only need the database done well. The long version, row by row.
Pick Cratefield when you want every app to come with a database of its own, nothing to pay for data going out, and code you could walk away with — and you are comfortable that the hosted service is not there yet, so today you run the open-source half yourself.