[{"data":1,"prerenderedAt":132},["ShallowReactive",2],{"blog-en-database-per-tenant-multi-tenancy-1tool":3},{"id":4,"title":5,"body":6,"categories":112,"date":114,"description":12,"draft":115,"excerpt":116,"extension":117,"image":118,"lang":119,"meta":120,"modified":121,"navigation":122,"noindex":115,"path":123,"related":116,"seo":124,"seoDescription":125,"seoTitle":126,"slug":127,"sourcePath":128,"sourceRoute":116,"stem":129,"tags":116,"translated":115,"type":130,"wpId":116,"__hash__":131},"blog\u002Fen\u002Fblog\u002Fdatabase-per-tenant-multi-tenancy-1tool.md","Database per tenant: how 1Tool really solves multi-tenancy",{"type":7,"value":8,"toc":102},"minimark",[9,13,18,21,25,28,32,35,39,64,68,85,91,94],[10,11,12],"p",{},"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.",[14,15,17],"h2",{"id":16},"a-separate-database-per-tenant-instead-of-a-shared-table","A separate database per tenant instead of a shared table",[10,19,20],{},"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.",[14,22,24],{"id":23},"dedicated-servers-for-large-tenants-separate-cache-for-everyone","Dedicated servers for large tenants, separate cache for everyone",[10,26,27],{},"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.",[14,29,31],{"id":30},"fine-grained-permissions-within-the-tenant","Fine-grained permissions within the tenant",[10,33,34],{},"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.\nFor 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.",[14,36,38],{"id":37},"frequently-asked-questions","Frequently asked questions",[10,40,41,45,48,49,52,54,55,58,60,61],{},[42,43,44],"strong",{},"Does a separate database per tenant mean that data is stored physically separately?",[46,47],"br",{},"\nYes, every tenant gets its own separate database instead of shared tables with a tenant identifier as a filter column.\n",[42,50,51],{},"Can individual tenants be run on a completely separate server?",[46,53],{},"\nFor particularly large tenants this is possible – including their own host and their own credentials, separate from the shared server infrastructure.\n",[42,56,57],{},"How is it controlled within a tenant who sees which records?",[46,59],{},"\nThis 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.\n",[42,62,63],{},"How important is true database isolation for your company's data protection requirements?",[14,65,67],{"id":66},"read-more","Read more",[69,70,71,79],"ul",{},[72,73,74],"li",{},[75,76,78],"a",{"href":77},"\u002Fen\u002Fblog\u002Foutgoing-notifications-workflow-http-request\u002F","Notifying other systems: HTTP requests straight from the automation workflow",[72,80,81],{},[75,82,84],{"href":83},"\u002Fen\u002Fblog\u002Fincoming-webhooks-structured-data-into-crm\u002F","Incoming webhooks: bringing external data into the CRM in a structured way",[10,86,87],{},[75,88,90],{"href":89},"\u002Fen\u002Fappointment-request\u002F","Book a demo",[14,92,67],{"id":93},"read-more-1",[69,95,96],{},[72,97,98],{},[75,99,101],{"href":100},"\u002Fen\u002Fblog\u002Fai-agents-automated-document-processing\u002F","AI agents behind the scenes: automated document processing",{"title":103,"searchDepth":104,"depth":104,"links":105},"",2,[106,107,108,109,110,111],{"id":16,"depth":104,"text":17},{"id":23,"depth":104,"text":24},{"id":30,"depth":104,"text":31},{"id":37,"depth":104,"text":38},{"id":66,"depth":104,"text":67},{"id":93,"depth":104,"text":67},[113],3330,"2026-06-27T09:00:00",false,null,"md","\u002Fmedia\u002F2026\u002F07\u002Fdatenbank-pro-mandant-multi-tenancy-1tool.jpg","en",{},"2026-07-25T08:25:52",true,"\u002Fen\u002Fblog\u002Fdatabase-per-tenant-multi-tenancy-1tool",{"title":5,"description":12},"A separate database per tenant instead of shared tables: how 1Tool solves multi-tenancy at the infrastructure level.","Database per tenant: multi-tenancy in 1Tool | 1Tool","database-per-tenant-multi-tenancy-1tool","\u002Fen\u002Fblog\u002Fdatabase-per-tenant-multi-tenancy-1tool\u002F","en\u002Fblog\u002Fdatabase-per-tenant-multi-tenancy-1tool","posts","2GHF1ZlGhxk95dqJCfiUaEstJjJjaY7_uHZrWRag3i4",1791582058396]