Introduction

Large language models (LLMs) are reshaping how enterprises access and use data. Traditionally, business systems relied on predefined reports, APIs, and query conditions to retrieve information. Today, an increasing number of users prefer asking questions directly in natural language. As queries become more open-ended, retrieval systems are no longer limited to keyword matching or semantic similarity search.

Enterprise data is typically connected through complex and explicit relationships. A single transaction may involve customers, accounts, and devices; a contract may connect organizations, projects, and responsible parties; and a risk event may propagate through relationships among funds, personnel, and organizations. Many business questions can only be answered by connecting these relationships to reconstruct the complete business context. A system must not only retrieve relevant information, but also determine how that information is related, through which paths entities are connected, and what verifiable data supports the final conclusion.

As a result, graph retrieval has become an essential component of enterprise AI data processing pipelines. It organizes business entities and their relationships as nodes, edges, and paths, enabling relationships to be queried and computed directly. This provides the foundation for relationship analysis, multi-hop retrieval, path discovery, and explainable results.

01 From "Content Similarity" to "Relationship Explainability"

With the rapid advancement of AI, vector retrieval has become one of the primary approaches for connecting LLM applications with external knowledge. It excels at identifying semantically similar objects across massive collections of text, images, and other unstructured data. However, in real-world enterprise scenarios, semantic similarity is often only the first step.

A single business query may simultaneously involve business constraints, structured data relationships, keyword matching, semantic retrieval, and relationship tracing. For example, during risk investigation, the system must not only retrieve documents similar to a given risk description, but also determine whether the associated accounts, transactions, devices, and individuals are connected through multi-hop relationships. In knowledge question answering, the system must not only retrieve documents containing a particular concept, but also identify hierarchical relationships, dependencies, references, and causal links among concepts.

Vector retrieval only answers the question, "Which content is most similar?" Graph capabilities, on the other hand, organize entities and their relationships into queryable and computable data structures, making them better suited to answering "How are these entities connected?" Nodes, edges, labels, and paths explicitly represent relationships that are otherwise hidden in table joins, document narratives, and business rules, allowing retrieval results to be traced and verified along concrete business paths. On this foundation, the system can execute graph queries such as pattern matching, neighborhood expansion, variable-length traversal, shortest path search, cycle detection, and path counting.

For AI applications that require multi-hop evidence, relationship analysis, and explainable results, graph capabilities provide an implementation model that better aligns with the characteristics of enterprise data: relationships become queryable, paths become verifiable, and conclusions can always be traced back to supporting data. In recent years, engineering practices such as GraphRAG have further accelerated the adoption of relationship-aware retrieval. For cross-document, cross-entity, and global reasoning tasks, relying solely on text chunk similarity retrieval often fails to preserve complete relationship context. To support relationship retrieval in production environments, enterprises also require databases capable of reliable relationship storage, efficient graph traversal, continuous data updates, and comprehensive access control.

02 CittaBase: A Unified Database for AI Workloads

CittaBase is an all-in-one converged database developed by YMatrix for AI hybrid workloads. In AI-native business systems, data access typically spans an end-to-end processing pipeline: transactional read/write operations, structured data queries, knowledge retrieval, relationship traversal, and analytical processing all coexist within a single workflow. To address these requirements, CittaBase is built on a PostgreSQL-compatible transactional and data foundation, providing OLTP, OLAP, Cypher graph queries, BM25 full-text search, and vector retrieval capabilities within a single database instance.

This integrated capability enables CittaBase to serve as the data foundation for ontology repositories, enterprise operational systems, and RAG knowledge bases. Business transactions, knowledge retrieval, graph queries, and OLAP analytics can all be executed within the same database instance, reducing cross-system data synchronization, permission management, and result integration. CittaBase natively integrates graph retrieval and graph computation capabilities. Through a unified data access interface, it handles both structured and graph data while supporting graph operations including pattern matching, variable-length paths, multi-hop traversal, shortest path, all-shortest-path queries, relationship label combinations, multi-label retrieval, path counting, and cycle detection. Graph query results can also participate directly in subsequent SQL filtering, joins, and aggregations, allowing relationship paths and business attributes to be processed together within a single query.

To improve graph query performance, CittaBase incorporates targeted optimizations for multiple common query patterns. For bounded variable-length paths, path counting, fixed-endpoint queries, and selected shortest-path workloads, the optimizer applies plan rewriting, index-based access, and specialized execution paths to minimize unnecessary traversal and full path materialization. CittaBase also provides graph computation acceleration by pruning unreachable branches through reachability analysis and accelerating selected path computations and graph algorithms. In addition, enterprise graph data typically contains rich attributes and is frequently used together with relational tables, time-series data, documents, logs, and vector embeddings. CittaBase's vectorized execution engine significantly improves the throughput of data scanning, filtering, joins, aggregations, and complex analytical queries through batch processing and operator optimization, providing a high-performance execution foundation for graph attribute computation, candidate filtering, and downstream analytics.

03 From Point Lookup to Multi-Hop Traversal: An In-Depth Benchmark of the CittaBase Graph Engine

Graph query performance is highly dependent on query patterns, and no single scenario can adequately reflect the overall capability of a graph engine. To provide broader coverage of representative workloads, this benchmark adopts both the Category B (basic scenarios) and Category C (complex scenarios) workloads from GraphBench, comprising a total of 38 queries. The workload covers typical graph operations including primary-key point lookup, property filtering, neighborhood expansion, multi-hop traversal, shortest path, cycle detection, and path counting. The benchmark was executed in a fixed order. Each query was run three times, and the cold execution time of Neo4j and CittaBase was compared. By examining the total execution time, individual query results, and the performance across different query categories, we can observe the execution characteristics of the CittaBase graph engine under various workloads.

The detailed benchmark results are as follows:

Benchmark configuration: 20 queries from Category B (basic scenarios) and 18 queries from Category C (complex scenarios), for a total of 38 queries. The benchmark first executes base.sql, followed by complex.sql. The ratio is calculated as CittaBase Cold ÷ Neo4j Cold, where a lower value indicates shorter execution time for that benchmark run.

From the overall execution time, CittaBase completed the benchmark in 129.205 seconds, compared with 1023.328 seconds for Neo4j, representing approximately 13% of Neo4j's total runtime. This overall result is significantly influenced by C18. In the "Directed 7-hop Raw Path Counting" query, Neo4j required 872.679 seconds, whereas CittaBase completed the same query in 0.374 seconds. Excluding C18, the remaining 37 queries finished in 150.649 seconds and 128.831 seconds, respectively. The two systems are therefore within a similar performance range, with CittaBase remaining slightly faster under this workload.

Across different query types, CittaBase performs well on highly selective point lookups, neighborhood counting with fixed start or end vertices, time-range filtering, partial text filtering, shortest path queries, bounded-depth path enumeration, and several complex graph pattern queries. There is still room for further optimization in workloads such as full-graph node and edge counting, low-selectivity IN filtering, label aggregation, and layer-by-layer deduplication for 7-hop endpoint queries.

The 38-query benchmark covers a broad spectrum of graph workloads, ranging from primary-key lookups and local neighborhood expansion to complex path computation. The results demonstrate that the native graph engine in CittaBase already provides comprehensive query coverage. In particular, for deep path-counting workloads, matrix-based pruning and optimized fast-path counting significantly reduce unnecessary graph traversal and path materialization, resulting in substantial performance improvements.

04 Conclusion

Natural language is becoming the new interface for data access, and enterprise queries increasingly involve structured constraints, textual content, and entity relationships simultaneously. Graph capabilities organize relationships scattered across table joins, business rules, and document descriptions into an explicit graph structure, enabling systems to directly query related entities, trace business paths, and provide verifiable data evidence for query results.

To address these requirements, CittaBase integrates OLTP, OLAP, native graph queries, graph computation acceleration, BM25 full-text search, vector retrieval, and a vectorized execution engine within a single database instance. Enterprises can complete candidate retrieval, relationship expansion, and result analysis under a unified data and access control framework, reducing cross-system data synchronization and result integration while enabling more efficient relationship retrieval and hybrid analytics.