multi-tenant with row-level security: why it matters for your privacy.

"Multi-tenant" describes an architecture where a single platform serves many different customers on the same technical infrastructure, instead of spinning up a separate server for each one. It's the model behind almost all modern B2B software: your email account, your CRM, your ecommerce platform. The alternative — a dedicated server per customer — is more expensive to operate and harder to keep updated, which is why almost no serious SaaS uses it today.

The delicate part of multi-tenancy isn't technical, it's about trust: if my business and my competitor's use the same platform, what guarantees that my conversations, my contacts and my catalog never mix with theirs?

The most common way to isolate customers in a multi-tenant SaaS is for the application code to add, on every database query, a condition like "only fetch this workspace's data". It works most of the time, but it depends on absolutely every query, in every endpoint, in every future version of the code, including that condition correctly. It only takes one developer forgetting one filter in a single route — something that has happened at large, well-known platforms — for one customer to see, even if just for a few minutes, data that doesn't belong to them.

That risk is neither hypothetical nor unique to heysteff: it's the central problem of any multi-tenant architecture that entrusts isolation solely to the discipline of the application code.

Row-Level Security (RLS) is a feature of modern relational databases — Postgres, the one heysteff uses, among them — that lets you define an access rule directly on a table: "this query can only see the rows that belong to the current workspace". The rule lives in the database, not in the application code, and it's applied automatically on every query regardless of which part of the system is running it.

The practical difference is enormous. With RLS active, even if an application query had a bug and "forgot" to filter by workspace, the database would still block access to another customer's rows, because the security rule doesn't depend on that query: it's a requirement enforced underneath, at the database engine level. It's the difference between trusting everyone to remember to lock the door and having a lock that closes on its own.

Not every multi-tenant platform implements RLS: it adds design complexity and requires thinking about the data model with isolation in mind from the start, not as a patch later on. That's why, when a B2B software vendor explicitly mentions Row-Level Security as part of its architecture, it's a concrete signal — not a marketing slogan — that isolation between customers was taken seriously from the database design onward, with a defense layer beyond the application code.

At heysteff, every table that stores a customer's data — conversations, contacts, channel credentials, automation flows — has RLS enabled with both read and write rules. The application's internal operations run inside that per-workspace isolation context; only specific, audited administrative processes can operate outside it when the operation requires it by nature (for example, the billing system).

If you're evaluating any SaaS platform that will handle your customers' data — not just heysteff — it's worth asking directly: does the isolation between customers depend solely on the application code, or is there a security layer enforced at the database level? It's a technical question, but the answer tells you a lot about how much privacy was designed in from the start, rather than bolted on later.

• How heysteff protects your customers' data
• Uptime and transparency: how to read our status page
• Security at heysteff
• Frequently asked questions