Markdown edition

# Why OpenAI moved Habitat storage back to shared tenancy

> OpenAI says Habitat returned to shared Cosmos DB storage after dedicated containers made product launches hard to provision. Hot-key limits, request priority and caching carry the tradeoffs.

By BIGCHANGE.AI Editorial

Published: 2026-10-25T00:27:39.008Z
Updated: 2026-10-25T00:27:39.008Z
Canonical: https://bigchange.ai/blog/openai-habitat-shared-storage-tenancy-cosmos-db

![Conceptual charcoal illustration of an open, unbranded storage cabinet in a generic data-centre aisle.](https://bigchange.ai/api/media/file/habitat-shared-storage-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no OpenAI or Azure facility, equipment layout or measured result is depicted.

OpenAI's Habitat storage platform, which handles data lookups for ChatGPT and other products, returned to a shared Azure Cosmos DB container after trying dedicated containers for major workloads. The [October 23 engineering account](https://openai.com/index/scaling-storage-one-billion-users-part-two/) traces a recurring problem: isolation protected critical requests from heavy neighbors, but made each product team responsible for forecasting its own traffic. OpenAI says it moved back to shared tenancy after adding controls for hot keys, request priority and partition capacity with Azure's engineering team.

A shared container pools spare capacity, but a busy key can compete with unrelated requests on the same physical partition. A dedicated container sets a clearer failure boundary while turning a product launch into a capacity-planning event. Habitat's current design tries to retain the first benefit without accepting the full contention risk. The account documents OpenAI's internal operation; it does not establish that every change is available as a standard Azure Cosmos DB feature.

## The big change

- **What changed:** OpenAI says Habitat now uses a shared Cosmos DB container by default, backed by hot-key throttling, lower-priority background requests and a serverless mode developed with Azure. Its earlier shift toward dedicated containers had reduced the blast radius of incidents but increased planning work.
- **Why it matters:** The controls target different causes of interference: an exceptionally busy key, a background job competing with interactive traffic, and physical partitions losing per-partition throughput as storage grows. Together they explain how OpenAI says it reduced its need for per-team provisioning.
- **What to watch:** OpenAI reports no provisioning or noisy-neighbor incidents in the months since its change, but offers no independent reliability study or public recipe for reproducing the custom service arrangement. Global placement, cache freshness and change-feed operations still impose tradeoffs.

## Why one shared container became hard to operate

Habitat began with one default Cosmos DB container per account. According to OpenAI, different product uses often chose the same logical partition keys, such as `user_id` or `workspace_id`, causing them to share a key's limits. Even separate logical keys can land on the same physical partition, where they compete for assigned throughput. Microsoft [documents the underlying hot-partition behavior](https://learn.microsoft.com/en-us/azure/cosmos-db/troubleshoot-request-rate-too-large): concentrated requests can produce rate limiting despite unused throughput elsewhere in a container. OpenAI says that, in its deployment, load from niche features disrupted login and signup flows.

Storage growth created a second failure mode. OpenAI describes physical partitions splitting as they filled while the container's total provisioned throughput stayed constant. More partitions divided that throughput into smaller shares; a workload whose request rate was stable could therefore lose headroom. This is OpenAI's account of its provisioned setup, not a claim that every Cosmos DB configuration behaves identically.

OpenAI responded by creating separate containers for critical new uses and increasing provisioned throughput as partitions multiplied. That limited some incidents to a feature or service. It also left older critical data in the default container without a migration, and dedicated containers required teams to estimate launch demand. OpenAI says a new use could jump from internal test traffic to a much larger production load, forcing last-minute capacity changes. Separate containers reduced competition between workloads, while a pooled container made a new workload a smaller fraction of aggregate demand.

## How OpenAI says it made sharing viable again

The return to a shared default container depends on several controls described in the post. Hot-key throttling targets the busiest keys first, limiting how much of a physical partition one key can consume. Request tiers give bulk inserts and data extracts lower priority than interactive requests, so the background traffic is throttled first. OpenAI also says Azure developed an improved serverless mode for its use: physical partitions can reach 10,000 request units per second, and high RU use can trigger splits as well as storage growth. That addresses the team's earlier need to monitor partition counts and adjust provisioned throughput manually.

These mechanisms address different bottlenecks; none makes capacity or workload shape irrelevant. The reported result is narrower than a general guarantee. OpenAI says it has had no provisioning or noisy-neighbor incidents for months after the shift and that product teams need less advance planning. The post does not publish a controlled before-and-after reliability comparison, the precise operating configuration, or the cost of this arrangement. Microsoft describes [standard partitioning and throughput constraints](https://learn.microsoft.com/en-us/azure/cosmos-db/partitioning) separately. Operators should use Microsoft's current service documentation for their own limits rather than assume OpenAI's co-managed settings apply to their accounts.

## Data movement and caching move the boundary again

Shared tenancy is only one part of Habitat's response time. OpenAI says it routes selected small, latency-sensitive datasets to widely replicated accounts; some accounts reach all 40 Azure regions where it serves traffic. It cannot do this broadly because regional storage capacity is limited. Moving a dataset between accounts with different replication layouts required a routing and data-movement layer. Most other data remains subject to distance between the request and storage.

For read-heavy workloads, Habitat places Valkey lookaside caches near serving compute. OpenAI says Cosmos DB's change feed sends invalidations to those caches globally within seconds: after an update, a later read misses the invalidated entry and refills from storage. That avoids choosing only between very short expiration times and prolonged stale entries. It also creates a dependency on a functioning change pipeline. The post says Habitat's change-data-capture system processes millions of changes per second across thousands of containers, with consumers for cache invalidation, secondary indexes and movement. Its workers use leases, lower-priority feed reads, alternate-region readers and dead-letter queues to contain failures. These are reported internal mechanisms, not a freshness guarantee for every read.

OpenAI attributes a drop in global median read latency from roughly 120 milliseconds to roughly 10 milliseconds to a combination of nearby replication for critical data, in-region caching and a Rust rewrite of the Habitat service. The post does not isolate each change's contribution. It also says slow uncached requests can still cross regions. For another storage team, that distinction matters as much as the median: faster common reads do not remove placement and miss-path costs.

Habitat's [earlier engineering post](https://openai.com/index/scaling-storage-one-billion-users-part-one/) explains why OpenAI moved routing, authorization and request shaping from a Python client library into a service, and why it kept the data API narrow. The October 23 account adds the storage-side choices behind that service. OpenAI says its largest Cosmos DB account stores tens of petabytes and serves more than 20 million queries per second; those are company-reported operating figures, not measurements by BIG CHANGE. The account gives other storage teams a way to examine their own systems: locate the shared resource where interference occurs, keep a migration path for exceptional workloads, and measure the latency and operating cost of the controls. Habitat's scale and its joint work with Azure limit how directly another operator can copy the implementation.

## Sources & further reading

- [OpenAI's October 23 Habitat storage account](https://openai.com/index/scaling-storage-one-billion-users-part-two/) provides the tenancy sequence, reported incidents, controls, caching and CDC design, and company-reported results. It is an account from the operator, without an independent audit attached.
- [OpenAI's September 11 Habitat service account](https://openai.com/index/scaling-storage-one-billion-users-part-one/) explains the service boundary, narrow API and Rust transition. It provides context for the later storage account.
- [Microsoft's Cosmos DB partitioning guide](https://learn.microsoft.com/en-us/azure/cosmos-db/partitioning) explains logical and physical partitions and current general service limits. [Microsoft's rate-limiting guide](https://learn.microsoft.com/en-us/azure/cosmos-db/troubleshoot-request-rate-too-large) explains how hot partitions can produce 429 responses. Neither document certifies OpenAI's custom operating mode for other customers.

## Sources

- [Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)](https://openai.com/index/scaling-storage-one-billion-users-part-two/) — First-party Habitat storage account and operator-reported outcomes.
- [Rapidly scaling online storage to serve over 1 billion ChatGPT users](https://openai.com/index/scaling-storage-one-billion-users-part-one/) — Service/API and Rust context, not new October event.
- [Partitioning and horizontal scaling in Azure Cosmos DB](https://learn.microsoft.com/en-us/azure/cosmos-db/partitioning) — General partition behavior and limits, not certification of OpenAI configuration.
- [Diagnose and troubleshoot request rate too large exceptions](https://learn.microsoft.com/en-us/azure/cosmos-db/troubleshoot-request-rate-too-large) — General 429 and hot-partition behavior.