Allow configuring PostgREST pool and pooler in Supabase CLI (api.db_pool, api.use_pooler)

[3h4x]

Problem:
In local development with Supabase CLI, the PostgREST container is hardcoded to use a max pool size of 10 (PGRST_DB_POOL=10). Under integration test load, this saturates the pool and results in intermittent 502s (e.g., “Connection reset by peer” / “Invalid response from upstream”). There is currently no supported way to increase the PostgREST connection pool or route PostgREST through the built-in pooler (Supavisor) via config.toml.

Current behavior:
PostgREST connects directly to Postgres (docker internal host/port).
Pool size is fixed at 10 (logs show “Connection Pool initialized with a maximum size of 10 connections”).
db.pooler settings in config.toml don’t affect PostgREST because it bypasses the pooler.
Setting PGRST_DB_POOL in .env doesn’t propagate to the CLI-managed API container.
What I tried

Enabled [db.pooler] with default_pool_size = 20 — no effect on PostgREST.
Set PGRST_DB_POOL=50 in .env — not passed through to container.
Changed external ports — not relevant; internal networking remains the same.

Expected behavior:
Add CLI configuration options to control PostgREST connection strategy and pool size:

api.db_pool: integer — pass-through to PGRST_DB_POOL for the API container.
api.use_pooler: boolean — make PostgREST connect through Supavisor instead of directly to Postgres.
Optional/related settings that would also help:

api.db_prepared_statements: boolean — pass-through to PGRST_DB_PREPARED_STATEMENTS.
api.db_pool_timeout: integer — pass-through to PGRST_DB_POOL_TIMEOUT.
api.db_extra_env: map — pass-through arbitrary env for PostgREST for advanced tuning.
Why this matters

Integration tests and local load testing regularly exceed 10 concurrent PostgREST connections.
Without configurability, developers hit flaky 502s and must maintain a parallel PostgREST setup or throttle tests significantly.
Aligns local behavior with production patterns where Supavisor/pool settings are standard.
Proposed implementation (high-level)

Extend supabase/config.toml schema with:
[api] db_pool = 50 use_pooler = true db_prepared_statements = false db_pool_timeout = 30
When starting the API container:
If use_pooler = true, set PostgREST’s DB host/port to Supavisor’s.
Apply env mappings:
PGRST_DB_POOL = api.db_pool
PGRST_DB_PREPARED_STATEMENTS = api.db_prepared_statements
PGRST_DB_POOL_TIMEOUT = api.db_pool_timeout
Include any api.db_extra_env entries
Validate values and reflect them in logs for discoverability.
Environment

Supabase CLI:
PostgREST: 13.0.5 (CLI default)
OS: <your OS/version>
Docker:
Logs / evidence

Example:
PostgREST log: “Connection Pool initialized with a maximum size of 10 connections”
Symptoms under load: intermittent 502s with “Connection reset by peer” / “Invalid response from upstream”
Workarounds used

Running a separate PostgREST container with PGRST_DB_POOL=50–100 and pointing tests to it.
Reducing test concurrency.

Additional context:
This request is specifically for local development ergonomics and parity with production behavior. Routing PostgREST through Supavisor (api.use_pooler = true) plus configurable pool size will make local testing far more reliable without custom container overrides.

Acceptance criteria
Users can set api.db_pool in config.toml and see the value reflected in PostgREST logs.
Users can set api.use_pooler = true and confirm PostgREST connects via Supavisor (e.g., by hostname/port/logs).
Documented in the CLI config reference with examples.

Thank you!