OpenAI · 2026
Scaling PostgreSQL to power 800 million ChatGPT users
OpenAI runs ChatGPT on a single-primary Postgres with nearly 50 global read replicas. Reads are offloaded, write-heavy shardable workloads move to Cosmos DB, and PgBouncer, cache leasing and multi-layer rate limits keep the primary safe.
800 million usersmillions of QPSread replicasconnection poolingcachingPostgreSQLAzurePgBouncer
Figma · 2026
How Figma manages sandboxes at scale
Figma's AI products needed secure places to run untrusted code, so the team built Nimbus, a centralized sandbox platform that product teams call through a simple namespace config and GetOrCreate/Get/Delete APIs. Nimbus picks a cloud provider, applies networking and security policies (trusted-host allowlists plus read-only GET/HEAD/OPTIONS to the rest of the internet, credentials decrypted only on the way out to their intended destination), and runs sandboxd inside each box for process supervision and metrics. Warm pools of already-running sandboxes cut provisioning latency by about 90% versus cold starts, raised availability from 99% to 99.95%, and absorb minutes of provider outages while Postgres claim transactions and a Redis health-check queue keep the pool correctly sized and singly assigned.
tens of thousands of sandboxes across productswarm pools cut provisioning latency ~90%warm poolsmulti-provider failovernetwork policy isolationNimbusPostgresRedis
PlanetScale · 2026
Designing a planned switchover for minimum disruption
When a Neki shard's primary has to step aside for a pod replacement, kernel upgrade or cell move, PlanetScale does a planned switchover instead of stopping Postgres the way Patroni does, so a failed switchover can quickly fall back to the old primary. Admin, Neki's control plane, first validates shard state, the target replica, logical failover slots and Postgres settings. Routers then proactively buffer primary-bound queries, the primary defaults new transactions to read-only, and the other replicas are disconnected to pin a final WAL position the target must replay. If the target can't catch up before a deadline, a config reload makes the old primary writable again. Buffered queries are replanned against the new primary, so apps see added latency instead of errors, and every acknowledged commit is on the target when it is promoted.
one primary and multiple replicas per shardsynchronous replication ANY 1 across eligible replicasplanned switchoverquery bufferingsynchronous replicationPostgreSQLNekiKubernetes
Netflix · 2026
Single-tenant Titus: VM-level isolation on a multi-tenant container platform
Titus, Netflix's Kubernetes-based container platform, launches millions of containers a week on tens of thousands of EC2 instances, packing many teams onto shared hosts. cgroups can't fence last-level cache, memory bandwidth or the global lock in HTB network shaping, so a small-packet flood from one container could starve its neighbors, and stateful streaming jobs like Flink would fall behind and need minutes to catch up. After ruling out microVMs (Firecracker, Kata), gVisor and moving teams to plain EC2, Netflix added an allowlisted single-tenant mode: the federation layer tags eligible tasks, the autoscaler launches the smallest instance that fits each one just in time, and anti-affinity, taints, no preemption and no repacking keep it alone on its host, all behind the same Titus API. Flink, streaming connectors and telemetry pipelines now report stable operation, and the shared fleet packs more densely because sensitive workloads no longer need anti-affinity spreading. The cost is slower launches, since every task waits for its own instance, and fixed host overhead that can take tens of percent of a small node.
millions of containers launched per weektens of thousands of EC2 instances across multiple AWS regionsworkload isolationmulti-tenancyautoscalingTitusKubernetesAWS EC2