What OpenAI actually published
Start with what Habitat is and who reads from it. OpenAI describes it as "the online storage platform we built so OpenAI products can quickly and reliably access needed information," and opens by naming the kinds of requests it serves: "Every OpenAI product depends on fast, reliable access to data, whether someone is logging in, checking their Codex settings, or starting a new conversation in ChatGPT. Each of those actions may require many separate data lookups before the product can respond."
The scale is stated plainly. Habitat "now handles more than 70 million requests every second, supporting products used by over 1 billion people each week, across almost 40 geographic regions," and "today, it's a complex distributed system that serves more than 500 petabytes of data."
Then comes the design decision that matters here, and OpenAI labels it as a decision rather than a limitation:
"Rather than allowing clients to construct arbitrary SQL queries that could result in large table scans or joins across many tables, Habitat exposes a simple NoSQL API. The lack of a powerful API is an explicit tradeoff in Habitat's design."
The reasoning is about predictability. "We aim to optimize for simple, predictable, constant-work requests. In our experience, these systems are substantially easier to scale and difficult to get wrong or misuse. Requests with unpredictable fanout are operationally dangerous: they complicate isolation, load balancing, and introduce latency cliffs that are hard to scale for both the service and its clients."
The data model follows from that. "Habitat exposes a NoSQL API modeled around client-defined object and edge types, inspired by TAO. Clients predefine objects and edges and how they relate to each other, but not the content of each type." OpenAI names its inspiration here, which is worth noticing — this is a well-travelled pattern, not something invented to cut corners.
And then the sentence the coverage skipped:
"We partition this graph so that each object and its corresponding edges are colocated in a storage-level partition, but we make no concerted database-level effort to colocate objects and the remote objects to which their edges point. The result is that the model easily partitions for horizontal scalability, but graph traversals are inefficient since any particular hop between objects may require fetching from two entirely different Azure Cosmos DB accounts stored in different regions."
Read that twice. An object and its direct edges sit together. The things those edges point at may sit on the other side of the world. OpenAI adds the boundary explicitly: "The resulting relationships resemble a graph, but Habitat itself does not support typical graph traversal queries outside of querying direct edges of a particular object."
Anything more complicated gets moved off the live path entirely: "For clients with more complex querying needs, we do provide an offline secondary view of Habitat exposed via Rockset." Changes stream out by change data capture, each team runs its own instance, and OpenAI is clear about why: "This design isolates our online storage from read-heavy analytical and search workloads."
What this does and doesn't change
It does not change anything about how ChatGPT behaves today. This is an engineering post about an infrastructure layer, not a product announcement, and OpenAI does not claim otherwise.
It also does not tell you where any particular feature's data lives. The post names ChatGPT, the API, Codex and internal services as clients of Habitat, and gives "starting a new conversation in ChatGPT" as an example request. It does not publish a schema for any product feature, and this article is not going to invent one.
What it does change is the quality of the guess you are allowed to make. Before this post, "why does my assistant recall individual facts but never seem to join them up" was speculation. Now there is a documented architectural reason why joining things up is the expensive operation at the storage layer, stated by the people who built it: single-object lookups with their direct edges are the cheap, constant-work case, and hops between objects are the case that may cross regions.
That is a different claim from "AI has bad memory," and it is a more useful one. The gap described in why long context isn't memory is usually framed as a model problem. Here is the same shape one layer down, in the storage tier, published by a vendor about its own system.
There is one more line worth carrying around, because it explains the whole design philosophy in eleven words: "When the average user request results in hundreds of database calls, the slowest database call is the one the user feels."
What people will take from this, and shouldn't
That OpenAI cut corners on storage. The post argues the opposite, at length, with reasons. Constraining the API is what makes a system at this scale predictable; OpenAI calls unbounded queries "operationally dangerous" and describes the cost imbalance directly: "it is cheap and easy to write SQL queries that are expensive and hard to run." A platform that refuses to let a product team write a query that takes out the database for a billion people is a platform doing its job.
That this is unique to OpenAI. It is not. OpenAI names TAO as the inspiration, which is a published design from a different company at a different scale, and the tradeoff it encodes — colocate an object with its edges, accept that remote hops are expensive — is the standard way to make a graph-shaped store partition horizontally. Anyone running a very large online datastore faces the same arithmetic.
That an offline copy solves it for you. Habitat's escape hatch is real and OpenAI is honest that it costs something: "This Rockset provisioning introduces extra friction to our clients," and each team is "responsible for scaling their own Rockset instance." That is an internal engineering option with an owner and a budget. It is not a user-facing feature, and nothing in the post suggests it is.
That the fix is a longer context window. Traversal cost and context length are separate problems. A bigger window changes how much can be shown to a model in one request; it does not change which lookups the storage layer treats as cheap. The retrieval version of this confusion is covered in why RAG isn't memory — finding a document is not the same as holding a conclusion.
The Fix: Keep the connections somewhere whose whole job is connections
If single-object lookups are the cheap case everywhere, then the durable move is to stop expecting the connection to be derived on demand and start writing it down as its own object.
Step 1: Separate the facts from the relationships between them
Go through what you actually rely on an assistant knowing and sort it into two piles.
The first pile is facts. "We bill in whole days." "The staging database is in Frankfurt." "Priya owns the payments integration." Each one stands alone and each one is a cheap thing for any system to fetch.
The second pile is relationships, and this is where the value hides. "We bill in whole days because the finance system rejects partial ones." "Staging is in Frankfurt because of the data residency clause in the 2025 contract." "Priya owns payments since the reorg, which is why the old runbook names someone else."
The second pile is the pile nobody writes down, because each half of it feels obvious at the time. It is also the pile that costs the most to reconstruct, and the one that any store optimized for constant-work single lookups will be worst at reassembling for you.
Step 2: Write the relationship as a sentence, not as two entries plus hope
A relationship written as one sentence is a single object. A relationship left implicit between two entries is a traversal — and you have just read a vendor's description of why traversals are the expensive path.
So write "Frankfurt, because of the 2025 residency clause" as one record, not as a location record and a contract record that something is expected to join for you. This is a small discipline with a large payoff, and it is the same instinct that makes a good commit message: the diff is the fact, the message is the relationship.
Where two records genuinely conflict, say so in the record itself rather than leaving the contradiction to be discovered. The failure mode when nobody does that is the subject of memory conflict detection.
Step 3: Give that layer one address every assistant can reach
A relationship you wrote into one product's memory is a relationship the next product cannot see. Keep the layer outside any single vendor's store so that moving tools, or using three at once, does not mean writing your relationships out again from scratch. The practical version of that problem is worked through in one memory across ChatGPT, Claude and Gemini.
Setting this up in MemoryLake
MemoryLake is built for the second pile. You write the decisions and the reasons behind them into it yourself, in your own words, and every assistant you connect reads the same set. Nothing is pulled out of any vendor's store; the layer holds what you put in it.
Step 1: Create an API key
Sign in, open your workspace settings, and generate an API key. This is the credential your assistants use to read the same layer, so create it once and keep it reachable from every tool you work in.
Step 2: Upload your first memories
Start with the relationships, not the facts. Take the five things you have explained twice this quarter and write each one as a single sentence that contains both the rule and the reason. Add the constraints that are expensive to rediscover and cheap to record.
Step 3: Connect your AI & agents
Connect ChatGPT and whatever else you use. The same reasoning arrives in each one, so a new conversation starts from what you already concluded instead of from scratch.
What this changes in practice
The first difference is that you stop being annoyed at the wrong thing. An assistant that remembers your city but not why you moved there is not being careless; it is being served by a layer that is very good at fetching one object and its direct edges. Knowing that turns a vague complaint into a specific habit.
The second is that your notes get shorter and more useful. A record that carries its own reason does not need a second record to make sense, which means it survives being read in isolation — exactly the access pattern these systems are optimized for.
The third shows up when things drift. Once reasons are written down, you can go back and check whether they still hold, which is a very different activity from re-reading a list of facts and wondering which are stale. That review habit is the subject of auditing what your AI remembers.
The fourth is continuity across sessions. The sinking feeling described in when ChatGPT loses context between sessions is mostly the cost of relationships that were never recorded anywhere, being re-derived by you, by hand, every time.
Best practices for working with a lookup-shaped memory
Write one record per decision, with the reason inside it. Two records that only make sense together are a traversal waiting to fail.
Prefer specific over structured. A plainly-worded sentence beats a clever schema you will not maintain. The systems doing the fetching are good at returning what you stored; they are not good at inferring what you meant to connect.
Record what changed, not just what is true. "We moved off the shared account in March" is more useful than "we have our own account," because it tells a reader which older material to distrust.
Re-read your oldest entries once a quarter. Facts rot quietly. Reasons rot loudly, and are easier to spot as wrong.
Keep the layer outside any one product. Vendors rearchitect. OpenAI just published a post describing a service that went from a library to a service to a rewrite, and promised a second part on the storage tier. Your reasoning should not have to care.
Don't treat an engineering post as a product spec. This one describes a platform and its tradeoffs. It does not document any feature's data model, and reading one into it would be guessing.
Conclusion
The Habitat post is a good piece of engineering writing, and the part worth keeping is not the rewrite. It is a vendor stating, without being asked, that its online storage is deliberately shaped for simple, predictable, constant-work lookups, that relationships between objects can land in different regions, and that anything requiring real traversal goes to an offline copy with its own owner.
Take that at face value and the conclusion for the rest of us is mundane and freeing. Stop waiting for the connection between two things you said to be rediscovered on demand. Write the connection down once, as its own plain sentence, somewhere every tool you use can read it. That turns the expensive operation into the cheap one — which is the same trick OpenAI's platform team used, one layer up.