The isolation problem: why one tenant seeing another is an existential bug
Start with the threat model. In a multi-tenant data platform you owe every customer three guarantees. Confidentiality: tenant B cannot read tenant A's data. Integrity: tenant B cannot modify it. Availability: tenant B cannot starve tenant A of resources. A single failure on the first guarantee can end a company. In a pooled model, a single missed WHERE clause or a misconfigured row-level security policy is all it takes to turn shared infrastructure into a data-leak incident.
You have three architectural choices.
Logical isolation (pooled). All tenants share the same tables. A tenant_id column plus row-level security enforces the boundary. This is the cheapest model and the simplest to scale: one connection pool, one migration path, one backup strategy. A single database can hold an enormous number of tenants. The risk is that your entire isolation guarantee rests on a predicate being applied correctly on every query.
Physical isolation (siloed). Each tenant gets its own schema, database, or warehouse. This is the strongest boundary and the easiest compliance story. It is also the most expensive: costs rise roughly linearly with every customer, and operational overhead (backups, monitoring, patching, connection management) multiplies. It works for dozens to hundreds of tenants, not tens of thousands. More than one SaaS company has watched a per-tenant database strategy turn into an unsustainable cloud bill.
Hybrid (bridge). Shared compute and network with dedicated data or identity for sensitive tenants. Enforcement moves up the stack, from the storage engine to the query planner. This is where a semantic layer earns its place.
Here is the part most teams underestimate. Even when your rows are perfectly isolated, meaning is not. Consider two tenants on the same platform. Both have Customers, Revenue, Churn, and Subscriptions. Underneath, the definitions diverge. Revenue includes refunds for tenant A and excludes them for tenant B. Churn is measured over 30 days for one and 90 days for another. If an AI agent or a shared metric service resolves "revenue last quarter" against the wrong tenant's definition, no row ever crossed a boundary and the answer is still wrong. Isolation is therefore two problems stacked: keep the data apart, and keep the definitions apart.
Why database row-level security alone is insufficient
Row-level security is excellent and you should use it. It is also not a complete answer for a customer-facing SaaS platform. Walk through how it actually works in the four systems most teams run.
PostgreSQL RLS. You enable a policy that appends a predicate to every query automatically:
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
ALTER TABLE invoices FORCE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON invoices
USING (tenant_id = current_setting('app.current_tenant')::uuid);The application sets the context per transaction:
BEGIN;
SET LOCAL app.current_tenant = '8b3a3b3a-0c07-4ef9-8db6-9c1f0b111234';
SELECT * FROM invoices; -- silently filtered to this tenant
COMMIT;SET LOCAL matters: it scopes the variable to the transaction so a pooled connection never leaks a previous request's tenant. The footguns are well documented. A role with BYPASSRLS or a view owned by a superuser skips the policy entirely. Forget WITH CHECK and you can write rows no tenant can read. Leave the context unset on a pooled connection and you either see nothing or, worse, the wrong tenant. And the database enforces the row boundary, not the meaning of a metric.
Snowflake. Row access policies and dynamic data masking are evaluated at query runtime. Snowflake's own multi-tenancy guidance for Cortex Agents pairs immutable session attributes with row access policies and is explicit that this is a "shared responsibility model": Snowflake provides the tools, and you are responsible for configuring them correctly. Performance is not free either: a row access policy adds a predicate to every query, and "On tables with 100M+ rows, this can add 10-30% overhead depending on the policy complexity," unless the policy column aligns with the clustering key.
Databricks Unity Catalog. Row filters and column masks are SQL UDFs, now backed by attribute-based access control policies, governed tags, and automated classification. Unity Catalog fails securely: on unsupported runtimes "no data is returned." Strong governance, but the unit of control is the table and column, not a per-tenant metric definition.
BigQuery. Authorized views for row filtering, native row-level security policies, and column-level security through Data Catalog policy tags. Again, all enforced at the data layer.
Every one of these enforces isolation at runtime, on the data, after a query has been formed. They share three structural weaknesses for SaaS at scale. First, they trust that the right tenant context was set on the right connection. Second, they protect rows and columns but not the business meaning layered on top. Third, the audit trail begins after the query runs, so reconstructing exactly what each tenant could see means exhaustive runtime logging.
How a semantic layer enforces isolation at compile time
A semantic layer sits between your users, your AI agents, and your warehouse. Instead of running a query and trimming the result, it resolves the request against a model of your business, evaluates tenant context, and decides what is allowed before any SQL exists. The difference is the order of operations: policy shapes the plan, then the plan compiles to SQL, then the SQL runs.
Concretely, compile-time enforcement does four things.
It resolves meaning within scope. A robust multi-tenant semantic model defines meaning across layered scopes: a Global scope for invariant concepts (what a Customer is), a Tenant scope for business-specific definitions (what Revenue means here), a Persona scope for role-based interpretation (Finance vs Product), and a User scope for individual context. Revenue stops being one global definition and becomes a scoped object:
{
"concept": "Revenue",
"scope": {
"tenant_A": "SUM(order_amount - refunds)",
"tenant_B": "SUM(order_amount)"
}
}The same natural-language question compiles to different SQL per tenant. That closes the semantic-leakage gap that pure row filters cannot touch.
It shapes an allowed subgraph before planning. The requester's identity and persona resolve a slice of the model they are permitted to traverse. Compilation happens entirely inside that slice. If a metric depends on a node outside the allowed scope, resolution fails. There is no query to run, no row to trim, no masked column to leak through a join key. This is the inversion of post-hoc masking, which trusts that every query runner remembered to apply the masking view, every BI tool refreshed its column list, and every analyst followed the policy.
It proves joins on the graph. A persona without access to one side of a relationship cannot use it as a join key. Ambiguous or unauthorized join paths fail compilation rather than silently producing a wrong or over-broad number.
It produces a deterministic, auditable result. Given the same tenant context, the same query, and the same model version, the output is identical. The audit record captures the model version, the identity context, the resolved definitions, the proven join paths, and the compiled SQL. The same question asked tomorrow against the same model version reproduces the same answer and the same trail.
A worked example: A support engineer for tenant B issues "show me refund totals by customer." In a pure-RLS world, the generated SQL joins orders to refunds, the row filter scopes rows to tenant B, but the refund table was never tagged sensitive for the support persona, so the column comes back in full. No cross-tenant leak, but a within-tenant policy bypass, and the auditor finds it months later. At compile time, the refund metric is outside the support persona's allowed subgraph, resolution fails, and the failure itself is logged with full tenant and persona context. The control is structural, not procedural.
Tenant context still has to get there. The semantic layer reads identity from JWT claims, session attributes, or a security context propagated through its APIs (Colrows accepts tenant identity over MCP, HTTP, and JDBC). This is the honest boundary of the approach.
The trade-offs, quantified
Cost. Logical isolation is the cheapest infrastructure and pushes the cost into policy evaluation. Physical isolation can be roughly 10 to 100 times more expensive at scale and guarantees no leakage. Semantic isolation adds a compile step that is cheaper than per-row runtime filtering and pays for itself in audit.
Performance. Snowflake row access policies can add 10 to 30 percent overhead on tables of 100M or more rows. PostgreSQL RLS, benchmarked at 50M rows across 10K tenants, averaged about 0.3ms of policy evaluation with composite indexes and "two orders of magnitude slower" without them, with the SET LOCAL call adding under 0.1ms. The lesson is identical across engines: index the tenant key, or pay for it on every query.
Scale. Logical and sharded models scale to thousands or millions of tenants. Physical isolation scales to dozens, maybe low hundreds, before operational overhead and cost dominate.
Security. The weak points of logical isolation are all configuration: a BYPASSRLS role, a stale tenant context on a pooled connection, a missing WITH CHECK, a wrong identity passed into the query. Compile-time policy reduces the blast radius because an unauthorized plan is never generated, but it does not remove your responsibility for authentication and credential isolation.
Audit complexity. Pure logical isolation requires exhaustive runtime logging to reconstruct what each tenant saw. Compile-time enforcement logs the policy decision and the compiled plan at the moment of compilation, which is a smaller, cleaner, and reproducible record.
Why regulators are about to make this table stakes
Every major framework converges on a single question: can you prove Customer B never saw Customer A's data, even in a join, even in an aggregate?
PCI DSS. Appendix A1 of PCI DSS, the additional requirements for multi-tenant service providers, is now mandatory under the active version of the standard (v4.0.1, the sole supported version since 31 December 2024). A1.1 requires that "Multi-tenant service providers protect and separate all customer environments and data." A1.1.2 requires controls "such that each customer only has permission to access its own cardholder data and CDE," and A1.1.4 (effective 31 March 2025) requires confirming the effectiveness of logical separation controls via penetration testing every six months. A1.2.1 requires per-customer audit logs available for review only by the owning customer. Logical separation is explicitly acceptable, but you must prove it works.
FedRAMP. Built on NIST 800-53, with SC-7 Boundary Protection, SC-3 Security Function Isolation, and SC-39 Process Isolation. Multi-tenant logical separation is permitted at Moderate and High when controls demonstrably enforce isolation, and a 2025 update (RFC-0013) modernized SC-7 to recognize VPCs and security groups rather than only Layer 3 subnetting. The recurring theme: demonstrable enforcement, not a diagram.
HIPAA. The Audit Controls standard, 45 CFR 164.312(b), requires mechanisms that "record and examine activity in information systems that contain or use" ePHI, and 164.312(a)(2)(i) requires a unique user ID per accessor. Multi-tenant systems must keep PHI from leaking between tenants and must produce a tenant-scoped audit trail. Enforcement settlements repeatedly cite organizations that logged access but never reviewed it: Memorial Healthcare System paid $5.5M in 2017, with OCR stressing that "organizations must implement audit controls and review audit logs regularly," and Excellus Health Plan paid $5.1M in 2021 over a failure to implement information-system-activity review and access controls.
SOX 404. Internal control over financial reporting rests on IT general controls: access management, change management, and segregation of duties. As one summary puts it, you must "demonstrate the chain of custody for every number." A multi-tenant analytics platform serving financial data has to show that access is segregated by tenant and that every definition and policy change is versioned and attributed.
GDPR. Article 17 (right to erasure) and Article 20 (right to data portability, in a "structured, commonly used and machine-readable format") both require operating at tenant and data-subject scope. You must be able to delete or export one customer's data without touching another's.
The common thread is that database row filters give you enforcement but not evidence. Compile-time policy decisions, versioned alongside business definitions and logged with tenant context, give you both. As data becomes a customer-facing product tier, with Salesforce and Snowflake shipping bidirectional data sharing and B2B buyers asking every vendor whether "Salesforce, Stripe, and Segment connect to my data warehouse, can you do that too?", the vendors that can prove isolation will win the regulated accounts and the rest will be stuck at the procurement gate.
Where Colrows fits, and where it does not
Colrows is a semantic execution layer. It compiles enterprise intent into governed, deterministic, dialect-perfect SQL, and it enforces tenant isolation in the planner before SQL is emitted. In a multi-tenant context that means four things.
First, tenant definitions and policies are scoped to tenant identity and versioned alongside business semantics in a typed graph, so the meaning of a metric is isolated, not just its rows. Second, governance is compile-time: RBAC, ABAC, and row and column predicates shape the allowed subgraph, and unauthorized plans are never generated. Colrows starts from default-deny, deny rules always win, and policies bind to classes (pii, financial, regulated) rather than table names that drift. Third, tenant context flows through MCP, HTTP, and JDBC, and enforcement happens before any database is touched. Fourth, isolation is deterministic: the same tenant, query, and model version yield the same result and the same audit record, which captures the graph version, the identity context, the resolved definitions, the proven join paths, and the compiled SQL. That record is the artifact a HIPAA, SOX, or PCI auditor actually wants.
Now the honest scope. Colrows governs data semantics in a multi-tenant context. It is not a complete multi-tenancy solution and does not replace your database engine's controls. The application is still responsible for propagating the correct tenant identity into the layer, and for credential isolation and authentication. Colrows enforces at the query-planning layer, not inside the storage engine, so it complements row-level security, masking, and physical separation rather than removing the need for them. Defense in depth still applies: keep your database row filters as a backstop, keep authentication and key management at the application edge, and use the semantic layer to enforce meaning and policy at compile time and to produce the deterministic audit trail.
The takeaway for builders: isolation is not one boundary, it is a stack. Storage keeps the rows apart. The semantic layer keeps the definitions apart and proves, at compile time and in an auditable record, that what executed is exactly what was authorized. In the age of customer-facing data products and tightening multi-tenant regulation, that proof is becoming the price of entry.
