Multi-tenancy: 5 real scaling case studies
5 of the 73 engineering write-ups in our database are tagged with the technique "multi-tenancy". They come from 4 companies (Datadog, Atlassian, Cloudflare and OpenAI) and were published between 2022 and 2026. Stack that shows up most often in these stories: Go (2) and Kafka (2). 3 of the 5 state concrete scale numbers, for example "1B+ users across 40 regions" (OpenAI). Each card below links to our short summary and the original post.
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.
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.
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.
Husky: Exactly-once ingestion and multi-tenancy at scale
A deep dive on how Husky routes, shards and ingests events exactly once across tenants.
Introducing Husky, Datadog's third-generation event store
Datadog's Husky is a distributed, schemaless column store that keeps event data on object storage.