Every team stores client data differently. Some keep everything in one big table, others prefer separate schemas, and some even go as far as spinning up a database per client. The way your data is structured determines which tenancy model you should choose in Databrain. This guide will help you decide. The first step is to understand how tenancy levels work.

​
Understanding Tenancy Levels

A tenancy level represents a layer at which client data is separated and organized. You might separate data at the table level, schema level, or even across databases. The more levels you introduce, the more control and isolation you can achieve.
  • One level of tenancy: Clients are separated at a single layer (e.g., by table or schema).
  • Multi-level tenancy: Clients are separated across two or more layers (e.g., schema + table, or database + schema + table).
With this in mind, let’s walk through the different setups.

​
One Level of Tenancy

If your setup has only one level of tenancy, here’s how your data might look:

​
Start with your tables

Ask yourself: Do all your clients live in a single table?
  • If yes, your data has a client_id (or similar) column to mark which row belongs to which client.
    • Example: One orders table where every record is tagged with the client it belongs to.
    • This maps to Single Table Tenancy — a shared database, shared table setup.
Read this guide on how to set up table tenancy: Configure Table Tenancy If not, let’s move on.

​
Organized by schema?

Do you group client data by schema inside a single database?
  • If you use one shared schema and rely on a client_id column
    • Example: A project management platform where all companies’ contacts, deals, and activities live in one schema, but each row is tagged with a company ID.
    • This maps to Single Schema Tenancy.
  • If you create a dedicated schema for each client
    • Example: A payroll system where each company has its own schema (client1.employees, client2.employees), keeping the payroll data fully separated.
    • This maps to Multi Schema Tenancy.
If not, let’s step up a level.

​
Full database per client?

Do you provision a separate database for each client?
  • On MSSQL, this usually means one server with multiple client databases
    • Example: An HR management platform for enterprises, where each enterprise customer gets their own MSSQL database (db_client1, db_client2), all on the same server.
    • This maps to Multi Database MSSQL Tenancy.
    To enable this in Databrain: when creating your MSSQL datasource, check “Enable Multiple Databases” and select Multi Database Tenancy. Add a Datasource
Enable Multiple Databases MSSQL Gi
  • On Postgres or BigQuery, this often means spinning up one database per client
    • Example: A fintech platform where each client has their own Postgres database instance for compliance and isolation.
    • This maps to Multi Datasource (Hybrid Tenancy).
Read more on Hybrid Tenancy using Databrain If not, let’s check the simplest option.

​
One shared connection?

Do all clients share one single database connection?
  • If yes, you’re on Single Datasource Tenancy.
    • Example: A chatbot where all client conversations are stored in the same database, separated by a client identifier. A client_id column ensures each company only views their own conversations.

​
Multi-Level Tenancy

If your setup requires more than one layer of separation, you fall into multi-level tenancy. This setup gives you finer control by combining multiple levels such as schema, table, and database. Here are the common patterns:

​
Do you separate clients by schema and refine with table tenancy?

  • Example: A reporting tool where each client’s data is grouped under schemas, but within each schema, tables restrict access to different departments (e.g., sales vs. finance).
  • This maps to Datasource → Schema → Table Tenancy.
  • In Databrain, this refinement is managed by App Filter — a feature that applies table-level restrictions inside the platform.

​
Do you separate clients by multiple levels of tables?

  • Example: A marketing analytics platform where each client has its own set of tables, and another level of tables to further restrict by campaign or region.
  • This maps to Datasource → Table Tenancy Level 1 → Table Tenancy Level 2.

​
Do you use MSSQL with schemas and table tenancy?

  • Example: An MSSQL deployment where each client database has multiple schemas (e.g., HR, payroll, support), and tables refine access by team or role.
  • This maps to MSSQL Database → Schema → Table Tenancy.

​
Do you use MSSQL with multiple levels of tables?

  • Example: An MSSQL deployment with client-level databases, each with shared tables for operations, refined by another level of tables for country-level access.
  • This maps to MSSQL Database → Table Tenancy Level 1 → Table Tenancy Level 2.

​
Do you need the highest level of isolation across all layers?

  • Example: A multinational platform where each client has its own database, schemas divide regions (e.g., North America, Europe), tables separate domains (e.g., employees, payroll, performance), and another level of tables ensure only certain roles (e.g., HR manager vs. finance lead) can access specific slices of the data.
  • This maps to Datasource → Database → Schema/Table → Table Tenancy.
With this flow, you can match your current data setup to the tenancy model that fits. Start by identifying how many layers of separation you currently have. Then, see whether you’re working with tables, schemas, databases, or datasources, and whether you need an additional row level tenancy fine-grained control. Once you know where you land, Databrain takes care of the rest.