Behind the scenes: How Database Traffic Control works

This post details the internal implementation of Database Traffic Control, explaining how it leverages Postgres extensions and hooks (ExecutorRun, ProcessUtility) to monitor query execution. It describes the four checks performed before query execution: rule matching, concurrency limit check, per-query cost limit check, and available capacity check. The post elaborates on cost prediction using planner cost estimates and exponential moving averages to derive a 'k' constant for estimating CPU/wall-clock time. It also explains the leaky-bucket rate limiting model for budgets, including burst limits and server shares, and the inverted model for debt management and eviction. Finally, it introduces the rule set data structure for efficient rule evaluation and the strategy for managing buckets in shared memory.