AI infrastructure and memory systems
Alibaba Cloud claims a 9.27x AI memory win against an unnamed rival
Alibaba Cloud's PolarDB and MemTensor's MemOS want to be the memory layer for long-running AI agents. Their pitch leans on a 9.27x P99 latency win over an unnamed graph database, and on folding relational, vector, and graph storage into one system.
Emmanuel Fabrice Omgbwa Yasse AI-assisted
2026-09-14 · 5 min read

MemOS Cloud ran the benchmark, and the disclosed conditions read like a properly controlled test: identical machine configuration, identical datasets, identical load. Across five load points between 10 and 40 queries per second, PolarDB for PostgreSQL posted a lower P99 latency than the comparison database every time. The reported gap runs from 1.79x to 9.27x, with a median of 2.71x and an average of 3.96x.
| Disclosed result | PolarDB for PostgreSQL | Unnamed graph database |
|---|---|---|
| P99 at 40 queries/sec | 1,404 ms | 13,020 ms |
| Gap at the top of the curve | 9.27x | |
| Across five load points, 10-40 queries/sec | 1.79x to 9.27x; median 2.71x, average 3.96x | |
Neither company names the rival, which matters: a 9.27x win at the top of the load curve says as much about the opponent as it does about PolarDB. A benchmark against an unidentified system cannot be reproduced outside the two companies, and nobody outside them can check whether the graph database was sized, tuned, or configured the way a production user would run it. Third-party verification is the usual answer, and it is the same argument behind Microsoft funding 18 university labs to red-team AI systems independently.
Why memory stopped being a chat log
Alibaba Cloud's ApsaraDB team and MemTensor frame context windows as a red herring. Limited windows and information lost between sessions are surface symptoms, they argue. The harder problem is writing, retrieving, and scaling memory on shared infrastructure as user volume grows, which turns a model feature into a distributed-systems exercise.
Agents moving from single-turn question answering to long-running tasks change what memory is for. A preference stated once has to survive months, dozens of sessions, and possibly several agents working for the same user. The source lists what that demands in production: high-concurrency access, multi-tenant isolation, fault recovery, dynamic scaling, and lifecycle governance that decides when a stored fact should be updated or deleted. Get that last part wrong and the cost is documented: stale facts stay retrievable and pollute the prompt, one recent preprint argues.
One database instead of three
A memory stack usually means three deployments. Structured data goes in a relational database: user IDs, timestamps, tags, permission scopes. Semantic data goes in a vector store: a stated preference for muted tones, say, or a Morandi palette. Entity relationships and multi-hop paths go in a graph store. Keeping the three in sync falls to the application layer.
PolarDB for PostgreSQL collapses them into one. An optimized PGVector extension handles semantic search, the PolarAGE graph engine handles entity relationships, native PostgreSQL covers structured data. Alibaba Cloud claims PolarAGE reaches tens of thousands of queries per second with sub-100 ms responses at hundred-billion-node scale, plus multi-hop traversal and causal-chain reasoning.
Collapsing the stores removes a category of synchronization work. It also means betting on one vendor's version of three different workloads. A team that needs a specialized vector index, or a graph engine built for a particular traversal pattern, gives up the option to slot in a dedicated system.
Inside the write path
Conversation content has to be processed before it becomes memory. PolarDB offers three model operators: an LLM operator that extracts long-term facts, preferences, and entity triplets; an embedding operator that converts content into vectors; and a reranking operator that reorders recall results so less irrelevant material reaches the model's context.
Model calls prioritize Model Studio, Alibaba Cloud's model service, with the in-database operators acting as a fallback under high load. That fallback is a stability measure, not a claim that the two paths perform identically. The source does not compare them.
Recall runs in three stages. L1 performs vector screening with attribute filtering and tag matching, at a stated latency typically under 50 ms. L2 expands through the graph from candidate nodes to related memories, holding a core-path P95 in the 10 ms range. L3 reranks candidates and has an LLM judge causal, conflicting, and conditional relationships, discarding duplicates and irrelevant content. That last step earns its keep: dead context left in the prompt is pure cost.
Tenancy and the cost arithmetic
Isolation maps onto database primitives. A PolarDB cluster is the physical boundary, a database separates business lines, a schema holds a MemCube, and tables or graphs store nodes, vectors, and edges. Inside a single MemCube, PolarDB partitions sub-graphs by UserID, which the source says improves recall efficiency by more than 50% at equivalent scale and supports separate memory spaces for tens of millions of users.
The cost argument stays qualitative. The companies say integration cycles shrink from weeks to days, that storing distilled memory nodes rather than raw transcripts cuts the tokens sent to the model, and that storage-compute separation lets infrastructure track actual usage instead of reserved capacity, the utilization question that still lacks an owner on the GPU side. No figure accompanies any of those three claims.
What the source leaves open
Several questions need answers before the numbers carry weight. The source attributes the benchmark to MemOS Cloud and offers no independent verification, so the figures remain vendor claims until a third party repeats them.
The comparison database's identity, its configuration, and the PolarDB version tested all go undisclosed. Without them, 9.27x is a claim rather than a measurement anyone can audit.
Then there is who stands to gain. This is an Alibaba Cloud page announcing that the PolarDB and MemOS memory management system is live and that MemOS is open-sourced, with a console, a REST API, and client SDKs. It reads as a product launch as much as a technical report, the same posture as the company's AI Gateway walkthrough. None of that makes the architecture wrong, and durable memory for agents that run for months is a real problem. It does mean the strongest numbers deserve an independent test before anyone rebuilds a memory stack around them.
- Source : Alibaba Cloud claims a 9.27x AI memory win against an unnamed rival — 2020-05-20
Get the tech essentials in 3 minutes every morning
One email, every weekday, with what actually matters in AI and tech.