Multi-tenant dashboards in SaaS: how Embeddable solved security and scale

Building dashboards for multi-tenant SaaS applications 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 and embedded analytics experiences.

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 companies), “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 since you're sharing infrastructure, but requires more careful engineering to keep data safely partitioned.

The approach to data isolation that a company chooses often depends on their business, the industry in which they operate, and their own customers' sensitivity to data security and data privacy e.g. if you serve government agencies, you’re  more likely to use a single-tenant architecture.

However, due to its cost effectiveness, most teams use a multi-tenant set up.

The pain of multi-tenant SaaS dashboards

When building customer-facing analytics 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 pursued this use-case, 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 powering your visualizations, which needs to be maintain forever. And it’s unlikely your non-technical teammates will be able to work with this.

From the customer's perspective, the user experience should be simple: log in, see only their data, no distractions. But behind the scenes, multi-tenant dashboards can get messy fast, even for teams experienced with business intelligence tools and approaches.

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 - a critical detail when you’re embedding analytics directly into your app.
• (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 write row-level security rules directly into it, ensuring the datasets are correctly scoped:

  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.
• Reliable metrics – every user sees the right numbers for their account even when users are self-serving data, without risk of cross-tenant leaks.

This helps make multi-tenant analytics practical at scale for our customers - from Y Combinator startup MosaicVoice all the way up to Fanatics, a company with 20,000 employees.

And critically, it means your end-users never see the complexity. To them, the dashboard just “knows” what data is theirs - and you avoid the overhead (and pricing penalties) of duplicating dashboards across tenants.

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 data sources and databases most SaaS teams already rely on. Out of the box, you can connect to:

• Postgres
• MySQL
• BigQuery
• Redshift
• Snowflake
• DuckDB / MotherDuck
• SQL Server
• Databricks
• Clickhouse
• Firebolt
• Presto
• Trino
• Apache Pinot
• Microsoft Fabric

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 teams behind SaaS products building dashboards.‍

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

‍

‍