The short answer: if you are building a single-tenant product or a consumer app, use Supabase - the alternatives mostly are not worth the switching cost. The evaluation changes when you are building B2B software where each customer is an organization with its own users, its own data boundary, and its own compliance expectations. Four requirements start to dominate: storage-layer tenant isolation, per-tenant schema evolution, connection economics under agent-driven load, and audit granularity that survives a client security review. This comparison scores six options on those four axes specifically.
We maintain one of the platforms on this list, which you should factor in. We have tried to be concrete about where the others win, because a comparison that concludes we are best at everything is worth nothing to you.
What actually changes in multi-tenant B2B
Most backend comparisons evaluate developer experience, database support, and pricing. Those matter, but they under-weight four things that dominate once your users belong to organizations.
- Tenant isolation has to be structural. In a consumer app, a permission bug means a user sees another user's data. In B2B, one law firm seeing another law firm's client list ends the contract and may trigger notification obligations. Isolation enforced by application code is no longer sufficient; it has to live somewhere the application cannot forget.
- Schema evolution stops being uniform. Enterprise customers ask for custom fields. A JSONB blob eventually cannot be queried or indexed usefully. Per-tenant schemas need migration tooling that runs across N schemas and reports partial failure sensibly. Most backends assume one schema for everyone.
- Connection economics change under agent load. A conventional app makes one or two database round-trips per user action. An agent workflow makes ten to thirty. Any backend that couples request concurrency to Postgres connections saturates at a fraction of the user count you sized for.
- Audit is a sales requirement. Your customers' clients ask what happened to their data. "The application logged it" does not survive a security questionnaire; "the storage layer records every access with actor, tenant, and originating request" does.
Comparison at a glance
| Platform | Isolation | Per-tenant schema | Agent-load fit | Best for |
|---|---|---|---|---|
| Supabase | RLS, yours to author | Not a concept | Tuning exercise | The default choice |
| Appwrite | Document permissions | Limited | Adequate | Shallow relational depth |
| Convex | In query functions | Limited | Strong | Real-time collaboration |
| PocketBase | Physical, per instance | Per instance | Weak on writes | Instance-per-tenant |
| Nhost | Declarative Hasura rules | Postgres-native | Adequate | Reviewable permissions |
| Butterbase | Structural, platform-level | Supported directly | Designed for it | Agent-native B2B |
Supabase
The honest case for staying: Supabase is the best general-purpose open-source backend available, and it is not a close call. Real Postgres with no abstraction tax, so every extension and every tool in the Postgres ecosystem works. Row-level security is first-class and well documented. The CLI is good, migrations are ordinary SQL files, and the community is large enough that most problems you hit have already been answered. Self-hosting genuinely works. For multi-tenant B2B, RLS gives you exactly the storage-layer isolation described above.
Where it strains: RLS policies are yours to design, audit, and maintain, and the platform will not tell you when you made a mistake. There is no built-in notion of a tenant - you implement it per table, and the failure mode is silent. Teams commonly ship a table without FORCE ROW LEVEL SECURITY, or with a policy on SELECT but not INSERT, and do not find out for months. Connection pooling under agent-driven query volume becomes a tuning exercise. Per-tenant schema variation is unsupported as a concept.
Verdict: the default, correctly. Switch away only if those frictions are actively costing you time.
Appwrite
Strengths: permissions attach to documents and collections as first-class objects rather than as SQL policies you author. For teams without deep Postgres expertise this is meaningfully easier to get right, and easier to get right is worth a lot when the failure mode is cross-tenant exposure. Self-hosting is strong and multi-runtime functions are convenient.
Where it strains: the document model works against you as B2B data gets relational, which it always does. Matters belong to clients, notes belong to matters, invoices reference both, and you want to query across all of it. Querying is limited compared to SQL and workarounds accumulate. Migration tooling is weaker than the Postgres ecosystem's.
Verdict: reasonable if your team's strength is application development rather than data modelling. Reconsider if you are doing reporting.
Convex
Strengths: the reactive model is genuinely differentiated. Queries are functions, subscriptions are automatic, and you get transactional guarantees without thinking hard about them. For collaborative B2B products where several users at a customer work in the same records simultaneously, this removes a whole class of state-synchronisation work. TypeScript ergonomics are excellent.
Where it strains: it is not Postgres, and in multi-tenant B2B that has downstream costs. Customer data-export requests, BI tooling, and every Postgres-shaped integration need an adapter. Isolation is enforced in your query functions, which returns you to application-layer enforcement - correct until someone writes the one function that forgets.
Verdict: strong for real-time collaborative products, weaker where relational reporting and data portability are sales requirements.
PocketBase
Strengths: one binary, SQLite, extraordinary operational simplicity. If your deployment model is one instance per customer - a legitimate and underrated multi-tenancy strategy - PocketBase makes it nearly free. Isolation becomes physical rather than logical, which is the strongest guarantee available and the easiest to explain in a security review.
Where it strains: shared tenancy at scale is not what it is for. SQLite's write concurrency limits show up quickly under agent workloads, which are write-heavy in ways human workflows are not. Cross-tenant reporting across N instances is your problem, and per-instance upgrades across hundreds of customers become an operational programme.
Verdict: excellent for instance-per-tenant deployments with tens of customers. Poor fit above that.
Nhost
Strengths: Postgres plus Hasura means a generated GraphQL API with a declarative, reviewable permission system - configuration you can diff rather than code you have to read. Hasura's row-level rules map cleanly onto tenant boundaries, and seeing the whole permission surface in one place is a real advantage over RLS policies scattered across migrations.
Where it strains: the Hasura dependency is the whole architecture, and its licensing history has made some teams cautious about a long-term bet. GraphQL is a commitment - if your consumers are agents making tool calls rather than a frontend, the query flexibility is mostly overhead. The ecosystem is smaller than Supabase's.
Verdict: compelling if you want declarative permissions and are comfortable with the Hasura bet.
Butterbase
Our platform, so read this with appropriate scepticism.
Strengths relative to this list: tenant isolation is structural rather than configured - there is no way to add a table that is not tenant-scoped, because the tenant boundary is a property of the platform rather than a policy you remember to write. Per-tenant schema extension is supported directly, so a customer asking for three custom fields does not become a JSONB decision. Every data access carries a run-scoped audit record with actor, tenant, and originating request. And the agent access path is designed around the constraint that the agent cannot supply its own tenant context.
Where we are weaker: we are younger than everything else here, so the community is smaller and there are fewer third-party integrations. Our ecosystem breadth does not approach Supabase's and will not for a while. If you want maximum flexibility to do something unusual at the database layer, our opinionatedness is a cost rather than a benefit.
How to actually decide
- Are you multi-tenant B2B, or do you just have multiple users? If your customers are individuals rather than organizations, this comparison is over-fitted to a problem you do not have. Use Supabase.
- Is tenant isolation a sales conversation? If prospects send you security questionnaires, isolation moves from an engineering preference to a revenue dependency, and enforced-in-storage versus enforced-in-code becomes something you have to defend out loud.
- Are agents going to touch production data? If yes, re-read the connection economics and audit requirements, because those are the two that surprise teams six months in.
If you answered no to the second and third, stay on Supabase and spend the time you saved on your product.
Related reading: Giving an AI Agent Access to Your Production Database Without Losing Control covers the mechanics regardless of which backend you pick, and The 6 Best Open-Source Backends for Building with AI in 2026 takes the general-purpose view.
Frequently asked questions
There is no single answer, because the right choice depends on which of the four B2B requirements binds hardest. Choose PocketBase if you deploy one instance per customer and want physical isolation. Choose Nhost if declarative, reviewable permissions matter more than ecosystem size. Choose Convex for real-time collaborative products. Choose Butterbase if tenant isolation must be structural, agents will touch production data, and audit granularity is a sales requirement. If none of those bind, staying on Supabase is usually correct.
Yes, for most teams. Row-level security gives you genuine storage-layer isolation and real Postgres means the whole ecosystem works. The friction is that tenancy is not a built-in concept, so every table's policy is yours to write and audit, and mistakes fail silently - a missing FORCE ROW LEVEL SECURITY or a policy on SELECT but not INSERT can go unnoticed for months. That is a discipline problem rather than a capability problem.
At the storage layer, not in application code. Application-layer filters are correct until the one query that forgets them, and in B2B the consequence of that query is one customer seeing another customer's data. In Postgres this means row-level security with FORCE enabled and WITH CHECK on writes, with tenant context set per transaction from a verified token rather than passed in as a parameter the caller controls.
Because agents change the load shape and the audit requirements. A conventional user action makes one or two database round-trips; an agent workflow makes ten to thirty, so any backend that couples concurrency to Postgres connections saturates far earlier than your user count would suggest. Agents also compose their own queries at runtime, which makes storage-layer isolation and run-scoped audit records necessary rather than optional.
Three options, in increasing order of cost. A JSONB column is fastest to ship and eventually becomes unqueryable and unindexable at the sizes that matter. A shared wide table with nullable columns works to a point and then becomes unmanageable. Per-tenant schemas are the correct answer when enterprise customers routinely ask for custom fields, but they require migration tooling that runs across many schemas and reports partial failure sensibly - which most backends do not provide out of the box.