What is multi-tenant software?

The word tenant comes from the same idea as an office building. Many companies share one structure, the foundation, the wiring, the elevators, but each office has its own door, its own key, and its own name on the directory. In software, the shared structure is the codebase and infrastructure the vendor operates. The tenants are the customer organizations, each with its own users, data, and configuration.

The alternative, single-tenant software, gives every customer a separate installation. That model shifts the cost of hosting, patching, and upgrading onto each customer, which is why most modern SaaS is multi-tenant: one platform to maintain, updated for everyone at once, with isolation handled by design rather than by physical separation.

In Vercid, each client organization gets a workspace at its own subdomain, clientname.vercid.com. The subdomain does two jobs. It marks the boundary of the workspace: everything under that address belongs to that tenant and is visible only to that tenant's members. And it carries identity: the workspace renders in the client's own colors, fonts, and logo, so a client's staff see their company's system, not a vendor's.

Each workspace's dashboard is also composed per client from modular widgets, metrics, files, announcements, billing, and custom widgets, so two tenants on the same platform can look and work like two different products.

Subdomains draw the boundary. Row-level security enforces it. In a multi-tenant database, every record, a job, an invoice, an inventory line, sits in shared tables, tagged with the tenant it belongs to. Row-level security is a rule attached to those tables inside the database itself: before any row leaves the database, the rule checks whether the requesting user is a member of that row's tenant. If not, the row does not exist as far as that user is concerned.

The buyer-relevant point is where the enforcement lives. If separation depends only on application code, every screen, every report, every endpoint remembering to filter by tenant, then one missed check is a leak. When the database enforces the rule, a bug in the application still cannot return another tenant's rows, because the database refuses to serve them. Vercid enforces tenant separation with Postgres row-level security, so isolation is a property of the data layer, not a habit of the code above it.

Multi-tenant SaaS is secure when isolation is enforced in layers rather than in one place. The database layer decides which rows exist for a given user. The identity layer, Google SSO in Vercid's case, decides who that user is. Members, roles, and per-seat licensing decide what each person inside a tenant can see and do. And an append-only audit log records every change, so edits and deletions leave a trail instead of overwriting history. Nothing is silently lost.

The honest answer to "is it secure" is never a slogan. It is a description of enforcement you can verify.

You do not need to read a vendor's code to evaluate its isolation. Four questions cover most of it.

Vercid's answers, in order: Postgres row-level security in the database; per-tenant subdomains with full client-brand rendering; Google SSO with members, roles, and per-seat licensing; and an append-only audit log with full-text search.