Product teams were shipping features without pre-scaling their dedicated database containers, leaving responders to add capacity during launch-day incidents. The containers had helped OpenAI separate competing workloads, but each team now had to anticipate its own demand. OpenAI eventually returned to shared containers after adding controls intended to prevent one workload from overwhelming its neighbors.
Newsroom America’s account describes that reversal, drawing on OpenAI’s October 23, 2026 engineering post about Habitat, its online storage platform. OpenAI says Habitat stores more than 500 petabytes and serves products used by more than one billion users across 40 geographic regions.
For platform engineers, the distinction is between isolating workloads and assigning them dedicated capacity. OpenAI’s reported experience shows how reducing interference can also move operational risk onto product teams.
Dedicated Containers Moved the Problem to Launch Day
Habitat initially used a single default Azure Cosmos DB container per account. According to the report, that arrangement encountered logical partition-key collisions and noisy-neighbor problems, where one tenant’s activity disrupted unrelated workloads.
Moving critical use cases into dedicated containers improved isolation. It also gave each container its own capacity-planning burden. When teams shipped features without pre-scaling, responders had to add capacity during launch-day incidents. Dedicated infrastructure had reduced one source of unpredictability while introducing another: whether each product team had correctly anticipated demand.
Separating workloads does not remove the need to manage capacity. It changes where that responsibility sits and how many teams must get it right.
A dedicated container may be appropriate when workload separation matters more than pooled capacity. OpenAI’s account suggests that treating dedication as the default, however, can make successful launches depend on repeated coordination between product and infrastructure teams.
Returning to Shared Capacity Required Explicit Controls
Before moving back toward shared containers, OpenAI reports working with Azure on three changes that address different parts of the contention problem:
- Hot-key throttling targets concentrated demand around a particular key.
- Request priority allows differentiated treatment of requests rather than treating all work as equally important.
- Revised serverless scaling increases the capacity available to physical partitions. OpenAI says the improved mode lets each physical partition scale to 10,000 request units per second.
The last figure describes request-unit capacity, not 10,000 queries per second. More capacity does not make throttling or prioritization unnecessary.
Pooling and isolation can coexist when the platform actively controls contention. OpenAI credits these changes with allowing a return to a shared container while preserving workload isolation and reducing product teams’ upfront and ongoing capacity-planning work.
That remains a vendor-reported outcome. The available report does not specify throttling thresholds, priority policies, costs, or guarantees during overload. Sharing capacity reduces per-team provisioning work only if the platform accepts responsibility for deciding how competing workloads behave under pressure.
The Reported Read Speedup Came From Several Changes
OpenAI also reports reducing global median read latency from roughly 120 milliseconds to roughly 10 milliseconds, a twelvefold improvement. The account attributes that result to a combination of data placement, geographic replication, integrated caching using change data capture, and a Rust rewrite. It does not establish how much of the improvement came from each component.
The result therefore cannot be presented as a twelvefold Rust speedup or as proof that caching alone produced the gain. Change data capture, or CDC, supplies information about data changes; the available summary does not explain Habitat’s cache-invalidation mechanics or consistency guarantees.
Platform teams should examine the whole read path before choosing an optimization. OpenAI’s reported approach addressed both where data was served and the software serving it, but the aggregate latency figure cannot identify which intervention another system should prioritize.
All scale and performance figures here are OpenAI’s claims, not independent benchmark results.
Recovery Procedures Became Part of the Architecture
The operational account is as consequential as the container design. OpenAI says its largest Cosmos DB account stores tens of petabytes and serves more than 20 million queries per second.
Two outages in late 2024 exposed recovery problems: a regional power failure revealed failover times of several hours, and a connection stampede occurred during failback. OpenAI and Azure subsequently deepened their collaboration through shared dashboards, joint testing, and direct paging access.
Those incidents raise practical questions for engineers evaluating a managed database. How long does recovery actually take? What happens when clients reconnect? Which signals can both the customer and provider see during an incident?
Some improvements depended on changes developed with Azure, limiting how directly others can copy the design. Teams should separate controls they can implement themselves from capabilities that require provider cooperation, beyond configuration choices available to every customer.
Habitat’s tenancy reversal ultimately shifted ownership of capacity planning. Dedicated containers left product teams responsible for anticipating demand. Returning to shared infrastructure moved more of that responsibility back into the platform, where throttling, priority, scaling, and recovery procedures had to make the shared model workable.
