# Apply request budgets without per-user quotas

Coordinator DB provides per-request processing limits and server admission controls. It does not implement per-user quotas, usage allowances or user settings profiles. Choose limits from the work you need to bound rather than treating every control as a user-specific policy.

## Separate resource budgets from admission

`max_execution_time`, `max_memory_usage`, `max_result_rows` and `max_response_bytes` bound a request. Its statements share the relevant budget. Server XML values form ceilings, and saved database settings can tighten them. A zero value removes only the added ceiling at that scope.

`max_connections`, `max_inflight_request_bytes` and `request_read_timeout` are server-only controls. They address admission and transport behavior rather than a customer's monthly usage. Do not attempt to persist them with `SET`.

## Inspect the effective policy

```sql
SELECT name, value
FROM system.settings
WHERE name IN ('max_execution_time', 'max_memory_usage', 'max_result_rows')
ORDER BY name
FORMAT csv;
```

Saved database changes affect other clients selecting that database, so coordinate administration changes. If an application needs per-account allowances, enforce and record that policy in its own request layer; the database settings do not identify those accounts.

See [request limits](https://coordinatordb.com/docs/concepts/features/configuration/settings/query-complexity), [server admission](https://coordinatordb.com/docs/reference/settings/server-settings/settings/max) and [server ceilings](https://coordinatordb.com/docs/concepts/features/configuration/settings/constraints-on-settings).