AI App Builder Multi-Tenancy (2026): Per-User Is Not Per-Tenant

Quick Answer (September 2026). Every AI app builder on this board can make a user see only the rows they created. That is not multi-tenancy. Multi-tenancy is when Alice and Bob, who have never met, both work at Acme, and both must see all of Acme's records and none of Zenith's. The isolation key has to be something other than the current user's own identity, and that is where the field splits. Of the eight builders compared here, Lovable is the only one that documents organisation-scoped access as a named pattern. Base44 has a real row-level security engine but all eleven of its published examples scope to the individual user. Bubble and Softr enforce restrictions on the server and both are usable, with caveats. Replit and Bolt.new document nothing on this axis at all. v0 has no database of its own, so you inherit whatever you attach. Webflow retired its user system entirely on 29 January 2026 and is out of this category.

The distinction nobody makes

Search for multi-tenant data isolation and you will find a great deal of excellent writing about row-level security in Postgres, Laravel and AWS. Almost none of it is about AI app builders, and the one place the question is actually being asked, a thread on r/nocode titled "Has anyone used AI to build a multi tenant SaaS", answers itself in the comments: AI builders can scaffold basic models but miss the nuanced parts, row-level security and tenant context.

Tenant context is the phrase to hold on to. It names the gap precisely.

Consider the two shapes of access control that get conflated:

Per-user isolation. Each row belongs to the person who made it. A todo app, a personal notes tool, a habit tracker. The rule is a single comparison: does this row's owner field equal the person asking? Every builder here can do this, and most of their documentation stops at exactly this example.

Per-tenant isolation. Each row belongs to an organisation, and several people belong to that organisation. A B2B SaaS, an agency dashboard, a clinic scheduling system, a school portal. The rule is a join: does this row's organisation match the organisation of the person asking? Nobody owns the row personally. Alice did not create Bob's records and must see them anyway.

The second is what people mean when they say multi-tenant, and it is a materially harder thing to express. It requires a concept of membership that sits between the user and the data, and it requires that concept to be visible to whatever enforces access. A builder that only knows about users, and not about the groups users belong to, cannot express the rule at all.

This distinction also separates multi-tenancy from a neighbouring axis this site has already covered. Roles are about what a person is allowed to do inside one organisation, which is the subject of how these builders handle role-based access. Tenancy is about which organisation's data they can reach in the first place. A perfect role system with no tenant boundary will cheerfully let a well-behaved admin read every customer's records.

The comparison

Three places isolation can live, and only one of them is safe

The mechanism matters more than the feature checkbox, because the three layers fail differently.

In the database. The database itself refuses to return another tenant's rows. If your application code is wrong, if a generated query forgets its filter, if someone hits the API directly, the rows still do not come back. This is what row-level security means in Postgres, and it is the only layer that survives your own mistakes.

On the server, above the database. The platform filters results before they reach the browser. This is genuinely safe against a user tampering with the client, which is the attack most people worry about, and it is much better than nothing. It is not safe against the platform's own query builder being handed the wrong parameters.

In the application code. Every query carries a filter, and the filter is correct because whoever wrote it remembered. This is the default state of a generated codebase, and it is the weakest position of the three.

Builder by builder

Lovable: the only one that names the pattern

Lovable Cloud is built on Supabase's open-source foundation, so the underlying database is Postgres and the isolation mechanism is row-level security. Lovable's security documentation is direct about the stakes: "Row-level security (RLS) policies control which users can access or modify data in your database", and, plainly, "Misconfigured RLS rules are a common cause of data leaks" (Lovable security docs, 2026).

What separates Lovable from the rest of this board is one line in its best-practices guide. Among the common patterns it documents are "Team-based access: team members share access to team data" and "Organization-based access: users access data within their organization" (Lovable security best practices, 2026). That is the tenant rule, written down, as a supported shape. No other builder here publishes it.

Two caveats, and they are real. Lovable does not state anywhere that RLS is switched on automatically for new tables. Its pre-publish checklist asks you to confirm that "RLS is enabled on all sensitive tables" and that "New tables are not missing policies", which is only a meaningful instruction if new tables can in fact be missing them. And it warns about sequencing: "RLS is much easier to change before real data exists". Retrofitting a tenant boundary onto a live table is the expensive version of this job.

Lovable also ships scanning that targets this specific failure. Its basic scan includes RLS policy linting that "highlights overly permissive rules or missing access checks that could expose sensitive data", and the deep scan adds an access control review for "database functions that bypass row-level security".

Base44: a real engine, aimed at the wrong target

Base44 has the most explicitly documented permission system of any platform on this board that is not simply passing through to Postgres. Its entity security supports four rule types, "create, read, update, delete", with conditions expressed as JSON against the requesting user (Base44 entity security, 2026).

The problem is what the examples teach. Base44 publishes eleven worked RLS patterns: a todo app, a contact form, a user profile, department data, subscriptions, private data, a blog post, documents, employee records, orders, and bidirectional relationships (Base44 RLS examples, 2026). Every single one scopes to the individual, usually through a comparison of the form created_by equals user.email. Not one isolates by organisation, company, workspace or tenant.

The closest thing is the department pattern, which matches an attribute on the record against the same attribute on the user: "read": { "data.department": "{{user.data.department}}" }. That is genuinely the right shape, and it would work for tenancy if you treated an organisation identifier as a user attribute. But you are extrapolating from an example about departments, and Base44's documentation does not state what happens to an entity with no rules defined at all, which is the single most important default on the page.

So the engine can probably express tenancy. The documentation will not teach you to, and will not tell you what you get if you forget.

Bubble: server-enforced, and permissive by default

Bubble's Privacy Rules are the oldest and most battle-tested mechanism on this board, and Bubble is unusually clear about where they run: "Privacy rules instruct that server to only send data to the browser, or write to the database, if certain conditions are met", and "This is essential to app security because it's stopped on the server side. The data stays encrypted in the database instead of being sent to the browser, where it could be viewed" (Bubble manual, 2026).

The sentence that should govern your design is this one: "With privacy rules, you don't prohibit access, you grant it."

Read that carefully. It describes a model in which the starting position is exposure and every restriction is something you add. Bubble does not publish an explicit statement of what an unruled data type returns, but the grant-not-prohibit framing, combined with the instruction that "Any database data that's private or sensitive needs to be protected with privacy rules to be considered secure", points one way. On Bubble, a tenant boundary is a thing you build, not a thing you inherit.

Privacy Rules can express tenancy, because conditions can reference fields on the current user and traverse relationships. Bubble simply does not publish a worked multi-tenant example, so you are designing it yourself.

Softr: the strongest claim about enforcement

Softr is the one platform here that makes an unambiguous, competitive claim about where its restrictions run, and it is worth quoting in full because it addresses the exact failure mode that makes people nervous: restrictions are "all being performed server side (many alternatives do client-side hiding only), giving no chance to modify queries on the client side and access more data than the system is configured to expose" (Softr app security, 2026).

It goes further: "Softr viability checks and record conditional filters are applied on the server side, and there is no way to trick the system." Conditional filters are evaluated server side and Softr retrieves "only the records that the current user is eligible to see".

Softr's model is user groups rather than tenants, which is the closest native fit for tenancy on this board that is not row-level security. Its global data restrictions "instantly hide irrelevant or sensitive records across dynamic blocks, dropdown options and inline filters" (Softr global data restrictions, 2026).

One carve-out, published by Softr itself and worth knowing before you design around the feature: "Global Data Restrictions is not currently available for the Comments block." A restriction described as global that does not cover one block is a restriction with an exception, and comments are exactly the kind of place tenant data leaks.

Replit: nothing on this axis

Replit provides a fully managed SQL database, Postgres-based. Its documentation notes that "Prior to December 4th, 2025, the development database was hosted on Neon", so the infrastructure underneath has moved (Replit SQL database docs, 2026).

What the database documentation does not contain is any mention of row-level security, multi-tenancy or tenant isolation. The security guidance it does offer is application-layer and aimed at a different threat: schema validation that "verifies data conforms to expected formats" and data sanitisation that "automatically cleans up builder input to prevent SQL injection attacks".

This is an absence in the documentation, not a proven absence in the product. Postgres supports row-level security natively, and if you have direct SQL access you can write policies yourself. But nothing in Replit's own material will guide you to do it, and nothing suggests the platform's generated code is aware of a tenant concept.

Bolt.new: a complete index with nothing in it

Bolt.new reaches a database through its Supabase integration, and its documentation describes that integration in terms of authentication: Bolt can add authentication so that "users will be able to sign up for your application and log in using Supabase's user management service" (Bolt.new Supabase integration, 2026).

This claim is stronger than the usual absence finding, because the whole published index was read rather than sampled. Bolt.new's complete documentation index runs to ninety-four entries. Occurrences of row-level security, RLS, multi-tenancy or tenant: zero. Occurrences of data isolation: zero.

Supabase underneath Bolt has row-level security, exactly as it does underneath Lovable. The difference is that Lovable documents the patterns, ships a linter that checks them, and names organisation-based access as a supported shape, while Bolt documents the login button. If you build a multi-tenant app on Bolt, the security model is entirely yours, and you will be reading Supabase's documentation rather than Bolt's.

v0: you inherit whatever you bring

v0 does not have a database. It generates a Next.js application and connects to services from the Vercel Marketplace, "starting with Upstash, Neon, and Supabase", installed from the project sidebar or from within the chat (Vercel changelog, 2026).

This makes v0 the hardest row to score and, in one specific sense, the best-positioned. Attach Supabase or Neon and you have Postgres with row-level security available, which is the strongest isolation layer on this board. Attach nothing and you have no persistence and no isolation question. The platform neither helps nor hinders; it has no opinion.

The honest reading is that v0's ceiling here is higher than most of this board and its floor is the same as everyone else's, because the thing that determines your outcome is a decision you make outside v0.

Webflow: out of the category since January 2026

Webflow is on this board as a comparison point and it no longer belongs in this particular conversation. Webflow sunset User Accounts on 29 January 2026, following Logic in June 2025, in favour of what it describes as an ecosystem-first approach (Webflow updates, 2026).

The consequences were not gentle. User Accounts functionality was disabled on all sites, no new sites could add it, and the APIs and webhooks stopped. Sites that still had it enabled lost access to User Accounts data, which was not migrated to the CMS, and User Accounts pages became regular static pages.

Without a native user system there is no identity to attach a tenant boundary to. Gated, per-customer areas on Webflow now run through third-party services such as Memberstack or Outseta, and the isolation question moves to whichever of those you pick. Any comparison written before 2026 that lists Webflow as a member-area platform is describing a product that no longer exists.

Why AI builders are structurally exposed here

There is a reason this axis is harder for AI app builders than for a developer writing the same application by hand, and it is not that the models are bad at SQL.

A tenant boundary is not a feature. It is an invariant: a property that must hold across every query in the application, including the ones that do not exist yet. Add a reporting page in month four and the filter has to be there. Add a CSV export in month seven and it has to be there too. Add an admin view, a search box, a webhook handler, an analytics dashboard, and each one is a fresh opportunity to omit a clause that nobody will notice is missing, because the app works perfectly for whoever is testing it. You only find out when two customers are in the system and one of them sees the other.

Prompt-driven development makes this worse in a specific way. Each new instruction is handled largely on its own terms, and the model has no durable commitment to a security model you established weeks earlier. It will reproduce patterns it can see in the surrounding code, which helps, and it will occasionally write a query that goes straight at the table, which does not.

This is exactly why the enforcement layer matters more than the feature list. If the boundary lives in the database, a forgotten filter returns nothing and you notice immediately. If the boundary lives in the generated code, a forgotten filter returns everything and you notice when a customer emails you.

It is also why Lovable's linter is more interesting than it first appears. Checking for overly permissive rules is an attempt to make the invariant visible at review time rather than at incident time, which is the correct place to put the effort.

What to check before you commit

If you are choosing a builder for something genuinely multi-tenant, these are the questions worth resolving before you have customers rather than after.

Can the isolation key be something other than the current user? This is the whole question. If the platform can only compare a row's owner against the person asking, it can do per-user apps and not much else. Write the rule for "everyone at Acme sees Acme's rows" and see whether the syntax permits it.

What happens to a table with no rules? Ask specifically, and test it rather than assuming. Bubble's grant-not-prohibit framing and Base44's silence on the question point in the same uncomfortable direction. A platform that fails closed is worth a great deal more than one that fails open.

Does the restriction cover every surface? Blocks, exports, dropdowns, search, comments, the API. Softr's exclusion of the Comments block from global data restrictions is a published example of a gap that a feature summary would never reveal.

Can you test it with two tenants? Create two organisations and two users and try to read across the boundary. This takes twenty minutes and is the only evidence that actually counts. Every other answer in this article, including the vendors' own, is documentation.

Are you retrofitting? Lovable's warning that RLS "is much easier to change before real data exists" applies to every platform here, whatever the mechanism is called.

Verdict, September 2026

If tenant isolation is the point of your application, Lovable is the defensible default on this board. It is the only builder that names organisation-scoped access as a supported pattern, it sits on Postgres row-level security so the boundary is enforced by the database rather than by your code, and it ships tooling that looks for the specific mistake this article is about. That is three things nobody else here offers together.

Bubble and Softr are both credible, for different reasons and with different shapes. Bubble has the most mature rule system and states plainly that it runs server side. Softr makes the strongest enforcement claim of anyone here and its user-group model maps onto tenancy more naturally than a per-user rule does. Neither publishes a worked multi-tenant example, so in both cases you are the architect.

Base44 is the frustrating one. The engine is there, the rule types are right, and the documentation teaches a different problem. If you use it for tenancy you are extrapolating from a department example and guessing at the default.

Bolt.new and Replit put the whole burden on you. Both can reach a Postgres database that supports this properly. Neither will mention it, check it, or warn you.

v0 is a pass-through, and scores according to what you attach.

Webflow is not in this category any more, and has not been since January 2026.

The pattern across the board is consistent and slightly uncomfortable: the platforms that solve per-user isolation well are numerous, and the platforms that document per-tenant isolation number exactly one. That gap is not a coincidence. Per-user is the demo, and per-tenant is the business.

Worth noting alongside this, because the two questions arrive together: teams building for internal use rather than for customers face a related but easier version of the problem, covered in the comparison of builders for internal tools, where the tenant is usually just your own company.