Skip to content

CONCEPT Cited by 1 source

postgresql.conf as control plane

Definition

Using postgresql.conf (and the reload-without-restart Postgres parameters that live in it) as the control-plane distribution channel to push runtime policy — here, Traffic Control rules and budgets — into Postgres worker processes, in preference to sending that policy over in-band SQL connections.

The distinction is important because during the incidents that most need urgent policy updates — CPU-saturated Postgres, all max_connections exhausted, worker-process starvation — opening a new SQL connection to issue SET or ALTER SYSTEM commands can itself be blocked. The config-file channel bypasses SQL-connection admission entirely: Postgres reloads postgresql.conf via a SIGHUP signal processed directly by the postmaster and propagated to workers between queries.

Source framing

From sources/2026-04-21-planetscale-behind-the-scenes-how-database-traffic-control-works:

"Traffic Control is meant to be used both proactively and during incident response. For incident response, it's important that rules take effect quickly. And they do! Rules created or modified in the UI generally take effect at all database replicas in just 1–2 seconds. How? Rules and budgets are stored as objects in the PlanetScale app. Any change to Traffic Control rules made in the UI or the API gets stored as rows in the planetscale database. Then it's serialized as JSON in the traffic_control.rules and traffic_control.budgets parameters for Postgres. Some Postgres parameters require restarting the server, but those two don't. So they cut the line and get sent immediately to postgresql.conf files on each database replica. Postgres reads the new config, and each worker process parses it into a rule set as soon as it completes whatever query it's executing. The rule set is in place before the next query begins."

And the robustness argument:

"One big advantage of using Postgres configuration files, rather than sending configuration over SQL connections, is robustness on a busy server. You may want new Traffic Control rules most urgently when Postgres is using 100% of its available CPU, 100% of its worker processes, or both. Changing config files is possible even when opening a new SQL connection and issuing statements wouldn't be."

End-to-end propagation pipeline

[PlanetScale UI / API]
       ↓  (write to planetscale app DB)
[planetscale DB rows]
       ↓  (JSON-serialise)
[traffic_control.rules / traffic_control.budgets Postgres parameters]
       ↓  (file-push to all replicas)
[postgresql.conf on each replica]
       ↓  (SIGHUP / parameter reload)
[worker process parses new config]
       ↓  (at next query arrival)
[new rule set in place before next query begins]

End-to-end latency: 1–2 seconds across all replicas.

Why worker-level reload is cheap

Each Postgres worker rebuilds its in-memory rule-set only once per config change, between queries, not mid-query. Because workers are process-per-connection, each worker has its own copy of the rule set — no cross-worker synchronisation is needed. The rebuild cost is amortised across every query the worker runs under the new rules.

Why SQL-channel push fails under load

Pushing control-plane state over SQL requires:

  1. Opening a new connection (blocked if max_connections reached).
  2. Authenticating (may itself consume worker slots or CPU).
  3. Executing SET / ALTER SYSTEM / INSERT (requires worker slot + CPU).
  4. Catalog updates / commit (requires WAL).

Any of these can fail under the overload conditions that most need the control-plane edit. File-based push sidesteps all four.

When reload-without-restart applies

The traffic_control.rules and traffic_control.budgets parameters are defined (by the pginsights extension) as reloadable without restart — i.e. they're in the PGC_SIGHUP or PGC_USERSET Postgres parameter context. Extension authors choose this classification when declaring the parameter via DefineCustomStringVariable / equivalent. Parameters in PGC_POSTMASTER context do require restart and cannot be used as a control plane this way.

Generalisation

The pattern extends beyond Traffic Control:

  • Logical-replication slots, auto-explain thresholds, work_mem tuning — any SIGHUP-reloadable parameter can carry policy signal.
  • The config-file channel is an out-of-band control plane relative to the SQL data plane — a canonical instance of concepts/control-plane-data-plane-separation.

Caveats

  • Config-file distribution itself must be reliable. The source leaves the file-push mechanism implicit (presumably: PlanetScale's fleet-control plane writes to each replica via the same mechanism that manages Postgres configs generally). A file-push-channel outage would defeat the purpose.
  • Parameter-size limits. Postgres GUC values have practical size bounds; JSON-serialising unbounded rule sets into a single parameter string is a scaling dimension. At some rule-set size, a different channel (maybe a shared-catalog table) would become necessary.
  • Ordering under concurrent edits. Two near-simultaneous UI edits producing two postgresql.conf writes must converge correctly on every replica. Ordering is presumably handled by the planetscale-app-DB transaction serialisation before the file write.

Seen in

Last updated · 517 distilled / 1,221 read