Why Your Workplace Data Needs an Isolated Database

When an IT or security team evaluates a workplace-booking tool, the questionnaire usually asks about encryption, single sign-on and where the servers are. It rarely asks the question that matters most for this category of data: is our organisation's data physically separated from every other customer's, or is it a column in a shared table?

Desk booking looks like low-risk data until you list what it contains: who was in which building on which day, at which desk, next to whom, with which visitors, and where they parked their car. That is a movement log of your workforce. It deserves the same isolation you would demand for HR or payroll data.

This article explains the two ways SaaS vendors store multi-tenant data, why Desk & Park gives every organisation its own isolated database, and what that decision means for the people who sign off on security, privacy and compliance.

Two architectures, one trade-off

Almost every SaaS product is multi-tenant: one application serves many customers. The question is where the boundary between customers lives.

Shared database, tenant column

The common approach. Every customer's rows sit in the same tables, and each row carries a tenant_id. Every query must filter on it. The application, not the database, is responsible for keeping customers apart.

It is popular because it is cheap to operate: one database, one schema, one migration. It is also where a whole class of security incidents comes from. A single missing WHERE tenant_id = ? in one of thousands of queries, one report that joins across tables without the filter, one caching bug, and customer A sees customer B's data. These bugs are not hypothetical; they are a recurring category of disclosed SaaS breaches, and they are hard to find because every individual query looks correct.

Isolated database per organisation

Each customer gets its own database, with its own tables, its own credentials and its own backups. The application connects to the right database for the organisation making the request. There is no tenant_id filter to forget, because there is no other tenant in the database to leak from.

It costs the vendor more operational discipline: provisioning, migrating and monitoring hundreds or thousands of databases instead of one. That cost is the point. It is paid by the vendor, once, in engineering, instead of by the customer, later, in an incident.

How Desk & Park is built

Desk & Park runs a database-per-organisation architecture. Concretely:

• A control plane holds only what is needed to route and bill: organisation names, plan, the mapping from an organisation to its database, and the platform's own audit trail. It contains no bookings, no floor plans, no employee directory.
• One PostgreSQL database per organisation holds everything about that organisation: users, roles, locations, maps, desks, parking spots, rooms, bookings, check-ins, visitors, notifications and the organisation's audit log.
• Per-organisation credentials. The application opens a connection to an organisation's database with credentials scoped to that database. A request from organisation A cannot be executed against organisation B's database even by mistake, because it never holds a connection to it.
• Per-organisation backups, restore and erasure. Backups are taken per database. Restoring one organisation to yesterday's state touches no one else. Deleting an organisation at the end of a contract means dropping its database, which is a verifiable, complete erasure rather than a DELETE WHERE tenant_id that hopes it found every row.

The application code is shared; the data is not. That is the boundary an auditor can point at.

What isolation buys the people who sign off

For the CISO: a smaller blast radius

A vulnerability in a multi-tenant query layer exposes every customer at once. With isolated databases, the same class of bug cannot cross an organisation boundary, because the boundary is enforced by the database engine and the connection credentials, not by application logic. Isolation does not make an application immune to bugs; it makes a bug in one place a single-customer problem instead of a platform-wide one.

For the DPO: clean answers to GDPR questions

Data-protection reviews ask predictable questions, and database-per-organisation gives them short answers.

The right to erasure and the obligation to restrict processing become database operations with a clear scope rather than application features that have to be tested for completeness.

For the compliance lead: a defensible control

Frameworks like ISO 27001 and SOC 2 ask a vendor to demonstrate logical separation between customers. "Every query filters on tenant" is a control that must be re-verified for every new query. "Every customer has their own database and credentials" is a control that is verified once, structurally, and holds as the product grows. The second is much easier to evidence, both for the vendor and for the customer's own audit.

For the CIO: predictable performance and lifecycle

One organisation's heavy report does not slow another's morning check-in rush, because they do not share tables or indexes. Migrations roll out per database, so a problem can be caught on one organisation before it reaches the next. Offboarding is a drop, not a cleanup project.

The rest of the security story

Isolation is the foundation, not the whole building. The controls IT teams expect sit on top of it, and they are worth listing because a good architecture with weak authentication is still weak:

• Single sign-on via OpenID Connect with your identity provider, and SCIM provisioning so joiners and leavers are created and deactivated from your directory, not by hand.
• Two-factor authentication (TOTP) and passkeys (WebAuthn), with an organisation-level policy to require MFA.
• Security policies per organisation: session timeout, password rules, IP allowlists.
• Active-session management so an administrator can see and revoke sessions.
• An audit log per organisation recording who changed what, in the organisation's own database.
• Payments through Stripe, so card data never reaches the platform at all.
• Role-based access: employees see and book; administrators configure; board members and managers get reports scoped to their teams.

None of these are unusual in enterprise SaaS. What is unusual is combining them with a data layer where the customer boundary is physical.

Questions to ask any workplace vendor

If you are comparing tools, these five questions separate marketing from architecture:

1. Is our data in a dedicated database, or in shared tables with a tenant column?
2. Are backups, restores and deletions performed per customer?
3. What credentials does the application use to reach our data, and are they scoped to us?
4. How do you evidence customer separation to your auditors?
5. Can a bug in a report or an export ever return another customer's rows?

A vendor with an isolated database answers all five in a sentence each. A vendor with a shared database has to describe a testing process.

Isolation should be the default

Workplace data is personal data about your employees' physical presence. The cheapest architecture for the vendor puts that data next to every other customer's and trusts the application to keep them apart. Desk & Park chose the more expensive one, so that the boundary between organisations is a database, not a filter.

You can read the technical detail in the architecture summary on the how-it-works page and in the platform's privacy policy. For an enterprise rollout with single sign-on, SCIM and a security review, the pricing page has the Enterprise contact.