Network restrictions and SSL cover Postgres, not the HTTPS APIs

The answer. Two settings harden the connection string, and they are easy to misread as "the project is locked down". Network restrictions are an allow-list of CIDRs enforced in front of Postgres and its pooler: a connection from any other address is refused before authentication. They say nothing about the HTTPS services, which is what your app and every client library actually use, so RLS and key hygiene remain the controls that matter there. SSL enforcement rejects plaintext connections on the same two endpoints; pair it with sslmode=verify-full and the project's CA certificate in any tool that holds the database password. Both fit a setup like ours, where the application reaches the database only through PostgREST and a Worker, and direct connections come from a short list of places: CI runners, a migration host, an analyst's machine.

The pattern.

npx supabase network-restrictions update --project-ref <ref> --experimental \
  --db-allow-cidr 203.0.113.10/32 --db-allow-cidr 2001:db8::/64        # both families if the host resolves to IPv6
npx supabase network-restrictions get --project-ref <ref> --experimental
npx supabase ssl-enforcement update --project-ref <ref> --enable-db-ssl-enforcement --experimental

psql "postgres://…@…pooler.supabase.com:5432/postgres?sslmode=verify-full&sslrootcert=prod-ca-2021.crt"

Watch out.

Edge Functions run outside your allow-list; with restrictions on they lose direct database access and must use the Data API.
The pooler and the direct host share the same allow-list, but the direct host is IPv6-only; an IPv4-only allow-list can lock you out of it entirely.
Passing 0.0.0.0/0 and ::/0 removes the restriction; there is no "disable" flag, which is easy to misread in a runbook.