The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →PostgreSQL row-level security (RLS) can enforce tenant-specific access in a shared-table design by filtering existing rows and checking proposed writes inside the database. It is one part of the security boundary, not a guarantee by itself: database roles, policy rules, and how the application manages tenant context all matter. Pool, bridge, and silo architectures make different trade-offs in resource sharing, operational effort, and tenant separation.
Should you use a shared database, a schema per tenant, or dedicated infrastructure?
The usual terms describe how much database structure or infrastructure tenants share. AWS describes pool as shared tables in a shared schema, bridge as tenant-specific schemas or databases on shared infrastructure, and silo as dedicated tenant infrastructure. Its guidance recommends pool for large numbers of smaller tenants, and silo when stronger resource control or very large or performance-sensitive tenants are important; these are provider-specific recommendations, not rules that fit every workload. See AWS Guidance for Multi-Tenant Architectures and its managed PostgreSQL decision matrix.
As an Amazon Associate I earn from qualifying purchases.
| Model | Data and resource separation | Operational and workload fit | Cross-tenant work |
|---|---|---|---|
| Pool | Tenants share tables and a schema; tenant identity is represented in rows. Compute and storage resources are also shared. | Can simplify provisioning and centralize schema changes for many smaller tenants. Shared resources mean tenants can contend with one another, and per-tenant resource control is limited. | Shared tables can make authorized cross-tenant reporting and relationships straightforward, but the application must deliberately control which operations may span tenants. |
| Bridge | Tenants have separate schemas or databases on shared infrastructure. | Provides a structural boundary between tenants while retaining shared infrastructure. Provisioning, migrations, backups, monitoring, and connection selection may need to account for each tenant’s separate database construct. | Queries across tenants generally need to account for the separate schemas or databases rather than treating all tenant rows as one table. |
| Silo | Each tenant has dedicated infrastructure, such as a separate database stack or instance. | Offers more control over an individual tenant’s resources and can suit large or performance-sensitive tenants. It typically increases the number of environments and per-tenant operational tasks. | Cross-tenant reporting must deliberately aggregate across the separate environments. |
These are architectural tendencies, not guarantees: a separate schema does not automatically prevent every privilege mistake, and dedicated infrastructure does not remove the need for sound access controls. AWS’s managed PostgreSQL guide frames its recommendations for its managed-service context. Validate the trade-offs against your hosting environment, workload, tenant sizes, and operational capacity.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteWhat does PostgreSQL RLS enforce?
RLS adds row-level authorization alongside ordinary SQL privileges. Once enabled for a table, applicable policies govern which rows a role may select or modify. If no policy applies, PostgreSQL uses default deny: no rows are visible or modifiable through the covered operations. PostgreSQL 18 documents this in Row Security Policies. RLS does not replace grants: the role still needs the relevant table privileges, and operations such as TRUNCATE are not controlled by row policies.
#1 Best Overall
Enable RLS and understand who can bypass it
Enabling RLS does not create a tenant policy for you. The table owner ordinarily bypasses its policies, as do superusers and roles with the BYPASSRLS attribute. ALTER TABLE ... FORCE ROW LEVEL SECURITY subjects the owner to RLS, but it does not constrain superusers or BYPASSRLS roles. The runtime role used by the application therefore needs careful privilege design; a policy is ineffective for a role that bypasses it.
Separate row visibility from write validation
USING defines which existing rows a policy permits a command to see or target. For example, it can limit rows returned by a select or rows eligible for an update or delete. WITH CHECK evaluates the proposed row values for inserts and updates. It is especially important when a write could assign a row to another tenant. For policy forms that support it, omitting WITH CHECK can make PostgreSQL use the USING expression for that check; explicit write rules make the intended boundary easier to review. The details are in PostgreSQL’s CREATE POLICY documentation.
Rank #2
Policy combination changes the effective rule
Policies are not simply accumulated as extra filters. Permissive policies, the default, combine with OR; restrictive policies combine with AND. At least one permissive policy must grant access, so a restrictive policy by itself does not authorize rows. Policies can also be limited by command and role. Review the complete set that applies to each operation rather than judging a single policy in isolation.
What might a pool-model policy look like?
The following is an illustrative pattern, not a complete application implementation. Assume a table has a tenant_id UUID column and the application uses a non-owner runtime role named app_runtime without BYPASSRLS. The tenant context must be derived from a trusted, authenticated identity; a tenant value supplied or changeable by an untrusted caller is not authorization.
ALTER TABLE app.records ENABLE ROW LEVEL SECURITY;
CREATE POLICY records_tenant_boundary
ON app.records
FOR ALL
TO app_runtime
USING (tenant_id = current_setting('app.tenant_id', true)::uuid)
WITH CHECK (tenant_id = current_setting('app.tenant_id', true)::uuid);Here, USING limits which existing records the role can access, while WITH CHECK prevents it from inserting or updating a record with a tenant ID that does not match the current context. With the optional second argument to current_setting, an unset setting returns null; the equality test does not match a tenant row. A malformed non-null UUID value can still cause a cast error.
This example does not establish how to safely set and reset tenant context in an application or connection pool. That lifecycle is part of the security design: bind context to the authenticated tenant, scope it correctly to transactions or sessions, and prevent state from leaking between requests that reuse a connection. Review the behavior with your PostgreSQL version, runtime role, transaction flow, and every applicable policy before relying on it.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What RLS does not settle
Ordinary privileges and privileged helpers
RLS is an additional check, not a substitute for granting only the SQL privileges a runtime role needs. Policy expressions run with the querying user’s privileges, so referenced tables and functions must be accessible as required. PostgreSQL discusses security-definer functions as one way to access data unavailable to the caller; such a helper executes with elevated privileges and needs careful design and review.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Referential integrity and information leakage
Referential-integrity checks are not governed by row security. In some designs, constraint outcomes can reveal information about values in otherwise hidden rows. Consider this when choosing keys, constraints, and error behavior, especially where tenant identifiers or other sensitive values may be probed.
Coverage across commands
Check each operation the application can perform, including inserts, updates, deletes, selects, and any administrative or bulk operation. Confirm that policies apply to the intended roles and commands, account for how policies combine, and separately review operations that row policies do not cover. Table ownership and bypass attributes should be checked alongside the policy definitions.
Does transaction isolation provide tenant isolation?
No. Tenant data isolation determines which tenant’s rows a database role may access; transaction isolation determines what concurrent transactions can observe and which concurrent outcomes are permitted. PostgreSQL’s Transaction Isolation documentation says Serializable transactions have effects equivalent to running them one at a time in some order. That concurrency guarantee does not decide whether a role is entitled to a particular row. A system may need both sound tenant authorization and an appropriate transaction isolation level, but one does not replace the other.
How should you choose and review the design?
- Choose pool when sharing tables and resources fits the tenant mix and the operational simplicity is worth the need for rigorous row authorization and careful shared-resource management.
- Choose bridge when tenant-specific schemas or databases provide a useful separation boundary on shared infrastructure, and the team can manage tenant-specific provisioning and database operations.
- Choose silo when per-tenant resource control or separation is a priority that justifies dedicated infrastructure and its associated operational workload.
- For any model, map each tenant-facing operation to the role and data it can reach. In a pool design, inspect every applicable RLS policy, grants, owner and bypass status, tenant-context lifecycle, and integrity constraints as parts of one boundary.
AWS’s pool-model guidance discusses shared resources and considerations for that design. Neither it nor the PostgreSQL documentation establishes a universally best model or a performance guarantee; the decision depends on your tenant profile, workload, hosting choices, and ability to operate the resulting system.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
