Storage needs a place in the facility
A Habitat response needs more than the processor running a model. Settings, application state and authentication data must arrive on time too. OpenAI’s new engineering account describes physical capacity limiting how close that data can be placed to users. Space allocated to storage in a region cannot simultaneously support additional serving compute. Where power and cooling are constrained, placement becomes more than a choice between software components: the operator is dividing the same local capacity between two kinds of work.[1]
The company says Habitat spans 40 geographic regions and holds more than 500 petabytes. Those figures do not imply equal data volumes or equal spare capacity in every region. OpenAI explicitly says some regions cannot accommodate their proportional share of user traffic as storage. Distant data therefore cannot be attributed solely to a software preference. Expanding local storage competes with placing more serving compute there. Geographic reach alone leaves the regional resource distribution unspecified.[1]
Copying every dataset everywhere
Habitat does not answer that pressure by replicating every dataset everywhere. Small, latency-sensitive datasets such as authentication metadata receive broad replication; nearby Valkey caches serve other frequently read objects. A cache narrows the need to move the entire backing store into the same region. Its copies still need to remain fresh. The Cosmos DB change feed invalidates the relevant local copy so the next read obtains a new value. Capacity planning therefore includes deciding which copies to refresh, rather than simply allocating more complete replicas.[1]
This arrangement does not replace local capacity with an unlimited software resource. A cache miss still reaches the backing store, and OpenAI says its slowest reads can travel to distant regions. Typical behavior and that slow path have separate consequences for waiting users. Better placement can accelerate the same software; better caching can avoid some journeys within the same placement. Calculating how much facility capacity either change releases requires the read mix, cache usage and local resource consumption. The disclosure does not provide facility-level energy measurements that would complete that calculation.[1]
Query capacity in exchange for flash
OpenAI’s next storage system moves the trade-off to another layer. Its in-development design combines RocksDB Cloud with Raft replication and uses disaggregated storage and physical replication for bulky data types. The stated exchange is lower flash requirements for lower peak queries per second. An exabyte-scale goal alone therefore does not describe service capacity. Holding a large volume and answering a large number of requests in a given time are different jobs. This system is still under development and cannot be added to the delivered capacity of the existing Cosmos DB service.[1]
Habitat’s infrastructure lesson is that storage and compute meet on the same local resources. Software design can change the outcome: widely replicating small data, caching frequent reads nearby and moving bulky data into a different layout distribute different loads. Another explanation also remains important: reliability and product access patterns, rather than power limits alone, drive some of those choices. OpenAI’s account shows these factors operating together. Understanding usable service capacity requires including the storage path beside the model; a count of purchased accelerators does not describe that path.[1]