MemOS × PolarDB All-in-One Memory Management Solution: Giving AI Unbroken Memory

This article introduces the MemOS and PolarDB all-in-one solution, unifying relational, vector, and graph data for scalable, long-term AI agent memory.

As AI moves from single-turn Q&A toward long-running tasks and continuous service, agents need to handle far more than a single request — they must manage ever-growing user preferences, factual context, historical interactions, and task state. Limited context windows and cross-session information loss are only surface-level symptoms. The deeper challenge is how to persistently write, retrieve, and elastically scale these memories on the cloud as user volume and workload grow.

In production environments, AI memory is not a static chat log. It must support high-concurrency access, massive data growth, multi-tenant isolation, fault recovery, and dynamic scaling — while also performing information extraction, structured storage, precise retrieval, continuous updates, and lifecycle governance. Only by integrating memory management with cloud-native data infrastructure can long-term memory evolve from a point solution into a scalable AI foundational capability.

PolarDB and MemTensor provide a layered, collaborative engineering path: PolarDB for PostgreSQL serves as a unified, stable memory data foundation for AI applications, while MemOS — a memory operating system designed for LLMs and agents — uses cloud and open-source deployment, a unified Memory API, memory models, and MemCube memory containers to continuously schedule and manage memory.

PolarDB for PostgreSQL handles the "stability" of memory; MemOS handles the "liveliness" of memory. Each takes responsibility for its respective layer — data infrastructure and memory system — forming a complete delivery chain from cloud-native storage through memory management to agent invocation.

1. Challenges in Building Agent Memory

Once deployed in production, a memory system typically needs to handle three categories of data simultaneously:

• Structured information. User IDs, timestamps, business tags, memory sources, and permission scopes require a relational database for precise filtering and consistency management.

• Semantic information. "Prefers muted tones" and "favors the Morandi palette" are phrased differently but semantically similar — requiring vector search for recall.

• Relational information. Associations among users, products, orders, and preferences — or the fact that one memory supersedes another — need a graph structure to express entity relationships and multi-hop paths.

Traditional approaches require separate deployments of relational, vector, and graph databases, with the application layer maintaining data synchronization, connection configuration, and error handling.

PolarDB for PostgreSQL unifies relational, vector, and graph capabilities within a single database system. On the vector side, an optimized PGVector extension performs semantic search; on the graph side, the PolarAGE graph engine handles entity relationships and graph queries; structured data continues to be managed by native PostgreSQL capabilities.

This means memory data no longer needs to be synchronized repeatedly across multiple database systems — developers can focus more effort on memory quality and business logic.

2. PolarDB All-in-One Memory Management System: Foundation Capabilities

2.1 Unified Memory Store: Scalar + Vector + Graph — Three Retrieval Modes in One Instance

PolarDB for PostgreSQL provides diverse data management and retrieval capabilities within a single database instance.

The optimized PGVector extension handles semantic search — a single SQL statement performs similarity computation and attribute filtering. The PolarAGE graph engine handles graph queries using native graph-database traversal algorithms, achieving tens-of-thousands QPS with sub-100ms response times at hundred-billion-node scale, supporting multi-hop traversal and causal-chain reasoning. PostgreSQL's native relational capabilities — full-text indexing, transactional consistency, backup and recovery — are available out of the box.

All three capabilities are served by a single, unified database system, eliminating the need to synchronize and maintain relational, vector, and graph data across separate systems. Combined with storage-compute separation, read-only node scaling, and elastic autoscaling, PolarDB for PostgreSQL can expand based on memory data volume and access load.

The two sides each take responsibility for their respective layers:

• MemOS, as the memory management layer for LLMs and agents, handles memory writing, extraction, organization, retrieval, updating, and lifecycle management, exposing capabilities to applications through the unified Memory API and MemCube memory containers;

• PolarDB for PostgreSQL handles memory data persistence, relational queries, vector search, and graph relationship processing, while providing transactional, access-control, backup/recovery, and elastic-scaling database capabilities.

Together, they form a complete chain from memory writing and persistent storage through composite retrieval to continuous updates.

MemOS Cloud already uses PolarDB to support memory data storage and querying. Under identical machine configuration, identical datasets, and identical load conditions, MemOS Cloud ran Search P99 latency benchmarks comparing PolarDB for PostgreSQL against a mainstream graph database.

Under the same configuration and dataset, Search P99 latency comparison (unit: ms, lower is better)

Across all load points from 10 to 40 QPS, PolarDB for PostgreSQL consistently delivers lower P99 latency than the comparison database:

• P99 performance improves 1.79–9.27×, with a median improvement of 2.71× and an average improvement of 3.96× across 5 load points;

• At 40 QPS, PolarDB for PostgreSQL achieves a P99 latency of 1,404 ms versus 13,020 ms for the comparison database — a 9.27× performance improvement and an 89.2% reduction in P99 latency.

2.2 PolarDB Model Operators: Supporting Memory Extraction, Vectorization, and Recall Ranking

Storage alone is not enough to build long-term memory. Conversation content must undergo information extraction and vectorization before writing; retrieval results require further ranking.

PolarDB provides three model operators:

• LLM operator: extracts long-term facts, user preferences, and entity triplets, and assists with fusion of new and existing memories;

• Embedding operator: converts memory content into vector representations for semantic search;

• Reranking operator: re-ranks recall results to reduce irrelevant content entering the LLM context.

The solution supports both in-database model operators and external model services such as Model Studio. Model calls can prioritize Model Studio, with in-database model operators serving as a fallback channel during high load, improving stability and service continuity under traffic fluctuations.

2.3 Graphical Configuration and Open Integration

The PolarDB console supports graphical management of model algorithms, database parameters, memory extraction strategies, and memory graphs.

Developers can integrate long-term memory into existing LLM and agent applications through the MemOS open-source SDK, Memory API, and sample projects. Platform administrators configure and govern the underlying capabilities; application developers integrate MemOS into specific business workflows.

3. MemOS × PolarDB Full Memory Chain: From Extraction and Storage to Recall and Governance

3.1 Extraction and Writing: Turning Conversations into Memory Nodes

Suppose a user mentions in a chat:

"I usually wear size M," "I like the Morandi palette," "I bought a pair of wide-leg pants last month."

MemOS organizes the information with long-term value into independent memory nodes — size preference, color preference, and purchase history.

Each node can contain metadata such as creation time, update time, owning user, tags, source, and vector representation. Nodes are linked by relationship edges, forming a traceable, queryable, and reason-able memory network.

In the memory-writing workflow orchestrated by MemOS, PolarDB's LLM operator performs fact and entity-relationship extraction, the embedding operator generates vector representations, and the resulting structured data, vector data, and graph relationships are written uniformly into PolarDB for PostgreSQL.

3.2 Recall: Vector, Graph Relationships, and Model Ranking in Concert

One month later, the same user asks: "Help me put together an outfit for a wedding." Memory recall proceeds through three stages:

• L1 vector screening: vector similarity computation, attribute filtering, and tag matching recall candidate memories related to "wedding outfit" — typical latency under 50 ms;

• L2 graph expansion: the PolarDB for PostgreSQL graph engine performs multi-hop queries, expanding from candidate nodes to related memories such as size, color preferences, and purchase history. With parallel execution and LRU multi-graph queue optimization, the core-path P95 response holds steady at the 10 ms level;

• L3 ranking and reasoning refinement: the reranking operator sorts candidate memories by relevance, while the LLM judges causal, conflicting, and conditional relationships among memories, filtering duplicates and irrelevant content.

The final memories passed to the LLM can be organized as: this user usually wears size M, prefers the Morandi palette, and bought a pair of wide-leg pants last month. The LLM then generates outfit recommendations that better match the user's preferences and history.

3.3 Governance: Dynamic Evolution of Memory

Memories are not immutable static data once written.

MemOS's Memory Scheduling mechanism orchestrates memory generation, invocation, updating, and lifecycle management. When new information conflicts with existing memory, it can be fused or updated according to application configuration and business policy. When a user proactively corrects information, the relevant memories can be modified through a feedback mechanism. Content that is no longer applicable can be deleted or archived.

The memory system therefore manages not a growing collection of static fragments, but a set of continuously updatable and governable long-term information.

3.4 MemCube: Multi-Tenant Isolation Supporting Tens of Millions of Users

In multi-business, multi-agent, and multi-user scenarios, the memories of different entities need clear ownership and controlled access scopes.

MemOS uses MemCube to manage different memory spaces, while PolarDB for PostgreSQL enforces data isolation through clusters, databases, schemas, tables, graphs, and user identities:

Level	PolarDB for PostgreSQL Mapping	Primary Role
Instance	PolarDB cluster	Physical resource boundary
Database	Database	Business line or project isolation
Schema	Schema	MemCube logical isolation
Data	Table / Graph	Stores memory nodes, vectors, and entity relationships

Within a single MemCube, PolarDB automatically partitions sub-graphs by UserID. At equivalent memory scale, recall efficiency improves by over 50%, supporting independent memory spaces for tens of millions of users.

For public memories such as product specifications, compliance clauses, and industry knowledge, MemOS can organize cross-project, cross-agent shared scopes, while PolarDB for PostgreSQL controls read/write boundaries through schemas, tables, views, and permission systems — enabling memory reuse while keeping data access under control.

4. Four Values of Deploying a Memory System in the Enterprise

Adopting an architecture where PolarDB for PostgreSQL and MemOS collaborate, enterprises can perform relational, vector, and graph retrieval on a single data foundation, reducing the cost of cross-system data synchronization, system integration, and operations.

• Integration efficiency. Developers need to integrate with only one system to obtain graph, vector, and relational retrieval simultaneously — integration cycles shrink from weeks to days.

• Cost control. What is stored are distilled memory nodes, not raw conversation transcripts, significantly reducing the number of tokens passed to the LLM. Combined with storage-compute separation and elastic scaling, infrastructure costs track actual usage — no advance capacity reservation needed.

• Reliability. MemCube-level space isolation, paired with database-level multi-tenant controls, backup auditing, and resource management, makes memories traceable, correctable, and deletable — SLAs carry the weight of contractual guarantees.

• Reduced headcount. Traditional approaches require dedicated staff for vector databases, graph databases, and memory extraction logic. In the new architecture, MemOS handles memory strategy and scheduling while PolarDB for PostgreSQL handles database operations and elastic scaling — engineering teams can focus on the business itself.

As systems move into multi-agent collaboration, continuous user-memory updates, skill and experience accumulation, and team knowledge sharing, what enterprises need to manage is no longer just memory writing and recall — it is the full lifecycle of memory across users, tasks, and agents.

Through the layered collaboration of MemOS and PolarDB for PostgreSQL, enterprises can keep the underlying data stable and reliable while allowing memory to update continuously, be invoked on demand, and scale with the business.

5. Quick Start

PolarDB × MemOS all-in-one memory management system on Alibaba Cloud is now live. MemOS is open-sourced.

• PolarDB console: full graphical configuration — memory engine, model services, and extraction strategies are all manageable through a visual interface;

• Minimal API: provides REST APIs and client SDKs with automatic memory extraction, fusion, and search;

• Ecosystem compatible: seamlessly integrated with Alibaba Cloud PolarDB Agent Express / AgentRun / AgentScope.

One PolarDB, one MemOS — providing AI applications with continuously available memory capabilities.

Community

MemOS × PolarDB All-in-One Memory Management Solution: Giving AI Unbroken Memory

1. Challenges in Building Agent Memory

2. PolarDB All-in-One Memory Management System: Foundation Capabilities

2.1 Unified Memory Store: Scalar + Vector + Graph — Three Retrieval Modes in One Instance

2.2 PolarDB Model Operators: Supporting Memory Extraction, Vectorization, and Recall Ranking

2.3 Graphical Configuration and Open Integration

3. MemOS × PolarDB Full Memory Chain: From Extraction and Storage to Recall and Governance

3.1 Extraction and Writing: Turning Conversations into Memory Nodes

3.2 Recall: Vector, Graph Relationships, and Model Ranking in Concert

3.3 Governance: Dynamic Evolution of Memory

3.4 MemCube: Multi-Tenant Isolation Supporting Tens of Millions of Users

4. Four Values of Deploying a Memory System in the Enterprise

5. Quick Start

Read previous post:

ApsaraDB

You may also like

Comments

ApsaraDB

Related Products

PolarDB for PostgreSQL

PolarDB for Xscale

PolarDB for MySQL

Database for FinTech Solution