Row-Level Security Needs a Table-Operation Permission Review

A SaaS platform can pass a convincing tenant-isolation demonstration and still leave an important question unanswered. Two customers sign in, each sees only its own orders, and the application returns the expected results. That demonstrates a useful row-access boundary. It does not establish what the same application account, a background worker, or a maintenance account can do to the table as a whole.

For teams comparing distributed databases, the practical decision is which responsibilities each boundary carries. Row policies, table privileges, application identity, and allocated computing resources address different parts of isolation. A procurement checklist that combines them into one “tenant isolation” checkbox can hide an operational permission that deserves a separate decision.

Start with the operation the policy actually covers

PostgreSQL 18 describes row-level security as an additional restriction on normal row access, alongside ordinary SQL privileges. Its documentation explicitly excludes whole-table operations such as TRUNCATE and REFERENCES from row security. That distinction does not give every user permission to perform those operations. The relevant privileges still need to be considered separately. See the official row-security documentation and GRANT reference.

This is a reason to ask a more precise question than whether a database supports row-level security. The buyer needs to know whether the accounts used by the service have an appropriate combination of row restrictions and operation privileges. A successful customer-filtering test answers one question about that combination, rather than certifying every possible action.

Separate the application account from maintenance authority

Consider a hypothetical shared orders table. The web service reads and changes customer orders. A scheduled maintenance process manages the table’s lifecycle. These responsibilities can require different authority, even though both processes are associated with the same SaaS product.

The review should identify which account actually performs each task. A document describing the intended web-service role is insufficient if deployment uses a different account. Equally, a maintenance privilege granted for a narrow operational need should not quietly become part of every request-serving account. The objective is a deliberate separation of responsibilities, with exceptions explained in ordinary operational terms.

Check owner and privileged-role assumptions

The PostgreSQL documentation says table owners normally bypass row security, while owners can be made subject to it through FORCE ROW LEVEL SECURITY. Superusers and roles with BYPASSRLS bypass row security. These distinctions matter when an isolation demonstration and the deployed application use different roles.

A useful review therefore records the actual application identity, ownership arrangement, and privileged maintenance identities. It should not assume that enabling a policy changes every role into an ordinary restricted user. Nor should it assume that ownership always bypasses policies regardless of configuration. The question is which documented behavior applies to the particular role and operation being evaluated.

Keep resource isolation in its own comparison column

OceanBase’s version 4.3.5 tenant-resource documentation describes resource units, configurations, and pools used to allocate resources to tenants. This gives a SaaS buyer a separate platform-level question: how are service resources assigned and governed? The tenant-resource reference supports discussing that allocation model.

It does not establish that an OceanBase resource tenant is equivalent to a PostgreSQL row policy, or that either mechanism automatically implements the application’s customer model. A service with many customers inside one database tenancy still needs an explicit account and data-access design. OceanBase is relevant to a resource-allocation comparison; its suitability for the complete isolation requirement depends on the deployed arrangement and demonstrated access behavior.

Use a controlled example without risking customer data

A buyer can request a demonstration in a disposable environment using synthetic customer records. The demonstration should cover the expected row-access behavior and a separate permission review of whole-table operations. Any destructive operation belongs only in an explicitly disposable test context, with no connection to production or real customer data.

The evidence should distinguish an operation denied for lack of privilege from an operation constrained by a row policy. Those outcomes support different conclusions. Recording the role, operation, expected outcome, and observed result makes the demonstration useful for later deployment reviews. These are proposed acceptance checks, not results of tests performed for this article.

Approve the combination of boundaries

The final selection should connect each requirement to the mechanism and operating responsibility that addresses it. A shared-table design may use row restrictions alongside carefully scoped privileges. A platform may additionally allocate resources among database tenants. Neither description removes the need to explain application identity and maintenance authority.

A clear approval would state who can access customer rows, who controls whole-table actions, and how resource allocation is managed. That is more useful than a general claim that one product “has isolation.” It also gives PostgreSQL-based designs and OceanBase-based designs a fair comparison: each must demonstrate the specific boundaries on which the proposed SaaS service will rely.