The proxy

Your application connects to the LokaDB proxy as it connected to Postgres: same wire protocol, same SQL, a new host and port. The proxy parses every statement with the real Postgres parser, finds the organization in it, and tells Postgres which partition to use. A statement that touches only one organization therefore never reaches another customer's database.

Finding the organization. Equality, IN and = ANY(array) on the tenant column, the row key or a foreign key, in literals and in bound parameters; INSERT … VALUES and UNNEST; joins through equal columns; subqueries that name the organization. Relations your schema does not declare, and unique keys, can be declared in the spec. Routing has the full rules.

Narrow, never widen. The proxy only takes the organization from the statement itself. A wrong guess yields an empty or partial answer, never another organization's rows. A statement that names no organization is refused by default (the reject fanout policy) instead of being sent to every customer database; you can allow reviewed reports.

Cooperative mode. The application can name the organization itself (SET LOCAL lokadb.tenant), so that the proxy does not have to find it in the statement: see profiles and cooperative mode.

Connections. The proxy has a built-in connection pool, on by default, and keeps prepared statements across enable and migrations. A pooler may stand in front of the proxy in any mode; between the proxy and Postgres use a direct connection or a pooler in session mode.

Not an authorization layer. If the application asks for another organization's document by id, the proxy routes the query to where that document lives. Who may read what is still the application's job. See the security model.