The story is about the layer beneath the chat window

OpenAI has published an engineering account of Habitat, the internal online-storage platform it says supports ChatGPT, Codex, its API and other services. The authors say the system now serves more than 70 million requests each second, stores more than 500 petabytes of data and operates across almost 40 geographic regions for products used by more than one billion people each week.

Those figures come from OpenAI, and the post is not an independent performance audit. Still, the account is useful because it puts a less visible part of the AI race into view. A capable model is not much use if a user cannot sign in, recover a conversation, load a setting or fetch the information needed to complete a task.

At that point, storage is no longer a background utility. It becomes part of the product's reliability, privacy and response time. A small decision in a data layer can suddenly affect a large part of the service.

Why OpenAI moved from a library to a service

OpenAI says Habitat began in 2024 as a Python library that product services used to talk to storage. As more services adopted it, changes became harder to coordinate. A routing change, for example, had to be shipped and enabled across many separate clients before the team could be confident it was safe.

The company says it turned Habitat into a service to make those changes central. That can give an organisation one place to update routing, limit requests, collect audit logs and apply access rules. It can also make it easier to see which part of a request path is failing when a region, dependency or client starts behaving badly.

Centralisation has a trade-off. It reduces duplicated work and makes policies more consistent, but it also makes the shared layer important enough to need careful isolation and failure planning. A single point of control should not turn into a single point of failure.

The interesting constraint is what Habitat will not do

OpenAI says Habitat uses a deliberately constrained, NoSQL-style interface instead of allowing product teams to run arbitrary SQL queries. The stated aim is to make each request bounded and predictable. A flexible query can be useful, but it can also trigger a large scan or join at the worst possible moment on a heavily used path.

This is a design lesson that travels beyond databases. AI products increasingly connect agents to files, tools, search systems and company data. The instinct is often to make every capability available. In practice, a smaller interface with clear cost and permission boundaries can be easier to observe, protect and recover.

That does not mean every product should replace a relational database with a narrow service. It means the limits should be intentional. Teams need to know which operations are cheap, which are risky and which should never occur without a separate review step.

A Rust rewrite is not the whole result

OpenAI says two engineers, working with Codex and GPT-5.5, rewrote the service in Rust in the second quarter of 2026. It says the Rust version now handles 95% of production traffic, with six times the CPU efficiency and 15 times the memory efficiency of the Python version. Those are the company's own production figures.

It would be easy to read that as a simple language story. The more durable point is sequencing. OpenAI says it delayed a rewrite while it was dealing with immediate capacity and reliability problems, then used the later rewrite to make an already-bounded service cheaper to run. That is a familiar systems choice: fix the behaviour first, then optimise the implementation once the operating model is stable.

The article does not provide enough detail to judge the measurements across every workload, nor should other teams assume their own migration would produce similar gains. The value of the account is in the operational reasoning, not in treating a single percentage as a universal target.

What is confirmed, what OpenAI says, and what remains open

Confirmed: OpenAI published its Habitat engineering account on 11 September 2026. It describes an internal storage platform, a transition from a client library to a service, a constrained request interface, and a staged migration from Python to Rust.

OpenAI's claims: Habitat serves more than 70 million requests per second, supports products used by more than one billion people each week, holds more than 500 petabytes of data and delivers the stated efficiency improvements. These are company-reported metrics, not independently verified benchmarks.

Open questions: how Habitat behaves under different failure conditions, what its operating costs are, how often its controls prevent incidents in practice, how the platform's privacy and residency rules work across individual products, and which parts of this architecture are genuinely transferable to smaller organisations. The public account offers useful principles. It does not offer a complete blueprint.

Sources

  1. OpenAI Engineering — Rapidly scaling online storage to serve over 1 billion ChatGPT usersPrimary engineering account, 11 September 2026. Source for OpenAI's description of Habitat, reported scale figures, the service architecture, bounded API choice and Rust-migration measurements.
  2. Microsoft Learn — Azure Cosmos DB for NoSQL overviewOfficial platform documentation used only for general context on the database technology named in OpenAI's account; it does not verify OpenAI's internal metrics.
  3. OpenTelemetry — Observability primerAuthoritative technical context for the role of central tracing, metrics and logs in operating distributed services. It is not a source for OpenAI-specific claims.