Imagine you are building a learning management system (LMS) for coaching centers. Each center has its own students, teachers, fees, and exam results.
You want to tell an owner: "Another center cannot access your students' data."
Giving every center its own Supabase project feels like a clean place to start. Different databases. Separate accounts. No customer data sitting in the same table.
Then you add one column to the students table.
With twenty centers, that small change now has twenty destinations. Nineteen succeed. One fails. Your new frontend expects the column everywhere.
What Exactly Are We Separating?
In SaaS, a customer organization is often called a tenant. For this LMS, one coaching center is one tenant.
Two common designs are:
Supabase gives each project its own Postgres instance. It is more than creating another folder inside the same database.
Both designs can use one application codebase. Separate projects do not require separate copies of your product's source code.
Blast Radius: Which Mistakes Stay Inside One Center?
Consider a background job that deletes old exam attempts. Someone forgets the condition that restricts it to one center.
In a shared database, a privileged job could delete attempts belonging to every center. In a dedicated project, a job connected only to Center A's database cannot reach Center B's records through that connection.
In distributed systems, this is known as a smaller blast radius: fewer customers are affected when a failure occurs.
A heavy analytical report at one center has less chance of consuming another center's database compute. You can also increase one center's database capacity without upgrading everyone else.
But the boundary has limits. A deployment script holding credentials for every project can repeat the same mistake everywhere. A broken frontend release can affect every center. A cloud provider outage can still take down several projects at once.
Separate databases help contain local failures. Shared code and shared administration can still create shared failures.
The Student in the Next Classroom Still Matters
A teacher should only access the classes they teach. A student should not be able to change their marks. Neither requirement disappears when a center gets its own database.
For browser-accessible tables, Row Level Security (RLS) controls which rows a user may access. Policies must cover reads and writes, including what fields users may change.
In a shared project, those rules must also enforce center membership.
In either design, test denied actions as carefully as allowed ones: another student's results, another teacher's class, and, where applicable, another center's records.
A public Supabase key (anon) is designed to appear in the browser. Secret and service_role keys can bypass RLS and must remain on the backend. Supabase explains this distinction in its data security guide.
The Hardest Part May Be the Next Release
If you edit each production database by hand, eventually one project will drift. A policy gets missed. A column has the wrong data type. Someone fixes an urgent problem directly in the Supabase dashboard and forgets to record it.
Now "works on my machine" becomes "works for nineteen customers."
Use versioned database migrations: files that record schema changes alongside your code. Apply the same migration history to each project, and track which changes succeeded where.
That still leaves a timing problem. A migration can succeed in one project while another is temporarily unavailable.
For a new optional field, a safer release sequence is:
- Add the field first: Keep existing fields working so the current application remains compatible.
- Test on staging, then a small production batch: Verify important user journeys such as login, exam submission, and viewing results.
- Record success for every target: Stop the rollout when a project fails. Investigate before continuing.
- Enable the feature after its database change is ready: If readiness differs by center, keep the feature disabled for centers that have not yet migrated.
Renaming or replacing a field requires an extra step: move the data and update readers and writers before removing the old field. In software engineering, this is often called the expand and contract pattern: add support, move usage, then remove what is no longer needed.
A Separate Project Means a Separate Login System
With Supabase Auth in each project, a teacher's account in Center A does not automatically exist in Center B.
That may suit your product. A teacher working at both centers needs a deliberate sign-in experience.
For a simple setup, each center's application deployment can use that center's dedicated project configuration. A shared application needs a reliable way to select the correct project before login—for example, via subdomains (center-a.lms.com) or tenant slugs.
Project selection is routing; the selected project must still verify the user's identity and permissions.
Limit access to privileged credentials. Separation helps far less if one poorly protected internal admin tool holds service keys for every project.
Put the Cost Beside the Customer's Subscription
The cost of your first free project tells you little about the cost of serving fifty customers.
As checked on October 30, 2026, Supabase's free allowance is two active projects across organizations where you are an owner or administrator. Free projects may also pause after a week of inactivity. Creating more organizations does not multiply your personal free-project allowance. See the official billing rules and current pricing.
For an illustrative paid setup, Pro is $25 per organization per month, which includes $10 in monthly compute credits. A Micro compute instance costs approximately $10 per month. Using Supabase's compute billing model:
How the compute math breaks down under Supabase's billing rules:
- 1 center ($25/mo): Covered by the base Pro organization plan ($25/mo), which includes $10 in monthly compute credits—fully paying for 1 Micro instance ($10/mo).
- 10 centers ($115/mo): The $25 base plan + 9 additional Micro instances at $10 each ($90 additional compute).
- 50 centers ($515/mo): The $25 base plan + 49 additional Micro instances at $10 each ($490 additional compute).
These estimates assume a full month of continuous uptime, before usage overages, add-ons, and taxes. Load testing determines whether a Micro instance is sufficient for your peak exam traffic. Both production and staging projects count toward your bill.
In SaaS, this directly impacts your unit economics and gross margins. A quiet center still incurs a base compute fee every month. Include that infrastructure floor—along with maintenance and operational support—when deciding what to charge per tenant.
Try Recovering One Center Before You Choose
Here is a useful exercise: Center A accidentally deletes yesterday's fee records. Center B is in the middle of taking an exam. How would you recover A without interrupting B?
With a shared project, restoring the entire database to yesterday would also rewind B's live exam data. You need a selective recovery process: restoring a backup elsewhere and carefully extracting only Center A's rows.
A dedicated project gives you an independent recovery target. But it does not make recovery effortless. You still need to decide your Recovery Point Objective (how much data can be lost), your Recovery Time Objective (how long recovery can take), and how to reconcile legitimate changes made since the backup.
Which Design Should You Choose?
For a budget-sensitive product serving many small centers with similar needs, I would usually start by evaluating a shared project. The trade is fewer databases to operate and monitor, in exchange for carefully designed tenant access rules.
I would favor dedicated projects when independent recovery, dedicated database capacity, or customer ownership is a non-negotiable requirement, and each customer's subscription revenue easily supports the ongoing compute cost.
If the customer must own the Supabase organization, agree on billing, maintenance access, and operational handover upfront. A separate project inside your own account does not give the customer ownership by itself.
If you already use one project per center, a growing project count alone is not a reason to rebuild. First check whether your onboarding, migrations, monitoring, and recovery are repeatable through automation. Avoid customer-specific code forks that make every release divergent.
You can also combine both approaches over time—keeping smaller centers on a pooled database and offering dedicated projects for enterprise tiers. Just remember that migrating a tenant later involves user identities, storage assets, permissions, and application routing, not only database rows.
The fundamental architectural question to keep asking is:
What must I be able to change or recover for one customer without disturbing the others?
Your answer tells you what level of isolation is worth paying for. A recovery rehearsal and a staged migration rollout will tell you whether you can operate it reliably.