Most SaaS platforms use row-level filters on a shared database. Here's why Manna uses isolated databases instead — and why it matters more than most platforms will admit.
The standard approach and what it actually means
When you sign up for most nonprofit fundraising platforms, your donor data doesn't get its own home. It gets a label. Every record in the database — yours, the org across the country, the food bank, the animal shelter — lives in the same tables. A column called tenant_id or org_id marks which records belong to which organization. Queries filter by that column. You only ever see your rows.
This is called multi-tenancy with row-level security, and it's genuinely standard practice across SaaS. It scales efficiently. It's operationally simple. It's what most platforms — nonprofit or otherwise — are built on.
But here's what it also means: a misconfigured query, a bug in the access control layer, or a permissions error doesn't just expose your data to the platform's engineers. It potentially exposes it to other tenants. The blast radius of a security failure in a shared database is the entire database.
Imagine a filing cabinet in a shared office. Every organization's files are in there, labeled with their name. The filing cabinet is locked. But it's still one cabinet, and everyone with a key to the building has physical proximity to every file inside it. If the lock fails — or someone gets a key they shouldn't have — the files are all there together.
What Manna does differently
Every organization on Manna gets a separate, isolated database. Not a filtered view of a shared table — a distinct database with its own connection string, its own credentials, and its own access controls. Your donor records, giving history, campaign data, email logs, and tax receipts live in a database that has no structural relationship to any other organization's data.
This is sometimes called database-per-tenant architecture, and it's less common in SaaS because it costs more to operate and requires more careful engineering. You can't just add a WHERE tenant_id = ? clause to every query. You have to manage connection pooling across many databases, route each request to the correct database at the application layer, and handle migrations across every tenant individually rather than once across a shared schema.
We made that tradeoff deliberately. The operational overhead is ours to manage. The benefit — genuine data isolation — belongs to the organizations running on the platform.
A misconfiguration in a shared database touches every tenant. A misconfiguration in an isolated database touches one.
What isolation actually protects against
Data isolation isn't just a theoretical security posture. It has practical consequences across several real scenarios.
Accidental data exposure. In a shared database, a query bug or a missing access control check can return records from another tenant's data. This happens. It's embarrassing, it's a breach, and in a system with shared tables it's an ever-present risk that requires constant vigilance in every query the application makes. In an isolated database, that query bug returns nothing from another tenant's data because there is no other tenant's data present.
Security incidents. If a shared-database platform has a security incident affecting one tenant — a compromised admin account, a SQL injection vulnerability, an insider threat — the question is immediately how far the access extended. In a shared schema, the answer is potentially far. In an isolated database model, a breach at the database level is contained to one organization.
Compliance and data residency. Organizations operating under HIPAA, state-level data privacy laws, or nonprofit-specific data governance requirements need to be able to demonstrate exactly where their data lives and who can access it. An isolated database makes that answer simple. A shared database makes it complicated.
Vendor lock-in and portability. When your data lives in a shared schema, leaving the platform means requesting an export and hoping it's complete. When your data lives in your own database, it can be migrated, transferred, or handed over cleanly — because it was always structurally separate to begin with.
How it works in practice
When Manna provisions a new client, we spin up a dedicated Supabase project for that organization. That project has its own database, its own API keys, its own access controls, and its own backup and restore lifecycle. The Manna application authenticates to that project using credentials scoped specifically to that client. No other client's application instance has those credentials.
Instead of one filing cabinet with labeled files, each organization gets their own cabinet in their own room. The building is shared — that's the Manna platform, the codebase, the deployment infrastructure. But the room is theirs. The cabinet is theirs. The key to the room doesn't open any other room.
Migrations — schema changes, new features, database updates — are applied per-tenant rather than across a shared schema. That's more work on our end. It also means a migration that causes a problem for one client's database doesn't cause a problem for every client's database simultaneously.
What you should ask any platform you're evaluating
Whether you're evaluating Manna or any other nonprofit platform, these are the right questions to ask about data architecture:
Is our donor data in a shared database with other organizations? If the answer is yes, follow up with: what prevents a query bug or a permissions error from exposing our records to another tenant?
What happens to our data if we leave? A shared database model typically means an export — a CSV dump or a data file that you receive and then have to rebuild from. An isolated database model means the data can be transferred structurally intact.
Who at the platform company has access to our donor records? This is a reasonable question regardless of the architecture. The answer should be: specific named roles, with access logging, and a clear policy.
Ask those questions. Evaluate the answers. The right platform for your organization is the one that can answer them clearly — not the one that redirects to a security page and a SOC 2 badge.
At Manna, the answer to the first question is no. Your donor data is in your database. It was always in your database. That's not a premium feature or an enterprise tier. It's how the platform is built.
