In our previous two articles, “Millions of Tokens, Yet Not a Single Experience Retained: The Memory Challenge for Agents” and “From Data to Memory: How Cognee Builds Long-Term Cognition for AI Agents”, we explored why Agents need long-term memory. We also examined Cognee’s processing workflow to understand how documents, conversations, and execution experiences can be organized into knowledge that can be retrieved and connected.
As Agents continue working, these memories accumulate and evolve. New content is added, existing knowledge is supplemented and revised, and information is repeatedly retrieved, connected, and used in subsequent tasks. Databases must therefore manage this knowledge continuously: keeping the text, vectors, and relationships associated with the same piece of content linked together; controlling retrieval and computation costs as the knowledge base grows; and enabling existing memories to be combined with current data when tasks involve real business operations.
The integration of CittaBase and Cognee is designed to address these needs. Cognee organizes how memories are formed and used, while CittaBase provides unified data management, semantic retrieval, and relationship computation capabilities. Together, they support Agents in continuously accumulating and using knowledge.
In Cognee, a piece of knowledge can have several representations: text preserves the original content, vectors provide an entry point for semantic retrieval, graph relationships connect entities, and source and status records indicate ownership and provenance. Each type of data serves a distinct purpose, yet they depend on one another. After semantic retrieval identifies candidates, the system must locate the corresponding knowledge objects. After following relationships to find an entity, it must be possible to trace that entity back to the original text. When a source is deleted, the system must also distinguish between content that should be removed and objects still used by other sources. Adding documents, revising knowledge, and clearing outdated content can all require multiple types of data to be maintained together. When objects are distributed across different systems, applications must also handle cross-system synchronization, identifier mapping, and result verification.
CittaBase brings relational, vector, and graph capabilities into a single database system, providing a unified management foundation for these interconnected data types.
Relational data manages the identity, source, and status of knowledge objects; the vector engine retrieves semantic candidates; and the graph engine organizes and queries relationships between entities. Using object identifiers, applications can establish links among these data types, find relevant content, trace its provenance, and restrict usage based on source and status—reducing the work required to transfer and reconcile data across systems.
Using memory involves several access patterns: relational queries filter and join data according to explicit conditions, vector search finds semantically relevant content, and graph queries traverse connections between entities. As the knowledge base grows, these operations must return suitable results while controlling data-access and intermediate-computation costs. CittaBase provides query interfaces for all three patterns and optimizes processing at the indexing and execution layers.
PostgreSQL is becoming an important technology foundation for AI applications. Its mature relational processing capabilities, open extension ecosystem, and growing collection of AI development tools allow enterprises to continue using their existing data and technical investments to meet new application needs. For developers, familiar SQL, drivers, and management tools also mean lower integration and maintenance costs.
CittaBase retains PostgreSQL’s relational processing capabilities and ecosystem advantages while enhancing graph computation and vector search. Developers can use SQL within the same database to filter, join, and aggregate business data, retrieve relevant knowledge through vector and graph queries, and maintain task state and data integrity through transactions, constraints, and concurrency control. These capabilities jointly support Agent task execution, from business data management to AI knowledge retrieval.
In Cognee’s memory system, relational data records the source, version, and ownership of knowledge. When a task requires an understanding of current business conditions, applications can also use business identifiers to associate retrieved knowledge with relevant records. This allows Agents to draw on past experience while staying informed about the current state of the business.
In Cognee, processing a document can produce multiple knowledge objects, including text chunks, summaries, and entities. Many of these objects have their own vector representations. As documents, conversations, and execution experiences accumulate, an Agent may need to retrieve only a few relevant pieces of information for each task, while the database’s candidate set continues to expand. High-dimensional vectors contain many numerical values. Reading this data, calculating distances, and selecting the nearest results all consume storage bandwidth and computing resources. Vector search must therefore consider not only whether relevant content can be found, but also how much data a retrieval operation needs to access and how many candidates warrant precise computation.
CittaBase’s vector engine combines search-space selection, quantized filtering, and candidate reranking to perform retrieval in stages within the index. A vector index can use clustering to divide vectors into different regions, grouping similar vectors together as much as possible. During a query, the system selects relevant regions based on the query vector, narrowing the search space. Within those regions, it then uses more compact quantized representations to estimate distances and filter candidates that may qualify for the result set, reducing data access and computational overhead at this stage.
After the initial filtering, the system recalculates distances for promising candidates using full-precision vectors to determine their final ranking. Lightweight representations are used for broad filtering, while precise computation is focused on the remaining candidates. This avoids spending the same amount of computational effort on large volumes of irrelevant content. The vector search engine performs this reranking without requiring an additional call to a large language model.
These operations take place inside the database, so applications can continue using familiar vector-distance queries. Taking Cognee’s entity vector table, Entity_name, as an example, an application passes the query vector as a parameter and retrieves the five nearest entities:
SELECT id
FROM "Entity_name"
ORDER BY vector <=> $1::vector
LIMIT 5;Here, $1 is the query vector supplied by the application, and <=> represents cosine distance. Once the appropriate index has been created, the database can choose a vector-index execution path for this query. The application does not need to implement candidate filtering or vector reranking itself.
For Agents that run continuously, teams can adjust indexing and query strategies in CittaBase as the knowledge base grows and retrieval requirements change. This lets them choose an appropriate balance between retrieval quality and resource consumption while continuing to use their existing data structures and query interfaces.
Cognee connects scattered entities and information through a knowledge graph, providing Agents with related context. Using the graph introduced earlier, we start from mars3 bucket and follow outgoing edges to find entities reachable within one or two hops. This illustrates how the same relationship query can be expressed using two different backends.
In a native PostgreSQL graph backend, nodes and edges are stored in relational tables. Queries must use recursive CTEs to expand the graph layer by layer, explicitly tracking traversal depth and visited edges, and then filter and deduplicate the returned entities. CittaBase has a built-in graph engine that allows developers to describe the starting point, relationship direction, and path range directly in Cypher, leaving matching and traversal to the database.
The *1..2 in the graph specifies a traversal depth of one to two hops, and the arrows indicate traversal direction. Given the same graph data and path rules, both queries return 16 distinct entities, with matching object identifiers, names, and types verified. Developers can express queries directly in terms of relationships between entities, reducing the effort required to write and maintain recursive logic themselves.
As the number of relationships increases and paths become deeper, graph queries must also control the computational cost of intermediate results. CittaBase optimizes execution for multi-hop traversal. Where applicable, pruning reduces exploration of irrelevant paths, and unnecessary result construction can be avoided for tasks such as path counting. These capabilities operate alongside relational data processing in the same database, allowing applications to explore connections through the knowledge graph and then query further using source information, status, and business records.
After finding relevant objects through knowledge relationships, an Agent often needs to continue its reasoning with business data. It may need to determine whether past experience applies to the current situation, how often similar issues have occurred recently, or where they are concentrated. These operations extend knowledge retrieval into business computation and increase the volume of data the database must process.
Reading the status of a particular object usually involves only a small number of records. Analyzing changes over a period of time, however, may require scanning large volumes of data and then performing joins, aggregations, and sorting. CittaBase supports these analytical workloads through MARS3’s row-and-column hybrid storage and vectorized execution, addressing both storage and computation. MARS3 supports both routine read/write operations and analytical access. Its columnar organization reads only the required fields, reducing unnecessary data access. Vectorized execution processes data in batches rather than one row at a time, reducing per-row overhead and improving the efficiency of filtering, joins, and aggregation.
Business data continues to change, so analytical results must also be updated. Domino’s in-database streaming uses SQL to define processing logic such as filtering, joins, and aggregation, then incrementally updates downstream results when source data is inserted, modified, or deleted. For frequently queried metrics, applications can read the continuously maintained results directly, reducing repeated scans and computations. Because data processing takes place inside the database, there is also less need to deploy a separate stream-processing system or maintain cross-system processing pipelines.
Whether past experience can be retrieved, scattered knowledge can be connected through relationships, or historical conclusions can be reassessed in light of current data all depends on database support. Cognee organizes and retrieves memories, while CittaBase provides the data management, retrieval, and computation capabilities behind them.
Built on the PostgreSQL ecosystem, CittaBase combines relational processing, vector search, and graph computation. It also supports business analytics and continuous data processing through hybrid row-and-column storage, vectorized execution, and in-database streaming. Unified data management and targeted execution optimizations allow knowledge and business data to be organized, queried, and used on a common foundation.
From organizing and retrieving memories to using knowledge and business data together, CittaBase is building a full-stack, multi-model data foundation for AI applications.
Thank you for reading. YMatrix looks forward to working alongside like-minded people like you.
AI Era Database Infrastructure: Exploring Vectorized Execution in PostgreSQL
YMatrix for Smart Factories: Two Practical Data Platform Architectures (Time-Series + Analytics)
In-depth Analysis (Part 1) — In the AI Era, Databases Are Entering the “Unified Storage Era”
SERES × YMatrix: 3-Hour Migration of 2.13TB, 50% Faster Multi-Scenario Queries