Multi-tenancy: 6 real scaling case studies

6 of the 94 engineering write-ups in our database are tagged with the technique "multi-tenancy". They come from 5 companies (Datadog, Atlassian, Cloudflare, Netflix and OpenAI) and were published between 2022 and 2026. Stack that shows up most often in these stories: Go (2) and Kafka (2). 4 of the 6 state concrete scale numbers, for example "1B+ users across 40 regions" (OpenAI). Each card below links to our short summary and the original post.

OpenAI · 2026

Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)

OpenAI's Habitat storage platform went from one shared Azure Cosmos DB container, to dedicated single-tenant containers that pushed capacity planning onto every product team, and back to a shared container by default once Azure added hot-key throttling, request-priority QoS and a new serverless mode where each physical partition scales to 10K RU/s and splits on RU usage. After failover and failback outages in late 2024, OpenAI and Azure now co-own testing and monitoring. Replicating small latency-critical datasets widely, a Valkey lookaside cache invalidated through the Cosmos DB change feed, and a Rust rewrite of the proxy cut global read p50 from about 120 ms to about 10 ms.

1B+ users across 40 regions500+ PB served by Habitatmulti-tenancyhot key throttlingCDC cache invalidationAzure Cosmos DBValkeyKafka
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
Cloudflare · 2026

Under the hood, off the hot path: how D1 scales to millions of databases

How Cloudflare's D1 keeps query execution at the edge while a separate control plane manages millions of SQLite databases.

millions of databasescontrol plane separationmulti-tenancyedge computingSQLiteDurable ObjectsWorkers
Atlassian · 2025

Migrating the Jira Database Platform to AWS Aurora

Atlassian migrated about four million Jira databases from RDS Postgres to Aurora, balancing reliability, downtime and cost.

4 million databasesdatabase migrationmulti-tenancycost optimizationPostgreSQLAWS AuroraAWS RDS
Datadog · 2023

Husky: Exactly-once ingestion and multi-tenancy at scale

A deep dive on how Husky routes, shards and ingests events exactly once across tenants.

exactly-once ingestionshardingmulti-tenancyGoKafkaFoundationDB
Datadog · 2022

Introducing Husky, Datadog's third-generation event store

Datadog's Husky is a distributed, schemaless column store that keeps event data on object storage.

columnar storagestorage/compute separationmulti-tenancyGoObject storage

Get new multi-tenancy scaling stories weekly

One email a week. No spam.

Companies in these stories

Browse all 105 topics →