Salesforce, Shopify, Notion, Slack, Figma and GitLab are all multi-tenant SaaS examples: one product serving many customer companies, with each company's data kept separate. Each one picks an ID that says which customer owns every record, such as an organisation, a shop or a workspace, and builds its storage around it.
The details differ in useful ways. Salesforce keeps every customer in one shared database. Shopify, Notion and Figma split their data across many databases once one wasn't enough. Slack changed its approach as large customers outgrew it. GitLab runs a shared service and also sells a private, single-tenant one. Everything below comes from the companies' own engineering posts and documentation, linked in each section.
What is a multi-tenant SaaS application?
A multi-tenant SaaS application is one deployment of a product that serves many customer accounts, called tenants, while keeping each tenant's data private. A tenant is usually a company, with its own users, settings and subscription. The opposite is single-tenant SaaS, where every customer gets a separate copy of the application and its infrastructure.
Most B2B SaaS is multi-tenant because it's cheaper to run and simpler to update: one release reaches every customer. If you want the patterns and trade-offs first, our guide to multi-tenant SaaS architecture covers them. This article looks at how real products apply them.
Multi-tenant SaaS examples at a glance
- Salesforce: the tenant is an org. One shared database and schema, with an OrgID on every row. Pool pattern.
- Shopify: the tenant is a shop. A shop_id on every shop-owned table, with shops grouped into isolated pods. Pool, split into isolated units.
- Notion: the tenant is a workspace. Sharded by workspace ID across 480 logical shards (as of 2021). Pool, sharded.
- Slack: the tenant is a workspace. First one shard per workspace, later re-sharded by channel ID on Vitess. Pool, re-sharded.
- Figma: tenants are organisations. Several shard keys, including OrgID, FileID and UserID. Pool, sharded.
- GitLab: the tenant is a customer organisation. Shared GitLab.com, plus single-tenant GitLab Dedicated. Pool and silo side by side.
The pattern names come from Amazon's guide to SaaS tenant isolation strategies. Pool means tenants share resources and rules keep them apart. Silo means each tenant gets its own.
Salesforce: one shared database, an OrgID on every row
Salesforce is the classic multi-tenant SaaS example. Each customer is an org, and every org lives in a single shared database with a single schema. According to Salesforce's platform multitenant architecture brief, "every org-specific record in shared database tables has an OrgID", and the database structures, including indexes, are physically partitioned by OrgID so a query only touches its own org's partitions.
Two other choices make that work at scale:
- Customisation is data, not schema. When a customer adds a custom object or field, Salesforce doesn't create a new database table. It stores metadata describing the object, and the platform builds it at runtime. That keeps one schema for every customer.
- Hard limits on shared resources. Salesforce enforces governor limits on code running in the platform, capping things like CPU time, memory and the number of queries per transaction. Those limits are how one customer's heavy code is stopped from slowing everyone else.
What to take from it: a tenant ID on every row, with the database organised around it, can carry a very large product. Customer-specific settings should be stored as data, never as code branches for one client.
Shopify: a shop_id on every table, and shops grouped into pods
Shopify's tenant is the shop. Its engineers explain in a post on shard balancing that they can "attach a shop_id to all shop-owned tables and have it serve as a sharding key". Because every row knows its shop, a shop's data can be moved from one database to another as a unit.
Shopify's post on its pods architecture explains why it went further. By 2015 it was "no longer possible to continue buying a larger database server", so it sharded the database. That restored growth, but a single failed shard could make some actions unavailable across the whole platform. The answer was pods: "a set of shops that live on a fully isolated set of datastores". Web servers and job workers are shared, but each request or background job talks to one pod only, and a routing layer in the load balancers sends each request to the right pod.
What to take from it: isolation isn't only about privacy. Grouping tenants into separate units also limits how many customers one database failure can affect. And the shop_id on every table is what made those moves possible.
Notion: sharded by workspace ID
Notion's tenant is the workspace. In Herding elephants: lessons learned from sharding Postgres at Notion (October 2021), the team describes a single Postgres database that was reaching its limits, with CPU spikes and maintenance jobs falling behind.
They partitioned by workspace ID because every block in Notion belongs to exactly one workspace, and users usually work inside one workspace at a time. That kept most queries on a single shard. The design used 480 logical shards spread across 32 physical databases, with each logical shard set up as a Postgres schema. They picked 480 because it divides evenly in many ways, so the number of database servers could grow in steps without unbalancing the shards. Routing from workspace to shard lives in application code.
The post is candid about hindsight. The team says they should have sharded earlier, before the database was under strain.
What to take from it: pick the tenant key early and make sure everything hangs off it. Notion could shard by workspace because each block already belonged to exactly one.
Slack: from workspace shards to channel shards
Slack's tenant is the workspace, and for years it stored each workspace's data on one MySQL shard. A lookup service mapped each workspace to its shard. Slack's post Scaling datastores at Slack with Vitess (December 2020) explains where that broke down:
- The largest customers outgrew the largest hardware available for their shard.
- Big customers created hot spots, while many other shards sat underused.
- Products that connect organisations, such as Enterprise Grid and Slack Connect, broke the assumption that a team's data lives on one shard.
- An outage on one shard took down every customer on it.
Slack moved to Vitess, a system for scaling MySQL horizontally, and started sharding message data by channel ID instead of workspace. That spread a large customer's traffic across many shards instead of concentrating it on one.
What to take from it: the tenant is the right unit for privacy, but not always the right unit for splitting data. When a few customers are far bigger than the rest, or customers start sharing data with each other, you may need a different split for some tables while the tenant ID still governs who can see what.
Figma: several shard keys, one of them the organisation
Figma's post How Figma's databases team lived to tell the scale (March 2024) shows a product that ran on one Postgres database, on AWS's largest physical instance, as recently as 2020. When some tables reached billions of rows, the team built horizontal sharding on top of their existing Postgres.
Instead of a single tenant key, they chose a few, including UserID, FileID and OrgID, and grouped related tables that share a key so they can still be joined and updated together. A proxy service they built, DBProxy, routes each query to the right database. They rolled it out in two steps: first sharding logically while the data stayed in one database, then splitting the data physically.
They're open about the cost. Sharded tables lost database-enforced foreign keys and globally unique indexes, transactions across shards are no longer atomic, and the proxy supports only a subset of SQL.
What to take from it: sharding is a serious project with real trade-offs, even for a well-funded team. A SaaS MVP doesn't need it, but it should avoid designs that make it harder later, such as records that belong to no tenant.
GitLab: a shared service and a single-tenant option
GitLab shows both ends of the range in one company. GitLab.com is the shared, multi-tenant service. GitLab Dedicated is described as a "single-tenant SaaS solution": a fully isolated instance for one customer, hosted and run by GitLab in the AWS region the customer chooses. GitLab pitches it at organisations that need to meet strict compliance requirements.
What to take from it: you don't have to choose one model forever. Many SaaS companies keep most customers on shared infrastructure and offer a dedicated deployment to the few who need it for regulation, data location or contract terms. That's the bridge pattern in practice, and it's far easier to offer if the product was multi-tenant from the start. It's also the kind of decision we plan for in SaaS development work, even when the first release is fully shared.
What do these multi-tenant SaaS examples have in common?
Across all six, the same few decisions come up:
- Every record knows its tenant. OrgID, shop_id and workspace ID are the foundation. Without them, none of the later moves would have been possible.
- They started on one database. Shopify, Notion, Slack and Figma all split their data years after launch, when growth forced it. Splitting was possible because the tenant key was already there.
- The biggest customers break the averages. Slack's hot spots came from a few customers being much larger or busier than the rest.
- Isolation covers failures as well as privacy. Shopify built pods so one database failure couldn't affect the whole platform, and Slack counted the fact that one shard outage took down every customer on that shard among its reasons to change.
- Shared resources need limits. Salesforce's governor limits are a large-scale version of the per-tenant rate limits every SaaS product should have.
- Some customers will pay for their own copy. GitLab Dedicated shows how a shared product can still offer a separate deployment when a customer needs one.
What should a SaaS MVP copy from these examples?
A SaaS MVP should copy the foundations, not the scale. None of these companies launched with 480 shards or a query-routing proxy. What they had, or wished they'd had sooner, was a clean tenant model. For a first version that means:
- One application and one PostgreSQL database shared by all tenants.
- A tenant ID on every tenant-owned table, with row-level security switched on so the database refuses to return another tenant's rows.
- The tenant taken from the signed-in session, never from a URL or form field.
- Customer-specific settings stored as data, not as code written for one client.
- Per-tenant rate limits on the API and on heavy jobs such as imports.
- Nothing that belongs to no tenant unless it's genuinely global.
That's how we approach every product in our SaaS MVP development services, and it's one of the questions worth asking any team you're considering, as we explain in how to choose a SaaS MVP development agency. It also fits the advice in what goes in the first version of an MVP: get the parts that are expensive to change right, and keep everything else small.
If you're planning a multi-tenant product and want the tenant model decided before the first line of code, contact us to get started.
Common questions
What is an example of a multi-tenant SaaS application?
Salesforce is the best-known example. Every customer org shares one database and schema, and every org-specific record carries an OrgID that keeps it separate. Shopify, Notion, Slack and Figma are also multi-tenant: many customers share the same application, and each customer's data is tied to an ID such as a shop or workspace.
Is Slack a multi-tenant application?
Yes. Slack serves many workspaces from one platform. It originally stored each workspace's data on its own MySQL shard, then moved to Vitess and began sharding message data by channel ID, because its largest customers had outgrown a single shard.
Is Shopify multi-tenant?
Yes. Every shop-owned table carries a shop_id, which Shopify uses as its sharding key. Shops are grouped into pods, each with its own isolated datastores, so a database problem in one pod doesn't affect shops in another.
What is an example of single-tenant SaaS?
GitLab Dedicated is one. GitLab describes it as a single-tenant SaaS solution: a fully isolated GitLab instance for one customer, hosted and managed by GitLab in the AWS region the customer picks. It sits alongside GitLab.com, which is shared by many customers.
Do multi-tenant SaaS products use one database or many?
Usually one at first, then many as they grow. Salesforce describes a single shared database for its tenants, while Shopify, Notion, Slack and Figma split their data across many databases once one couldn't keep up. In every case the tenant ID on each record is what made that split possible.
When should a SaaS product start sharding its database?
Usually not at the MVP stage. These companies sharded when a single large database became a real limit, years after launch. An MVP should instead make sharding possible later, by putting a tenant ID on every tenant-owned record and keeping data that belongs to no tenant to a minimum.
Is multi-tenant SaaS less secure than single-tenant?
Not if separation is enforced at more than one layer. The application should take the tenant from the signed-in session, the database should enforce row-level security, and tests should try to read across tenants. Single-tenant deployments give stronger physical separation, which is why some regulated customers ask for them.
Want something like this built and run in your own accounts? That's what our SaaS Development service does. You can also see everything we build or look through our case studies.
