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

Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II) | OpenAI October 23, 2026

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

How we optimized Azure Cosmos DB in our application storage platform, Habitat, to manage unprecedented growth. By Jon Lee, Hrachya Hakobyan, and Chaomin Yu, Members of Technical Staff All OpenAI products require fast, reliable access to data, provided by our storage platform, Habitat. It has to respond in milliseconds to over 1 billion users across 40 geographic regions. Our infrastructure faced an extraordinary challenge: supporting explosive growth and new use cases while continuing to improve reliability, performance, and product developer velocity. Solving that challenge required rethinking how our online storage platform was designed and operated. We constantly evaluated tradeoffs, following the pattern of: first become reliable enough for mission-critical product traffic, then fast enough for global users, and, finally, to deftly operate at massive scale. This two-part series explains how we developed Habitat from a simple client library and database into a globally distributed storage platform serving over 500 petabytes of data. Part I focused on Habitat’s evolution from a Python client to a service. It also covered the techniques that allowed us to push a Python-based service far beyond what many would consider practical. In this post, Part II, we walk through how we scaled the underlying storage component: Azure Cosmos DB. Through a close working partnership with the Azure team, we arrived at a viable multi-tenancy approach of co-managed containers, with excellent read performance at massive, global scale. Figure 01 · What is Habitat? Online storage platform Habitat is the online storage platform we built so OpenAI products can quickly and reliably access needed information. Play

• Request
• Response
• Changes (CDC)

Clients Online storage platform Storage resources

• ChatGPT
• API
• Codex
• Internal services
• And more

Habitat

• Caching Caches
• ACL policies Authorization
• Placement & data residency Data residency
• Encryption Data security
• Isolation Multi-tenancy
• Rate limiting Request shaping
• Routing Schema lookup · Data residency
• Azure Cosmos DB Online storage
• Nanobase Online storage
• Valkey Caches
• Blob storage Storage resources

CDC Services Change Data Capture

• Databricks
• Rockset
• Kafka
• And more

Making multi-tenancy reliable at scale

As companies scale, infra teams often evolve from running single-tenant systems to multi-tenant ones. Single-tenancy, where every product surface team maintains their own system, reduces blast radius and provides easy ownership boundaries and workload isolation. As teams and product surfaces grow, this becomes expensive to run. Single-tenancy makes every product team responsible for capacity planning and often results in significant over-provisioning. Conversely, multi-tenancy assigns control to a centralized database team, with better knowledge and experience for provisioning resources. But multi-tenancy creates its own problems, such as noisy-neighbor issues, where one tenant consumes an unusually large share of the resources to the detriment of the other tenants. In Habitat, we had to weigh all these tradeoffs to design a reliable, efficient, storage system at scale. Today, Habitat is a multi-tenant database layer for many OpenAI products, but we went through a circular journey from using one multi-tenant Azure Cosmos DB container to provisioning single-tenant backing containers to reverting to a multi-tenant container by default. We’re still very early in our multi-tenancy story on Habitat: we support a large set of use cases, but we’ve been able to defer investment in this area by leveraging Azure Cosmos DB’s built-in primitives wherever possible.

A simplified primer on Azure Cosmos DB containers

Before walking through our Azure Cosmos DB journey, some basic context:

• An Azure Cosmos DB account defines a set of containers and a replication policy
• Each container is provisioned for a certain amount of throughput in request units per second (RU/s)
• Data within each container is stored in a typical shard-by-specified-logical-partition-key manner with documented limits on storage and throughput per logical partition key
• Azure Cosmos DB handles sharding logical partition keys across fewer backing physical partitions, splitting them into multiple physical partitions when storage exceeds a threshold or when the container requires more physical partitions to sustain the provisioned throughput

Phase I: Relying on Azure Cosmos DB primitives

We originally allowed any client load through, relying on the stated 10K RU/s limit per logical partition key to provide back pressure. When we first set out, we also used only one default Azure Cosmos DB container in each account. This worked well enough, but proved problematic for a few reasons:

Logical partition key limits

Due to early API choices, we exposed logical partition key selection directly to clients. As a result, we have frequent collisions on commonly used partition keys, such as user\_id or workspace\_id, across different product use cases. Because these use cases shared Azure Cosmos DB limits on the same logical partition keys, the design constrained overall throughput for a given user. One common problem we faced in scaling Postgres before we moved to Habitat and Azure Cosmos DB was the ability for many requests from a very hot organization or hot key—one tenant generating a disproportionately high load—to take out the whole database. Significant collective effort was spent to cache those keys and build leases into cache misses so that the resulting cache miss load does not stomp on the underlying database. Figure 02a · Logical partition key limits Different clients, the same partition key Play### Noisy neighbors While documented data size and throughput limits apply to logical partition keys, the physical partition is actually where limits are enforced. In practice, this means logical partitions are unable to reach 10,000 RU/s. Instead, they share the physical partition’s limits with every other logical partition key colocated on that physical partition. This allowed noisy neighbors to impact many unrelated logical partition keys, with workloads operating on data for niche product features disrupting core login and signup flows. Figure 02b · Noisy neighbors...