Design row and column access boundaries ​

A SQL predicate can select rows for a report, and a view can omit columns. Neither becomes an enforced access policy for a client allowed to submit arbitrary SQL. Coordinator DB does not provide row-level policies, column grants or role-based permissions.

CREATE VIEW visible_orders AS
SELECT id, account_id, amount
FROM orders
WHERE account_id = 42;

This view is a reusable query definition. It does not prevent a directly connected user from asking for another account's rows in the base table. Use it for readability only when that distinction is acceptable.

For restricted readers, let the application authenticate the end user, select the permitted account context and execute only reviewed queries. Avoid accepting arbitrary table names, column lists or WHERE fragments from the caller. With embedded prepared statements, bind data values rather than concatenating input into SQL.

When SQL clients themselves must be isolated, design deployment and data separation around that requirement before making the service reachable. Separately review who can read diagnostic history, because logged SQL may contain application values. Do not claim isolation based solely on distinct usernames.

See security capabilities, views and prepared statements.