When several customers use the same software instance, a SaaS provider has to answer a fundamental question: how is the data of each tenant kept separate? The most common answer in the industry is a shared database in which every table carries an extra column such as “tenant_id”, used to filter every query. That works, but it depends entirely on this filter being implemented correctly in every single place in the code. 1Tool takes a structurally different approach.
A separate database per tenant instead of a shared table
At 1Tool, every tenant gets its own physically separate database. It is connected dynamically at runtime – when a user logs in, the system knows which tenant database it has to talk to and establishes the connection accordingly. Separation therefore does not happen at application level through a filter condition, but already at infrastructure level. A programming error that, with a shared database, could theoretically mean the filter condition is forgotten and another customer's data becomes visible is ruled out from the start with a strict database-per-tenant architecture: there is simply no shared table from which too much could be read by mistake.
Dedicated servers for large tenants, separate cache for everyone
This separation can be taken even further when needed. For particularly large tenants, 1Tool can even assign a completely separate database server – with its own host and its own credentials – instead of running the database on the same shared server infrastructure as other customers. This extends isolation from the logical to the physical infrastructure level when that makes sense for a customer for security or performance reasons. In addition, 1Tool also manages the cache per tenant: cached data is likewise kept separately for each tenant, so no mixing between customers can occur at this level either.
Fine-grained permissions within the tenant
Separation between tenants is only one layer of access control. Within a single tenant, a permission system with dozens of specialised filter rules – so-called scopes – additionally governs which individual records a given user is allowed to see at all. This makes it possible, for example, for a sales representative to see only their own contacts while a manager gets a complete overview – all within the same database that is already isolated per tenant. For companies with high requirements for data protection and data security, this combination is a relevant argument when choosing a provider. A shared database with tenant_id columns is cheaper to scale in operation, but requires every single query in the entire system to be filtered correctly – over years and across many generations of developers. A true database-per-tenant architecture moves this guarantee from the application logic to the infrastructure itself.
Frequently asked questions
Does a separate database per tenant mean that data is stored physically separately?
Yes, every tenant gets its own separate database instead of shared tables with a tenant identifier as a filter column.
Can individual tenants be run on a completely separate server?
For particularly large tenants this is possible – including their own host and their own credentials, separate from the shared server infrastructure.
How is it controlled within a tenant who sees which records?
This is handled by a permission system with numerous specialised filter rules, which apply in addition to the database separation and restrict access to individual records per user.
How important is true database isolation for your company's data protection requirements?
Read more
- Notifying other systems: HTTP requests straight from the automation workflow
- Incoming webhooks: bringing external data into the CRM in a structured way