Multi-Tenant Dashboards in SaaS: How Embeddable Handles Security and Scale

Building dashboards for a multi-tenant SaaS product is harder than it looks. The risk of cross-tenant data leaks, duplicated dashboards, or brittle SQL rules grows fast.

In our previous article we broke down the multi- and single-tenant database architectures behind this problem. In this article we build on that, focusing on how Embeddable itself handles multi-tenancy, and what that means for your customer-facing dashboards.

But before we dive in, here’s a quick recap:

What do single-tenant and multi-tenant mean?

In modern customer-facing software applications (e.g. SaaS platforms), “single-tenant” and “multi-tenant” describe how you isolate customer data:

• Single-tenant means each customer has their own database (sometimes their own infrastructure too). It’s simple and secure but can get expensive and hard to scale.
• Multi-tenant means many customers share the same database, with security rules controlling access. It’s efficient and scalable, but requires more careful engineering to keep data safely partitioned.

The approach a company chooses often depends on their business, the industry in which they operate, and the types of customers they serve e.g. if you serve government agencies, you’re  more likely to use a single-tenant architecture.

However, most teams use a multi-tenant set up or some mix of the two.

The pain of multi-tenant SaaS dashboards

When building customer-facing data experiences, it sounds easy: just give each customer a dashboard with their data.

But in practice you end up with duplication and risk, especially if you want to enable your non-technical teams to iterate on the dashboards.

• Do you create one dashboard per tenant? We’ve certainly met companies who’ve done this, and it gets painful very quickly. Imagine running a SaaS with 500 tenants, wanting to change something, and having to manage that change across all those dashboards…nightmare!
• Do you create one shared dashboard? Then you need complex filters to stop cross-tenant leaks.
• Do you hard-code rules into every query? Now you’ve got brittle logic to maintain forever. And it’s unlikely your non-technical teammates will be able to work with this.

From the end-user’s perspective, the experience should be simple: log in, see only their data, no distractions. But behind the scenes, multi-tenant dashboards can get messy fast.

How Embeddable approaches multi-tenancy

Embeddable was built from the ground up to handle both single- and multi-tenant architectures elegantly.

The idea wasn’t just to solve the security challenges - it was also to empower non-technical teams to build and iterate on in-app, user-facing dashboards, without having to think about complex SQL, filters, or access rules.

Here’s how it works in practice:

• (1) Semantic layer, not queries. Most analytics tools tie each visualisation to a query (for example: “here’s the SQL behind this pie chart”). At Embeddable, we take a different approach: you define your data models separately in a semantic layer, with pre-defined ways of slicing and dicing the data. Straight away, that makes the dashboards consistent, secure, and reusable across tenants.
• (2) Dashboards as web components. You embed Embeddable dashboards into your app as HTML web components. Unlike iFrames, they behave like native parts of your product.
  
• (3) Security context at runtime. This is the key part: when a user visits a page with a dashboard, your app requests a security token from Embeddable’s Tokens API. In that request, you include a security context - just a simple object with key-value pairs that describe who the user is and what they’re allowed to see based on the existing rules in your database:
  
  e.g.
  
  {
"userId": 45,
"orgId": "9sZSJ9LHsiYXR0cmlidXRlIjoiZ2VvaXBf",
}
• (4) Context-aware data models: That security context is passed directly into your data models. So when you define a model, you can write row-level security rules directly into it:
  
  e.g.
  
  SELECT * FROM public.orders
WHERE org_id = '{ securityContext.orgId }'
AND user_id = { securityContext.userId }

The result is that every dashboard is automatically pre-filtered to just the data a particular user is allowed to see. It applies everywhere - from the data shown in charts, to the dropdown options in filters.

• From the user’s perspective, it’s seamless. They never have to log in separately or think about permissions - the dashboard just works and contains only their data.
• From your team’s perspective, it’s equally seamless. You decide which data points you want to display for each visualisation and row-level security is applied automatically in the background.

You can even define preset security contexts to easily switch between ‘customer views’ inside the no-code dashboard builder - perfect to check you’re seeing the right data.

‍Why this approach matters

This model has some obvious benefits for our customers and their users:

• Your non-technical teams (or even your customers!) can build and iterate - they don't need to worry about your company’s complex security rules because they’re already baked into the data models.
• Automatic scoping - no need to manually build tenant filters into every chart.
• Fewer dashboards to manage - you don’t change your dashboards as you go from 10 customers to 10,000.

And critically, it means your end-users never see the complexity. To them, the dashboard just “knows” what data is theirs.

How does it work for a hybrid security model with row-level and database-level security?

Many companies use a hybrid approach i.e. some customers live in a shared multi-tenant database, others demand their own dedicated instance OR each customer lives in its own database but you still need to apply row-level security based on the permissions of the particular dashboard viewer.

Once again, we’ve designed Embeddable from the ground up to deal with these more complex-uses cases easily and elegantly.

You can easily combine:

• Row-level security - applying row-level security based on a security context, as described above.
• Database-level security - use our environments API to programmatically tell us which database to load the data from.

Both models work with the same dashboard definitions. You don’t rewrite dashboards when your architecture changes, and you don’t need to manually “provision” additional users - everything just works.

What databases does Embeddable support?

Embeddable works with the databases most SaaS teams already rely on. Out of the box, you can connect to:

• Postgres
• MySQL
• BigQuery
• Redshift
• Snowflake
• DuckDB
• SQL Server
• Databricks
• Clickhouse
• Firebolt

And more.

Because the security context is applied at the data-model level and based on your own set up, the experience is consistent no matter which database you’re using. Whether your customers are spread across a shared Postgres instance, an enterprise-grade Snowflake warehouse, or a hybrid of both, the same rules apply and the same dashboards just work.

The bottom line

Multi-tenancy is one of those invisible challenges: it should feel simple to end-users, but it’s rarely simple for the team building dashboards.

Embeddable’s security-context model is designed to take that complexity off your plate. One dashboard, many tenants, each end-user seeing exactly what they should — and nothing else.

‍

‍

‍

‍