Mandala and backend services.
A backend service gives a frontend everything behind it: a database, sign-in, files, realtime, functions, and SDKs to reach them. That is the job Mandala means to do. These five do it today, and for a public application they are well ahead. Mandala’s difference is where the rules live and what is remembered.
Checked 12 October 2026
Five complete backends.
A real Postgres database with everything around it: sign-in with passwords, magic links, many social providers and MFA, row-level security, realtime, file storage, edge functions, generated REST and GraphQL, vector search, and SDKs for web and mobile.
Google’s app platform, strongest on mobile: document and realtime databases, a managed PostgreSQL option, sign-in, security rules, storage, functions, hosting and messaging, with SDKs for Apple, Android, web, Flutter and games.
A reactive database where queries and mutations are TypeScript functions and every screen updates by itself. End-to-end types, scheduled functions, cron, file storage, full-text and vector search.
An open-source all-in-one backend: sign-in with many providers and MFA, databases, storage, functions, messaging, realtime and site hosting, with a long list of client and server SDKs. The self-hosted edition has the cloud’s features.
A whole backend in one executable with an embedded SQLite database: sign-in, access rules per collection, realtime, files, an admin dashboard, a rate limiter and backups. A personal open-source project, and the closest in shape to Mandala.
As of October 2026, from each project’s own site, documentation and repository. Feature stages move quickly on all five.
Access rules, or the rules of the business.
A backend service protects rows: who may read this, who may write that. That is row-level security, security rules, collection rules, or checks in your functions. The business logic itself, that an order needs every item packed before it ships, lives in code you write around it.
In Mandala there is one text. The contract says what the record is, what each action requires and who may take it, and nothing reaches storage any other way. Then it keeps every accepted change as a fact signed by whoever made it.
These services offer audit logs of their platform and point-in-time recovery, some as paid options. We found none with a built-in, signed, per-change history of your data. In Mandala that history is the data.
Mandala’s accomplice acts through the same contracts as your users, and can’t do what they forbid.
# Nothing ships to the Moon, or over 200 units,# without a second person confirming (Leela).action Ship() authorize dhl validate state.paid or state.credit_terms state.crates_checked == state.crates state.status == Requested or state.status == Confirmed state.status == Confirmed or state.units <= 200 state.status == Confirmed or state.destination != "Moon" apply state.status = Shipped
The whole contract (65 lines)
aggregate Delivery state public customer: Text(len=200) public destination: Text(len=100) public units: Int = 0 public crates: Int = 0 public crates_checked: Int = 0 public paid: Bool = false public credit_terms: Bool = false public requested_by: Identity public confirmed_by: Identity public status: Enum(New, Requested, Confirmed, Shipped) = New action Request(customer: Text(len=200), destination: Text(len=100), units: Int, crates: Int, credit_terms: Bool) authorize dhl validate state.status == New units > 0 crates > 0 apply state.customer = customer state.destination = destination state.units = units state.crates = crates state.credit_terms = credit_terms state.requested_by = context.signer state.status = Requested action CheckCrate() authorize dhl validate state.status == Requested state.crates_checked < state.crates apply state.crates_checked = state.crates_checked + 1 action Confirm() authorize dhl validate state.status == Requested context.signer != state.requested_by apply state.confirmed_by = context.signer state.status = Confirmed action Pay() authorize dhl validate state.status != New state.paid == false apply state.paid = true # Nothing ships to the Moon, or over 200 units,# without a second person confirming (Leela).action Ship() authorize dhl validate state.paid or state.credit_terms state.crates_checked == state.crates state.status == Requested or state.status == Confirmed state.status == Confirmed or state.units <= 200 state.status == Confirmed or state.destination != "Moon" apply state.status = Shipped
Real DHL, exactly as it runs: this contract compiles. Every action is checked against it before it happens, for people and AI alike.
Where they differ.
| Backend services | Mandala | |
|---|---|---|
| Where it runs | The vendor’s cloud for all but PocketBase. Supabase, Convex and Appwrite can also be self-hosted; Firebase cannot | Your own machine or server only, as one program |
| Data | Postgres (Supabase), documents (Firebase, Convex), a choice of databases (Appwrite), SQLite (PocketBase) | works today Signed facts; tables and views derived from them. No SQL |
| Rules | Access rules on rows or collections, plus your own functions | works today Contracts: state, actions, validation and delegation, checked before every write |
| API | Generated or SDK-based, with typed clients on several | works today REST, GraphQL and gRPC generated per contract. No typed client yet |
| History of changes | Platform audit logs and point-in-time recovery | works today Every change, signed, kept |
| Sign-in for your users | Built in on all five: passwords, OAuth providers, and more | on the roadmap Not built. Guest sessions exist in a storefront preview |
| SDKs | Web on all; mobile on most; many languages on Appwrite and Supabase | on the roadmap None. You call the API yourself |
| Realtime | Built in on all five | designed Live queries are designed, not built |
| Files | Built in on all five | on the roadmap No file type, no public delivery |
| Functions, schedules | Server functions or hooks on all; cron or scheduled functions on most | built, not released Email and PDF as declared effects, in the engine. Schedules declared by a contract are on the roadmap |
| Search by meaning | Vector search on Supabase, Firebase and Convex | built, not released Text search works today; vector search is on a branch |
The full list of what a backend has to do, with Mandala’s status for each, is on Mandala vs web frameworks.
Said plainly.
With any of these you have sign-in, a database and an SDK in your frontend within an hour. With Mandala you have contracts and an API, and you write the client.
User sign-in, file delivery, rate limits and realtime are what a public app needs first. All five have them. Mandala has none of them released.
It is also one self-hosted program with embedded storage, and it already ships sign-in, files, realtime, an admin screen and two SDKs. If that shape is what drew you here and you need it now, use PocketBase.
Firebase, Supabase and Appwrite have native mobile SDKs. Mandala has none.
Managed backups, regions, dashboards and support plans come with the hosted services. With Mandala, you are the operator.
Choose honestly.
Choose a backend service if…
- You are shipping a public app that needs user sign-in and client SDKs now.
- You want SQL and the Postgres ecosystem: Supabase.
- You are building for phones first: Firebase.
- You are a TypeScript team building something live and collaborative: Convex.
- You want open source, self-hosted, with everything included: Appwrite, or PocketBase for something small.
Choose Mandala if…
- The business rules are the hard part, and you want them in one readable place that nothing can bypass.
- You must be able to show who did what, for whom, under which rule, for every change.
- An AI will act in the system and has to be held by the same rules.
- Your users are few and known for now, and you can wait for public sign-in and SDKs.
Mandala vs web frameworks has the frontend side of this, and a storefront that runs on contracts today. For developers
We checked every statement about other products on 12 October 2026, against their own sites, documentation and repositories where we could. Products change. If something here is wrong or out of date, write to hello@getmandala.org and we’ll correct it.