When you build software, one architecture decision shapes cost, security, and how easily you can ship analytics: do your customers share one database, or does each get their own? This is the single-tenant vs multi-tenant database question — and it has a real impact on embedded BI.
Both models are valid. The right one depends on your customers, and a good embedded BI platform should work with either. Here's how they differ, and what each means once you embed reporting in your product. (For the broader idea, see what multi-tenant analytics is.)
What is a single-tenant database?
A single-tenant database gives each customer their own dedicated, isolated database — their own instance and supporting infrastructure, used by them and only them. Because nothing is shared, a single tenant can be configured and customized heavily for that one customer's needs. This model, often called database-per-tenant, suits businesses in tight verticals that need strict control and isolation.
What is a multi-tenant database?
A multi-tenant database is closer to what most cloud companies adopt: many customers share a single database and a single instance of the application, with each tenant's data separated by a tenant identifier and protected by row-level or data-level security. Tenants can configure parts of the experience but don't alter the underlying code. A middle-ground option, schema-per-tenant, keeps customers in one database but in separate schemas — more isolation than shared rows, less overhead than a database each.
Single-tenant vs multi-tenant database compared
Here's how the two main models stack up on the factors that matter when you're choosing an architecture.
| Factor | Single-tenant database | Multi-tenant database |
|---|---|---|
| Data isolation | Strongest — physically separate database per customer | Logical — shared database, isolated by row/data-level security |
| Cost | Higher — more infrastructure and upfront spend per customer | Lower — shared infrastructure across all tenants |
| Customization | High — tailor per customer freely | Limited — configuration within a shared codebase |
| Scaling | Slower and costlier — provision per customer | Fast and cheaper — add tenants to the shared system |
| Maintenance & updates | Heavier — tasks repeat per customer | Lighter — update once for everyone |
| Best for | Fewer, larger customers needing isolation or compliance | Serving many customers efficiently at scale |
How the database model affects embedded BI
Embedded business intelligence means integrating reports, dashboards, and visualizations directly inside your application, so customers analyze their data without leaving your product. Whichever database model you use, the embedded BI layer has one non-negotiable job: make sure each customer sees only their own data.
How it does that depends on the model. Over a shared multi-tenant database, the BI platform applies row-level or data-level security so each logged-in user is automatically scoped to their own rows. Across many single-tenant databases, it routes each customer to their own database connection, retrieving only that customer's data. The important part for an ISV: one BI platform can serve both models, so your reporting layer doesn't have to be rebuilt when your database architecture varies from customer to customer.
How Yurbi handles both models
Whatever tenancy model you're on, Yurbi is built to support it — and to support a mix.
Multi-tenant (shared database). Yurbi has data-level security built in, so each user is configured to see only the data they're authorized to see. With App Shield, tenant constraints are enforced on every query, so no user can reach another tenant's data even though everything is stored centrally.
Single-tenant (database per customer). You don't need to stand up a separate Yurbi server per customer. Yurbi's semantic layer — the Yurbi App — lets one server serve everyone: each Yurbi App connects to a default database, and through dynamic data sources you define connection strings (data-source personas) pointing to each customer's database. In user permissions, you assign each customer the data source they should connect to. Build once, share with everyone, all from a single server.
If schemas differ between customers, or you need an isolated install per customer, Yurbi's APIs and scripts let you export, copy, and load Yurbi Apps, reports, and dashboards to handle those cases too. It's self-hosted, with flat published pricing from $10,000/year.
Frequently asked questions
What is a single-tenant database?
A single-tenant database gives each customer their own dedicated, isolated database with its own instance and infrastructure. Often called database-per-tenant, it offers the strongest isolation and the most customization, at higher cost and operational overhead.
What is a multi-tenant database?
A multi-tenant database stores many customers' data in one shared database, separated by a tenant identifier and protected by row-level or data-level security. It's cheaper to run, easier to maintain, and faster to scale, with less per-customer customization.
Single-tenant vs multi-tenant database — which is better?
Neither universally. Single-tenant suits fewer, larger customers needing strict isolation, heavy customization, or compliance; multi-tenant suits serving many customers efficiently at lower cost. Many vendors use a mix, and a good embedded BI platform supports both.
How does the database model affect embedded BI?
The BI layer must enforce tenant isolation regardless of model — row/data-level security over a shared database, or per-customer connection routing across single-tenant databases. One platform can serve both, so your reporting layer doesn't need rebuilding when architecture varies.
Can one BI platform support both models?
Yes. Yurbi supports both: data-level security (App Shield) over a shared database, and the Yurbi App semantic layer to route each customer to their own database from one server. Build reports once and share across isolated databases. Yurbi is self-hosted with flat pricing from $10,000/year.
Choosing an architecture for your reporting layer? See embedded analytics built for SaaS and how Yurbi enforces tenant data security.
Stop rebuilding your reporting layer.
Embed Yurbi into your product and ship analytics to your customers in weeks — not quarters. Self-hosted, white-labeled, flat annual pricing.
Download Free Trial See a Live Demo
