As the Web3 ecosystem continues to expand, blockchain-based transactions have introduced a new paradigm of decentralized finance (DeFi) characterized by anonymity, intricate interaction paths, and a lack of centralized oversight. While this innovation offers unparalleled freedom and flexibility, it also creates significant challenges for risk management and compliance. **Traditional tools like rule engines, relational databases, and statistical analysis struggle to keep pace with the dynamic and the hidden nature of Web3 threats. Enter graph databases—a technology uniquely suited to model and analyze the complex relationships inherent in blockchain networks.**

In this article, we’ll explore why graph databases are becoming indispensable for Web3 risk management, how they address the shortcomings of traditional solutions, and their transformative impact on combating fraud, money laundering, and other illicit activities.

# The Challenges of Web3 Risk Management
## Anonymity and Lack of Context
In Web3, user identities are represented by blockchain addresses, which do not require real-name registration. This anonymity, combined with privacy-enhancing protocols and privacy coins, makes it nearly impossible to trace the origins of transactions or identify malicious actors. For example, attackers often exploit these features to launder money through multi-layered transfers or obfuscate transaction paths using time delays and decoy addresses. Traditional risk management systems, which rely on static rules and predefined thresholds, are ill-equipped to handle such sophisticated evasion tactics.

## Limitations of Rule Engines
Traditional rule-based systems operate on simple heuristics, such as flagging an address after a certain number of consecutive transactions or identifying high-value transfers as suspicious. While effective against predictable patterns, these rules falter when faced with the adaptive strategies of Web3 attackers. For instance, a money-laundering operation might split large sums into smaller amounts distributed across multiple addresses, making it difficult for static rules to detect the underlying scheme. Without the ability to understand the broader context of transactions, rule engines are rendered ineffective.

## Isolated Data Analysis
Statistical methods used in traditional risk management focus on individual metrics, such as transaction frequency or average transfer amounts. However, these approaches fail to capture the interconnected nature of Web3 transactions. Many fraudulent activities, such as Sybil attacks or airdrop farming, involve coordinated actions across multiple addresses controlled by a single entity. Analyzing each address in isolation misses the bigger picture, leaving organizations vulnerable to "group-based" attacks.

## Performance and Real-Time Constraints
The sheer scale and complexity of blockchain data pose additional challenges. Traditional relational databases rely on complex joins and queries to map relationships between entities, leading to slow performance and high resource consumption. In contrast, Web3 demands real-time risk detection and mitigation, which legacy systems cannot deliver.

# How Graph Databases Handle Web3 Risk Challenges
## Native Representation of Complex Relationships
At its core, Web3 operates as a vast network of interconnected entities—addresses, transactions, smart contracts, and protocols. Unlike relational databases, which require multiple tables and joins to represent these connections, graph databases model this data natively. Addresses become nodes, while transactions and interactions become edges, creating a semantic-rich and intuitive representation of the blockchain ecosystem. This structure simplifies modeling and enables lightning-fast queries, even across billions of nodes and edges.

For example, tracking a fund flow from a high-risk address involves traversing multiple layers of transactions. A graph database can perform this task in milliseconds, identifying all downstream addresses within 10 hops of the original source. This capability is crucial for real-time risk assessment and response.

## Pattern Recognition and Structural Analysis
Web3 fraud often exhibits distinct structural characteristics, such as circular transactions where funds loop back to their origin, star-shaped aggregations (multiple addresses funneling funds to a central account), or shared-source clusters (multiple users linked to the same IP). Graph databases excel at detecting these patterns through subgraph matching techniques, allowing systems to identify suspicious behaviors with remarkable accuracy.

By integrating with risk decision platforms, graph databases enable real-time alerts and dynamic analysis. As soon as an abnormal transaction or connection to a known blacklist node is detected, the system can trigger immediate warnings, far outpacing traditional batch-processing methods.

## Advanced Graph Algorithms for Fraud Detection
Graph databases come equipped with powerful algorithms that uncover hidden risks in large-scale networks. Take Community Detection Algorithms and Connected Components Analysis for instance. Techniques like Louvain clustering group highly interconnected addresses into potential fraud clusters. These clusters may represent orchestrated attacks, such as airdrop abuse or coordinated money laundering. Connected Components Analysis is often leveraged by Identifying isolated subgraphs to help detect rogue groups operating independently from the broader network. Such structures are often indicative of automated scripts or bot-controlled addresses.

These advanced graph algorithms allow graph databases to go beyond simple anomaly detection, providing deep insights into the structural vulnerabilities of Web3 ecosystems.

# The Future of Web3 Risk Management
As Web3 continues to reshape the financial landscape, the need for robust risk management solutions has never been greater. Graph databases offer a transformative approach to addressing the unique challenges posed by decentralized, anonymous, and complex blockchain environments. By enabling precise, real-time analysis of transaction networks, they empower organizations to stay ahead of evolving threats while ensuring regulatory compliance.

**For businesses operating in the Web3 space, adopting [graph database](https://www.nebula-graph.io/) technology is no longer optional—it’s essential.** Whether you’re a cryptocurrency exchange, a DeFi protocol, or a blockchain analytics firm, leveraging graph databases will help you unlock the full potential of your data and build a safer, more resilient Web3 ecosystem.


In the rapidly evolving world of Web3, where blockchain transactions are decentralized, anonymous, and complex, graph databases are emerging as the critical solution to tackle fraud, money laundering, and other risks with precision and speed.

Why Graph Models Outperform Traditional Tools in Web3 Risk Management

In the age of AI, competitive advantage hinges on how deeply organizations can understand their data. **With the release of NebulaGraph Enterprise v5.1, we're introducing native vector processing capabilities that address a critical demand in today’s AI and large language model development: hybrid queries combining graph structures and vector semantics.**

This enhancement significantly expands NebulaGraph Enterprise’s ability to handle unstructured data such as text, audio, and video—unlocking richer insights across domains like financial risk control and knowledge graph construction. The result is a more agile and intelligent way for enterprises to extract value from their data, backed by enterprise-grade reliability through distributed architecture improvements and cross-region disaster recovery.

# Native Vector Support Uncovers Hidden Connections  
In AI-driven applications, the gap between structured relationships and unstructured semantics often limits the depth of insight. With native vector support, NebulaGraph Enterprise v5.1 bridges this divide by integrating vector search into the graph model.

**Vectors are essentially becoming part of a node’s “attribute DNA.” This allows users to perform relationship traversal and vector similarity searches within the same query.** For example, entity relationships in an equity ownership chain can be analyzed alongside semantic intent extracted from contract texts, while sensor networks in industrial equipment graphs can be automatically linked to anomaly patterns in log messages. This unified approach opens up entirely new dimensions for data exploration and interpretation.

![image](https://www-cdn.nebula-graph.io/blogs/product_architecture_5.1.jpg)
*NebulaGraph Enterprise v5.1 Architecture*

# Up to 5.5x Performance Boost
On the performance front, NebulaGraph Enterprise v5.1 delivers major advancements. **Benchmarks based on the LDBC SF100 dataset show a 550% increase in query throughput compared to the previous generation.** Complex deep-link queries see dramatic improvements—for instance, a 10-hop equity penetration query now runs in just 1.5 seconds, down from 8.2 seconds. This effectively creates direct paths through intricate relationship networks, enabling faster, more responsive decision-making.

Additionally, full backup efficiency for ultra-large-scale graphs has been drastically improved. **A trillion-node dataset that previously required 72 hours can now be backed up in just 9 hours—greatly enhancing business continuity and operational resilience.**

# Enterprise-Grade Resilience and Security
To meet the stringent availability requirements of industries like finance and government, NebulaGraph Enterprise v5.1 introduces a robust disaster recovery and security framework.

The new cross-Zone active-active architecture leverages a multi-site, three-center design along with Raft consensus to ensure seamless traffic failover and zero data loss in case of local outages. For long-distance disaster recovery, manual switching and zone-aware scheduling minimize network latency and resource consumption—ensuring rapid service restoration even under extreme conditions.

On the security front, v5.1 offers end-to-end protection across access control, data transmission, and storage. Fine-grained permission management follows the principle of least privilege, allowing administrators to restrict access to specific subgraphs or attributes. Full TLS/mTLS encryption ensures secure data-in-transit, safeguarding sensitive information at every stage.

# Future-Ready Intelligence Infrastructure
With NebulaGraph Enterprise v5.1, the fusion of graph and vector technologies reaches a new level of maturity. By uniting structured relationships with unstructured semantics, and combining it with breakthroughs in performance, security, and enterprise readiness, we’re empowering businesses across finance, manufacturing, healthcare, and beyond to build smarter, more responsive data infrastructures.

Ready to explore what the future of data intelligence looks like? [Contact us](https://www.nebula-graph.io/contact) to unlock the power of integrated graph and vector analytics.


With the release of NebulaGraph Enterprise v5.1, we're introducing native vector processing capabilities that address a critical demand in today’s AI and large language model development: hybrid queries combining graph structures and vector semantics.

NebulaGraph Enterprise v5.1 Embeds Vector Search for AI-Grade Data Fusion

# About EasyCash
EasyCash is a leading Indonesian fintech platform that leverages AI, big data risk assessment models, and core credit systems to provide accessible, secure, and inclusive financial services for SMEs and individuals. As of July 2022, the platform has reached 11 million registered users and disbursed over $1 billion in loans to 2 million borrowers.

# Business Challenges: Bottlenecks in Real-Time  Fraud Detection
However, with rapid growth came complex operational challenges—especially when it came to fraud detection. **Traditional relational databases struggled under the pressure of high-concurrency scenarios, often taking more than three seconds to return critical query results.** This delay led to a 30% miss rate on high-risk applications, leaving gaps in the company’s defense against organized fraud rings. **Static rule-based systems were also ineffective in detecting evolving tactics such as “one device, multiple accounts” or “one ID, multiple users,” where bad actors distributed fraudulent behavior to avoid detection.**

Compounding these issues was the company’s offline data architecture, which required more than eight hours to generate graph-based features needed for machine learning models. This bottleneck severely limited the responsiveness of their AI-driven risk engine, making it difficult to deploy up-to-date fraud detection strategies in real time.

# Solution: A Graph-Powered Risk Control Upgrade
To overcome these limitations, EasyCash turned to NebulaGraph Enterprise , a distributed graph database trusted by leading enterprises for mission-critical workloads. By leveraging the power of graph technology, EasyCash built a real-time risk detection system capable of analyzing vast, interconnected datasets with low latency and high throughput.

**At the core of the new system is a real-time risk graph containing over 1 billion nodes and 19 billion edges , dynamically updated with information about users, devices, phone numbers, emergency contacts, and binding relationships.** Powered by NebulaGraph Enterprise , this infrastructure enables two key fraud detection workflows.					

## Credit Assessment: 8ms Decisions at Scale
In the credit assessment phase, when a user submits a loan application, the risk engine performs real-time queries into the user's 1–3 degree network. For example, it checks whether the applicant’s emergency contact appears on a blacklist or if the same device has been associated with more than five IDs. Based on dynamic graph rules, the system generates a risk score in under 8 milliseconds per query, even under 300+ concurrent requests.

## Disbursement: Unmasking Hidden Networks
During the disbursement phase, EasyCash combines real-time graph features generated by NebulaGraph Enterprise —such as community risk density and fund flow paths—with machine learning models to detect complex fraud patterns. Using subgraph embedding techniques, the system uncovered a spider-web-like network involving 20 devices and 100 phone numbers, enabling precise interception of coordinated loan fraud attempts.

![image](https://www-cdn.nebula-graph.io/blogs/risk_control_platform.jpg)

# Why NebulaGraph Enterprise?
EasyCash chose NebulaGraph Enterprise for its proven ability to deliver high-performance, scalable, and reliable graph computing in production environments. Some key reasons behind EasyCash’s adoption include:

- **Distributed Architecture**: Built from the ground up for horizontal scaling, NebulaGraph Enterprise allows organizations to grow their datasets seamlessly without compromising performance. Its multi-node architecture ensures high availability and fault tolerance.

- **High Concurrency & Low Latency**: The system excels in high-throughput environments where thousands of queries must be processed simultaneously with minimal response time. This makes it ideal for real-time applications such as fraud detection engines.

- **Seamless Integration**: NebulaGraph offers flexible connectors for Spark, Flink, Kafka, and other big data technologies, making it easy to integrate with existing data pipelines and machine learning workflows.

These features enabled EasyCash to build a unified, intelligent risk control platform that scales with business growth while maintaining responsiveness and accuracy.

# Customer Value Delivered: Enhanced Fraud Detection and Operational Efficiency
As a result of this transformation, EasyCash saw measurable improvements across its operations. **Risk screening was moved earlier in the process, allowing the company to intercept 60% of high-risk applications during the credit assessment stage, reducing manual review workload by 70%.** Despite increasing the overall fraud interception rate by 240%, EasyCash achieved a 15% increase in user approval rates, demonstrating that strong security does not have to come at the cost of user experience.

With NebulaGraph Enterprise, EasyCash has built a robust, intelligent, and scalable risk control system—one that supports sustainable business growth while protecting users from increasingly sophisticated threats. Its automated approval system reduces traditional financing barriers by 40%, with an average loan processing time under 8 minutes, directly addressing Indonesia’s demand for efficient, transparent, and inclusive financial services.


This article dives into how EasyCash built a robust, intelligent, and scalable risk control system based on NebulaGraph Enterprise.

Real-Time Risk Detection at High Concurrency: How EasyCash Secures Growth with NebulaGraph Enterprise


> The author,Xin Hao, is a risk management  engineer at Airwallex and a maintainer of nebula-go. This article will introduce the applications of NebulaGraph at Airwallex.


#  Airwallex  

As a renowned global payment and financial platform, Airwallex provides one-stop cross-border payment solutions for enterprises of all sizes and stages of development.  

When shopping, gaming, subscribing to video platforms, or using paid software, you encounter various cross-border payment scenarios, including card payments or recurring subscriptions. These payment services are facilitated by game companies, e-commerce platforms, or merchants on other platforms.  Behind the scenes, Airwallex supports these enterprises by offering services such as payment acceptance, fund collection, and treasury management.  

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/Airwallex/1744943392895.jpg)

In cross-border scenarios, our clients are highly diverse.  On one hand, some clients are gaming companies providing in-game purchase products to users across different countries. Others are e-commerce platforms, including self-operated platforms and those like Taobao that serve multiple merchants.  On the other hand, our clients extend beyond the platforms themselves to include the merchants on these platforms. These merchants are legally independent entities, necessitating clear and precise identification.  


#  Application Scenarios of NebulaGraph  

We categorize NebulaGraph’s use application scenarios into four main areas:  

## Know Your Customer (KYC)  

It is well known that cross-border operations involve unique legal frameworks across jurisdictions. Commercial entities are the fundamental legal units, and we must classify and link these entities to ensure compliance with local regulations and business scopes.  

1. **IPersonal Information Association:** 
    - Authorized Representatives and Legal Persons of Commercial Entities: Their information must be linked to the entities to identify who actually controls and manages them.  
    - Operators of Registered Accounts: When individuals register and use our services, their email addresses, phone numbers, and other details are associated with their accounts, aiding identity verification and risk assessment when needed.  

2. **Device Information Association:** Device information association involves client devices, such as IP addresses and device IDs. This helps detect abnormal login behaviors, such as access from unusual geographic locations or devices.  

3. **Network Information Association:** Network information association covers clients’ online behaviors and transaction patterns. By analyzing network activities, we identify anomalous transaction patterns or potential risks—for instance, frequent large transactions or multiple transactions from different locations within a short timeframe.  

4. **Facial Recognition Association:** Facial recognition association leverages biometric technology to verify client identities.  

## Real-Time Transaction Correlation  

During real-time transactions, NebulaGraph is used to correlate transaction data.  

Device information association here differs from the KYC context. Here, device data originates from payment components integrated with Airwallex SDK. When users initiate payments via Airwallex SDK (mobile, web, etc.), we track device IDs, models, IP addresses, and other details.  

Payment and collection information association ensures transaction legitimacy and security. In e-commerce, billing information association is key to detecting abnormal purchase patterns and potential fraud, while logistics information association tracks product flows and ensures transaction integrity.  

## Model Feature Extraction  

For model feature extraction, raw data is preprocessed into features used for model training and real-time inference. During online graph service operations, periodic data snapshots are generated for training, while real-time interfaces compute features for inference.  

## Visualization and Interaction  

Our current implementation is simplified, primarily serving internal operations teams. We provide web interfaces for operators to input queries and interact with the system on demand.  

# Why NebulaGraph?  

## Graph Relationships and KYC  

Know Your Customer (KYC) is a critical risk control process to verify client identities and assess risks throughout their lifecycle. It ensures compliance and prevents fraud by validating identities, understanding financial behaviors, and detecting anomalies.  

Graph databases naturally model KYC relationships. By representing clients, accounts, devices, and transactions as nodes and edges, NebulaGraph visualizes complex connections—such as legal-entity associations or account-device links. This structured approach enhances data readability and enables efficient anomaly detection, such as identifying fraudulent chains through relationship analysis.  

Thus, adopting NebulaGraph was the best choice.  

## Challenges  

Before NebulaGraph, we used a simple Python-based graph service for basic applications. During our early stages with smaller datasets, we extracted nodes and edges from offline data warehouses and stored them in memory.  


This architecture worked initially but faced issues as data grew:  
1. **Instability:** Periodic data updates every 10 minutes caused frequent failures.  
2. **Memory Inefficiency:** Increasing data volumes strained memory resources.  
3. **Limited Query Flexibility:** Basic query languages hindered complex scenario support, reducing development efficiency.  

These challenges drove us to adopt NebulaGraph.  

## NebulaGraph Selection  

During evaluation, we benchmarked multiple graph databases. Despite some competitors’ comparable performance, NebulaGraph excelled in functional completeness and enterprise adoption, making it the optimal choice.  

# System Architecture Design  

## Customer Relationship System Architecture  

### Graph Construction for Customer Relationships  


We built a heterogeneous graph, offering three key advantages:  
1. **Adaptability:** Supports diverse query scenarios, such as analyzing account linkages or transaction patterns.  
2. **Scalability:** New relationship types can be added effortlessly as business evolves.  
3. **TTL-Based Data Cleanup:** Automatic expiration of outdated data ensures relevance.  

Over time, we enriched the graph with additional relationship types, allowing granular analysis via edge attributes and weights.  

### System Architecture  


1. **Data Ingestion**  
   - Batch Processing (Full Data): Hourly bulk updates.  
   - Real-Time Data Supplement (Incremental): APIs fill missing data during new client registration.  

2. **Schema-First Approach**  
   - **Schema as Code:** Field definitions and changes are codified, ensuring consistency.  
   - **Unified Schema:** Shared across services and ETL pipelines for efficiency.  

Key applications of the graph service include:  
1. Model feature extraction for real-time client and transaction analysis.  
2. A rules engine for risk control decisions based on graph features.  
3. Internal business services leveraging graph data.  
4. Visualization interfaces for operational queries.  

## Business Complexities  

1. **Dynamic and Complex Schemas**  
   - Multiple node types (10+ variants) with diverse attributes.  
   - Frequent schema adjustments (monthly).  

2. **Data Logic Changes and Cleansing**  
   - Requires flexible workflows to accommodate rapid business shifts.  

### Mitigation Strategies  

1. **Centralized Schema Definition**  
   - Define schemas in code, auto-generating changes upon commits.  
   - Field modifications (renaming, additions) are code-driven and automated.  

2. **TTL + Full Data Writes**  
   - Combines TTL for data freshness with full writes for completeness.  

We adopted a declarative schema management approach. Field modifications trigger auto-generated schema change statements.  


For query result mapping, we use a "declare-and-get" method. Structs defined in code with annotations automatically map query results to fields, eliminating manual handling. SDKs or APIs dynamically fetch the latest schema, ensuring stability despite changes.  

## Transaction Correlation System Architecture  


This system prioritizes real-time performance, adopting a "compute-separate, merge-on-read" architecture.  

- **Historical Data (>4 hours):** Pre-processed via hourly batch jobs into subgraphs stored in the graph database.  
- **Real-Time Data (≤4 hours):** Ingested via Kafka, split, and written to the graph database after processing.  

# Future Outlook  

- **Resource Isolation:** Single Nebula clusters lack isolation, causing interference between applications during query peaks.  
- **TP/AP Compatibility:** A single cluster struggles to balance transactional processing (TP) and analytical processing (AP).  
- **Algorithm Ecosystem:** Limited openness and ecosystem for graph algorithms.  

Future improvements aim to enhance resource isolation, enrich graph algorithm support, and foster community collaboration to advance the technology and ecosystem.  

This article details Airwallex's use of NebulaGraph in cross-border payment scenarios. It covers application areas like KYC, real-time transaction correlation, model feature extraction, and visualization. 

How Airwallex Leverages NebulaGraph for Cross-Border Payment Solutions

Imagine a world where your data isn’t trapped in silos but connected like constellations, revealing hidden patterns that drive smarter decisions. Welcome to graph computing —the secret sauce powering today’s most innovative applications, from fraud detection to personalized recommendations. Let’s explore this transformative technology and how organizations are using it to turn complexity into competitive advantage.

# Decoding Graph Computing vs. Graph Databases
While often used interchangeably, these terms represent distinct concepts. Graph computing is the process of analyzing relationships to solve complex problems, like finding the quickest delivery route or detecting fraud rings. It’s the "brain" that applies graph theory to uncover insights.

Graph databases , on the other hand, are the "memory" that stores data as nodes (people, products) and edges (connections like "purchased" or "viewed"). They’re optimized to retrieve and manage these relationships efficiently. For example, a graph database might store billions of social media interactions, while graph computing algorithms analyze those connections to recommend new friends.

Think of it like cooking: the database holds the ingredients, and graph computing is the recipe that turns them into a meal.

# Why Graph Computing Matters Now More Than Ever
Traditional databases struggle with connected data. Relational systems require costly JOIN operations for relationship queries, while NoSQL solutions lack native support for multi-hop traversals. Graph computing solves this by:

- Speed : Analyzing millions of relationships in milliseconds.
- Flexibility : Adapting to evolving connections, like social networks or supply chains.
- Scalability : Handling billions of nodes and edges without slowdowns.

This capability is critical in modern applications. For example, Netflix uses graph computing to analyze viewing habits and suggest content that keeps users engaged. PayPal maps transaction patterns to stop fraud rings in real time.

# How Graph Databases Enable Graph Computing
Graph databases are the foundation for efficient graph computing. Leading solutions offer unique strengths:

[NebulaGraph](https://www.nebula-graph.io/) excels in real-time transaction processing at massive scale. It handles 10 billion+ edges natively, making it ideal for applications like ride-sharing route optimization or real-time fraud detection. Its SQL-like query language (nGQL) simplifies adoption, while open-source flexibility reduces vendor lock-in.

[Neo4j](https://neo4j.com/) focuses on deep analytical workloads, with a rich library of graph algorithms for tasks like community detection. However, its performance declines with datasets exceeding 1 billion nodes.

[TigerGraph](https://www.tigergraph.com/) targets enterprise-scale pattern matching, offering 35+ built-in algorithms and strong integration with machine learning tools. Its GSQL language appeals to SQL-proficient teams but requires more resource-intensive infrastructure.

[Amazon Neptune](https://aws.amazon.com/neptune/) simplifies cloud deployments for AWS-centric teams but lacks the hybrid flexibility of self-hosted solutions like NebulaGraph.

# Final Thoughts: From Complexity to Clarity
Graph computing isn’t about replacing your current systems—it’s about connecting them in ways that create exponential value. Whether you’re building a fintech startup or optimizing a manufacturing empire, the right solution turns data into discoveries.

Ready to Begin?
- Explore [NebulaGraph’s playground](https://explorer.nebula-graph.io/login) for hands-on learning
- Dive into the [Graph Database Community](https://join.slack.com/t/nebulagraph/shared_invite/zt-33nxrfan4-N_nhHDKOY1~C5YpHrJ3AiA) for peer insights
- Test your use case with the 14-day free trial offered by [NebulaGraph Cloud](https://www.nebula-graph.io/cloud-2025)


Let’s explore this transformative technology and how organizations are using it to turn complexity into competitive advantage.

Scaling Connections: How Graph Computing Solves Modern Data Complexity

Over the past few weeks, the Model Context Protocol (MCP) has sparked widespread discussion and attention within the technical community. Inspired by this momentum, I have contributed to several related open-source projects, including [implementing McpToolSpec for the official LlamaIndex repository](https://github.com/run-llama/llama_index/pull/17795) and collaborating with Xuanwo and FrostMing to develop [a Model Context Protocol Server for Apache OpenDAL™](https://github.com/Xuanwo/mcp-server-opendal).

As the only protocol currently offering a significant ecosystem advantage, MCP presents an exciting opportunity. In this context, [we have implemented a simple NebulaGraph MCP Server based on NebulaGraph 3.x](https://github.com/PsiACE/nebulagraph-mcp-server). This marks the first foundational component in the NebulaGraph X MCP ecosystem, opening up new avenues for exploring the potential of combining AI with graph databases. 

# What is Model Context Protocol (MCP)?

MCP, introduced by the Anthropic team, is an open protocol designed to provide AI systems with a unified and efficient way to access diverse data resources. By adopting a client-server architecture, MCP standardizes data access, addressing the fragmentation issues that traditional AI systems face when interacting with various data sources.

Key Features of MCP:

* **Standardized Communication**: MCP enables AI assistants to seamlessly access a wide range of data sources, including local data, remote services, and enterprise tools.
* **Openness and Ecosystem Advantage**: The MCP community already boasts nearly 1,000 MCP Server implementations, spanning search engines, weather services, databases, and more, facilitating rapid tool integration.
* **Flexible Architecture**: By defining clear interaction protocols between clients and servers, MCP empowers developers to build scalable and reusable systems.

While challenges around security and reliability remain, these issues are expected to be addressed as the protocol evolves and matures with improved development practices.


# Features of NebulaGraph MCP Server

Given my recent focus on Graph RAG and Agentic Workflow, leveraging large language models (LLMs) and intelligent agents to uncover insights from graph data has become a critical area of exploration. To facilitate this, I quickly developed the [NebulaGraph MCP Server](https://github.com/PsiACE/nebulagraph-mcp-server), enabling NebulaGraph 3.x to integrate into the MCP ecosystem as a tool for LLMs like Claude and GPT to invoke and utilize.

Built on FastMCP , the NebulaGraph MCP Server adheres to the core specifications of MCP, providing a lightweight and efficient connection service for graph databases. By exposing NebulaGraph's capabilities through standardized tool interfaces, this server allows LLMs to effortlessly interact with NebulaGraph data for basic graph exploration tasks.

### Multiple Transmission Modes:

* Supports both stdio and SSE (Server-Sent Events) transmission modes, catering to diverse development and deployment scenarios.

### Basic Graph Exploration Capabilities:

* Graph Space Listing: Enables models to query available graph spaces.
* Schema Querying: Supports querying schema definitions for specified graph spaces.
* Query Execution: Facilitates executing NebulaGraph queries via the MCP Server.

### Built-in Operator Templates:

* Includes templates for common operations like pathfinding and neighbor discovery, allowing LLMs to quickly retrieve preliminary insights from graph data.

To demonstrate its functionality, I built a simple example using McpToolSpec from LlamaIndex and ReActAgent. Below is a screenshot showcasing its capabilities:

![image](https://www-cdn.nebula-graph.io/blogs/3799122350000_llamaindex_mcptoolspec.png) 

# Conclusion
The NebulaGraph MCP Server represents an initial step in contributing to the MCP ecosystem, aiming to bridge the gap between language models and graph databases. As the protocol matures and its ecosystem expands, we hope it can play a vital role in real-world applications. If you're interested in this direction, we invite you to explore, experiment, and collaborate with us!

Together, let’s unlock the full potential of AI-powered graph databases!

The NebulaGraph MCP Server based on NebulaGraph 3.x is now open source. This marks the first foundational component in the NebulaGraph X MCP ecosystem, opening up new avenues for exploring the potential of combining AI with graph databases. 

Announcing the Open-Source Release of NebulaGraph MCP Server: Exploring the Infinite Possibilities of AI + Graph Databases

Storaged, the core storage component of NebulaGraph, is responsible for ensuring durability, availability, and scalability. It plays a critical role in handling reads and writes efficiently. This article explores the architecture of Storaged from the perspective of its underlying storage engine, RocksDB [1], and shares insights from real production use cases on diagnosing and resolving performance bottlenecks. 

One notable production example is Snapchat, which uses NebulaGraph to enhance its friend recommendation system at scale. (Read more [here](https://www.nebula-graph.io/posts/snapchat_enhances_friend_recommendations_with_nebulagraph).)

# How is data read and written in NebulaGraph

In NebulaGraph, both vertices and edges are stored as key-value pairs using RocksDB as the storage engine. In version 3.x, we use RocksDB 3.7.3. The data is partitioned and replicated, with each partition replica backed by a separate RocksDB instance.

![image](https://www-cdn.nebula-graph.io/blogs/storage.png)

To distribute data across multiple storage nodes, we use hash function:
- **Vertices** are partitioned based on their vertex ID.
- **Edges** are partitioned based on the source vertex ID.

This design ensures that a vertex and all its outgoing edges reside in the same partition, improving query performance. However, **super nodes** (e.g., highly connected entities such as celebrities or popular websites) can cause load imbalances. Hashing helps distribute these nodes more evenly across Storaged instances.

# Consistency and Replication via Raft

To maintain consistency between replicas, NebulaGraph employs the **Raft consensus algorithm** [2], which elects a **Leader** among the replicas. The Leader handles most read and write requests, while **Followers** serve as backups. If a Leader fails due to network issues or maintenance, a new Leader is elected.

The data write and replication process follows these steps:

1. The Leader writes data to the **Write-Ahead Log (WAL)**.
2. The write is replicated to all Followers, who also write to their own WAL.
3. Followers asynchronously persist the data to RocksDB and acknowledge the Leader.
4. Once the Leader receives acknowledgments from all Followers, it commits the write to RocksDB.

The diagram below illustrates this process.
![image](https://www-cdn.nebula-graph.io/blogs/storage_process.png)

# High Availability with Zones

For environments requiring high availability, we recommend distributing partition replicas across different zones. A zone refers to a distinct logical or physical grouping of infrastructure. In cloud environments, zones typically correspond to availability zones (AZs) [3] - geographically separate data centers within a region. These zones are close enough to support low-latency connections but far enough apart to minimize the risk of simultaneous failures due to localized disruptions (e.g., power outages or extreme weather). In this setup:

* Writes are always handled by the Leader, regardless of zone placement.
* Reads can be optimized with **zone affinity**, where queries prioritize a Storaged instance within the same zone as the compute node (Graphd) handling the query. 
* With zone affinity enabled, both Leaders and Followers can serve read requests, improving efficiency and reducing cross-zone data transfer costs. (E.g., In AWS, intra-zone data transfer is free.)

# Diagnosing High Storaged Latency: Common Causes and Solutions

In production environments, high P90 query latency and increased query failures often signal performance issues. While some problems originate from Graphd (our compute nodes) or Metad (our meta service nodes), when the root cause lies in Storaged, it always manifests as high storage latency. This section covers the most common causes of high storage latency and how to mitigate them.

## 1. Low Resource Utilization

If Storaged latency is high, but CPU usage, disk I/O, and disk throughput remain low, the software may not be fully utilizing available hardware resources. A key area to check is thread allocation for the Thrift server and RocksDB. 

Storaged relies on three main thread pools:
- Thrift IO thread pool – Handles incoming connections in an event loop. 
- Thrift worker thread pool – Handles service requests, including writes.
- Read handler thread pool – Manages disk reads via RocksDB.

The Thrift IO threads process the connections very fast and rarely cause latency issues. If latency persists, focus on the worker and read handler pools. In production, setting these pools to match the number of CPU cores on the machine or pod running Storaged typically yields optimal performance.

## 2. High CPU usage

If high CPU usage is observed across all Storaged instances, the root cause likely falls into one of the following categories.

### (1) CPU Spikes During Data Ingestion

If high CPU usage occurs primarily during data ingestion, the most likely cause is RocksDB compaction [4]. Compaction is an essential process that merges and reorganizes data in RocksDB’s Log-Structured Merge Tree (LSM tree) to optimize read performance. However, it can be resource-intensive.

To mitigate excessive CPU usage during compaction, consider the following optimizations:

* **Reduce compaction concurrency:**
    * Lower `max_subcompactions` and `max_background_jobs` to slow down compaction and distribute CPU load more efficiently.
* **Optimize custom compaction filtering**:
    * In NebulaGraph, expired data is garbage-collected using a **custom compaction filter** [5] when TTL is enabled [6]. This filter scans affected vertices and edges during compaction and verifies whether their TTL has expired. This additional check incurs CPU overhead.
    * The config `min_level_for_custom_filter` determines at which LSM level the custom compaction filter starts processing data.
    * A lower value of `min_level_for_custom_filter` will scan more levels of data and thus increase CPU load.
    * A higher value of `min_level_for_custom_filter` postpones TTL filtering to later stages, which reduces CPU usage but increases the temporary retention of expired data.

Since an excessively high value of `min_level_for_custom_filter` can result in bloated storage and potential availability issues, careful fine-tuning is necessary. The goal is to determine an optimal value that balances CPU efficiency with the retention of expired data. We will explore the impact of accumulated expired data later in this article.

### (2) Persistent High CPU Usage, Regardless of Writes

If high CPU usage persists even when there are no active writes, the cause is likely related to RocksDB read operations or thread contention within Storaged. To diagnose the issue more precisely, we recommend running `perf top` on a high-CPU Storaged instance.

* On physical or virtual machines, running `perf top` is straightforward.
* On Kubernetes deployments, additional privilege changes are required. Our Nebula Operator [7] includes the necessary configurations and can enable `perf top` with a single setting.

If `perf top` shows excessive thread context switching and preemption occurring within Thrift’s internal queues, this indicates over-threading - too many active threads competing for CPU resources. Reducing the number of worker and read handler threads can improve CPU efficiency.

## 3. High Disk I/O Utilization

If IOPS or I/O throughput reaches the disk's limits, query latency can degrade significantly. Identifying the underlying cause is crucial for maintaining performance.

### (1) High I/O During Data Ingestion

If excessive disk I/O occurs only during data ingestion, the likely causes are:
* High data ingestion speed
* High compaction concurrency

To alleviate this, consider:
* Reducing ingestion speed or adjusting the batch size
* Lowering the values of `max_subcompactions` and `max_background_jobs` to limit compaction concurrency

### (2) Constantly High I/O with Storage Errors

If disk I/O remains persistently high and approaches the disk's limit, and error logs such as `RPC failure in StorageClient` with `timeout` or `loadshedding` appear in Graphd, this likely indicates excessive amount of expired data..

In this case, Storaged is scanning the disk excessively to filter out expired data, which significantly increases I/O load. To verify this, check the statistics by running:

```
SUBMIT JOB STATS;
SHOW STATS;
```
If the amount of stale data is twice the normal level or higher, trigger a full compaction to clean up expired data:

```
SUBMIT JOB COMPACT;
```
# Conclusion

Storaged is a critical component of NebulaGraph, and its performance directly impacts query latency and system stability. This article provided insights into how data is stored, partitioned, replicated, and accessed in Storaged, along with best practices for diagnosing and resolving high storage latency.

#Reference

[1] Rocksdb. https://github.com/facebook/rocksdb 

[2] Raft. Ongaro, Diego, and John Ousterhout. "In search of an understandable consensus algorithm." 2014 USENIX annual technical conference (USENIX ATC 14). 2014.

[3] Availability Zone. https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview?tabs=azure-cli 

[4] Rocksdb Compaction. https://github.com/facebook/rocksdb/wiki/Compaction 

[5] Compaction Filter. https://github.com/facebook/rocksdb/wiki/Compaction-Filter 

[6] TTL in NebulaGraph. https://docs.nebula-graph.io/3.8.0/3.ngql-guide/8.clauses-and-options/ttl-options/

[7] Nebula Operator. https://github.com/vesoft-inc/nebula-operator 





This article explores the architecture of Storaged from the perspective of its underlying storage engine, RocksDB, and shares insights from real production use cases on diagnosing and resolving performance bottlenecks.

When NebulaGraph Slows Down: Diagnosing Storage-Related Performance Issues

Imagine asking ChatGPT, “How did the 2023 global chip shortage impact Tesla’s suppliers in Shenzhen through three degrees of separation?” Despite its eloquence, the LLM would likely falter—not because it lacks data, but because it lacks a way to map hidden, dynamic relationships. This is where graph databases like NebulaGraph become essential for the next generation of AI and LLMs.

As AI shifts from statistical pattern recognition to knowledge-driven reasoning, traditional databases (SQL, NoSQL) hit a wall. Their rigid tables and documents can’t model the interconnectedness of real-world data—supply chains, fraud networks, or molecular interactions. This blog explores how graph technology is rewriting the rules of intelligent systems.

# LLM Hallucinations: When “Confidently Wrong” Becomes Dangerous
LLMs hallucinate because they infer answers from patterns, not facts. Without grounding in verified knowledge, they risk generating plausible but dangerous outputs. Hallucinations aren’t just errors—they’re liabilities because they lack access to verified, structured knowledge. A medical chatbot might invent a drug interaction that doesn’t exist, risking patient safety.

# The Limitations of Traditional Databases
One of the biggest limitations of traditional databases is that they treat data points as isolated entities. Relational databases force data into tables, losing nuanced connections. For example, mapping a 10-layer corporate ownership structure requires 50+ JOINs in SQL, slowing queries to minutes. Vector databases retrieve semantically similar data but miss contextual relationships.

AI often struggles with the isolated data because so much of its power comes from understanding relationships. Graph databases, by contrast, are designed to store and manage data as interconnected entities, allowing AI to make sense of the links between seemingly disparate elements.

# Knowledge Graphs for Intelligent AI Systems
Graph databases are the backbone of such knowledge graphs, providing a powerful means of organizing and traversing complex webs of information. They allow AI systems to dynamically explore and connect various pieces of data, enhancing both the depth and the accuracy of the answers provided. Knowledge graphs are already being used in domains such as finance, healthcare, and education, where the complexity of the data requires more than a surface-level understanding.

Consider a fraud detection system for a major bank. Instead of treating each transaction as an isolated data point, a graph-powered AI can look at an entire network of transactions—cross-referencing user relationships, transaction frequency, locations, and any outliers that indicate something suspicious. It’s this networked understanding that enables real-time decision-making, stopping fraud as it happens rather than analyzing it after the damage is done.

# Graph RAG: Minimize Hallucinations of Traditional RAG
Graph RAG (Retrieval-Augmented Generation) is an advanced evolution of traditional RAG that integrates knowledge graphs into the retrieval process, significantly enhancing contextual understanding and multi-hop reasoning capabilities. Graph RAG addresses hallucinations of traditional RAG by leveraging the structured relationships in knowledge graphs, enabling more precise and contextually rich information retrieval. This structured approach minimizes hallucinations by grounding responses in factual, interconnected data, leading to more accurate and reliable answers.

# Two Major Methods to Implement Graph RAG

- **Build Your Graph RAG with NebulaGraph**: This method requires some coding work and solid AI knowledge. By leveraging NebulaGraph’s powerful graph database capabilities, you can construct a knowledge graph that integrates with your existing data sources. The approach of [Implementing Graph RAG with NebulaGraph](https://www.nebula-graph.io/posts/implement_graph_rag_with_nebulagraph) allows for customization and fine-tuning of the graph structure and retrieval algorithms, providing a robust solution for complex enterprise applications. It involves steps such as data ingestion, graph construction, and integration with large language models (LLMs) to enable sophisticated query handling and response generation.

- **Choose NebulaGraph RAG**: For those without coding experience, [NebulaGraph RAG](https://www.nebula-graph.io/posts/announcing_nebulagraph_RAG) offers an intelligent app-building platform that simplifies the process. This platform abstracts away the technical complexities, allowing users to build and deploy graph-powered AI applications with minimal effort. It provides a user-friendly interface for creating knowledge graphs, configuring retrieval parameters, and generating responses, making it accessible to a wider range of users within the organization.

# Build Tomorrow’s AI with NebulaGraph Today
The next AI breakthrough won’t come from bigger LLMs—it’ll come from smarter data infrastructure. NebulaGraph bridges the gap between LLMs’ linguistic brilliance and the structured intelligence of real-world knowledge. In the race to AGI, graph databases aren’t optional—they’re the bedrock. As OpenAI’s CTO once mused, “The future of AI isn’t just neural networks; it’s neural networks married to knowledge.”

Discover how graph databases like NebulaGraph are powering the future of AI and LLMs by enabling complex reasoning, reducing hallucinations, and unlocking scalable knowledge-driven applications.

Why Graph Databases Like NebulaGraph Are Essential for the Next Generation of AI and LLMs

**Author Introduction**

Hong Hailan specializes in leveraging large language models (LLMs) to automate the extraction of knowledge from unstructured medical records, construct knowledge graphs in traditional Chinese medicine, and uncover the experiences of renowned TCM practitioners.


# Background


Building knowledge graphs presents dual challenges: improving the efficiency of knowledge extraction and reducing human labor costs. To effectively address these issues, this paper builds on the schema layer and explores methods for automated knowledge extraction. The following sections detail the process of constructing a knowledge graph for the treatment of rhinitis by Master Gan Zuwang, a renowned traditional Chinese medicine practitioner.
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/%E9%BC%BB%E7%82%8E%E7%9F%A5%E8%AF%86%E5%9B%BE%E8%B0%B1/1.png)
The data for this study comes from clinical records of rhinitis patients, with a total of 1,081 detailed records selected for analysis. These valuable records contain various basic patient information, such as name, workplace, gender, age, diagnosis time, disease type, symptom details, diagnostic results, observations of tongue and pulse, treatment records, prescription content, and medication guidance.






# Knowledge Graph Construction Process Diagram





## Step 1: Prepare Sample Data

Utilize the 1,081 preprocessed medical records as sample data.


## Step 2: Define Extraction Targets

Based on the ontology-defined schema layer, establish extraction targets like diseases, related diseases, symptoms, examinations, tongue appearance, pulse appearance, and compatibility. Define extraction rules for each target type.




## Step 3: Automated Knowledge Extraction



Create a prompt template based on the defined extraction targets, using a "demonstration case + relationship list" format to guide large language models in automatically extracting medical record data and generating triples.



**The following is a specific Prompt example:**

Imagine you are a large language model designed to extract relationships in Traditional Chinese Medicine. Your task is to extract the relationships between symptoms and related diseases for rhinitis patients. Here's an example medical case:

"Rhinitis has been severe for three days, the condition naturally flares up, with excessive nasal discharge, difficulty blowing the nose. Headache. Nasal congestion. Nasal mucosal edema, with secretions. Thin white tongue coating, floating and tight pulse. Prescription: mulberry leaf 6g, peppermint 6g, platycodon root 6g, calamus 6g, spatholobus stem 10g, schizonepeta 6g, angelica dahurica 6g, xanthium fruit 10g, fagopyrum 10g, vitex 10g."

The output format is:[(“rhinitis”, “symptom”, “excessive nasal discharge”), (‘rhinitis’, ‘symptom’, ‘difficulty blowing the nose’), (‘rhinitis’, ‘symptom’, ‘headache’), (‘rhinitis’, ‘symptom’, ‘nasal congestion’), (‘rhinitis’, ‘examination’, ‘nasal mucosal edema’), (‘rhinitis’, ‘examination’, ‘secretions’), (‘rhinitis’, ‘tongue appearance’, ‘thin white tongue coating’), (‘rhinitis’, ‘pulse appearance’, ‘floating and tight pulse’), (‘rhinitis’, ‘combination’, ‘calamus 6g’), (‘rhinitis’, ‘combination’, ‘spatholobus stem 10g’), (‘rhinitis’, ‘combination’, ‘schizonepeta 6g’), (‘rhinitis’, ‘combination’, ‘angelica dahurica 6g’), (‘rhinitis’, ‘combination’, ‘xanthium fruit 10g’), (‘rhinitis’, ‘combination’, ‘fagopyrum 10g’), (‘rhinitis’, ‘combination’, ‘vitex 10g’)]. Follow this format to extract the following medical case in triplet format. The given sentence is: ‘***’. Given the relationship list: [‘symptom’, ‘related disease’, ‘combination’, ‘tongue appearance’, ‘examination’, ‘pulse appearance’], provide the relationships in the list. If they do not exist, output: none.


## Step 4: Clean the Extracted Results

Use regular expressions to clean the automatically generated triplet data by removing errors, redundancies, irrelevant, and incomplete triplets. This process ensures the accuracy and reliability of the data.


## Step 5: Store the Triplets

Store the final extracted triplet data in the NebulaGraph database.

This paper directly extracts diseases and Chinese herbs into corresponding triplets to ensure the reliability of the knowledge extraction process using large language models. During the writing process, these triplets are further decomposed to ensure the rationality of the knowledge graph. Additionally, the entities and attributes of Chinese herbs are jointly extracted during the knowledge extraction. For example, the dosage of Fagopyrum 10g in a rhinitis patient’s prescription is extracted as ('rhinitis', 'combination', 'fagopyrum 10g').

Before storing the triplets, this paper uses regular expressions to extract the entities and their corresponding attributes. For instance, ('rhinitis', 'combination', 'fagopyrum 10g') is decomposed into ('rhinitis', 'combination', 'Fagopyrum') and ('fagopyrum', 'dosage', '10g'), as demonstrated in the constructed knowledge graph.




# Using NebulaGraph to build a knowledge graph




**Why NebulaGraph**？NebulaGraph is a high-performance and user-friendly graph database that offers researchers a new way to explore and analyze data thanks to its outstanding features and broad applications. It comes with a graph query language called **nGQL**, which provides users with a rich set of graph operation functions. Whether for basic CRUD operations on nodes and edges or complex graph algorithms and path queries, nGQL handles them effortlessly. This **flexibility and robust functionality make NebulaGraph an excellent choice for handling complex network structures and maximizing the value of medical case data**.

**Specific steps:**

* Algorithm pseudocode

* Construct prompt templates, related cases, and relationship lists

* Write functions to connect to **NebulaGraph**

* for i := 0 to N do // traverse medical case data

* Generate questions by combining data and templates

* Pass the questions to the LLM to get answers

* Clean the answers and remove unnecessary triples

* Build the IDs for patients, examinations, symptoms, and prescriptions in the current case

* for j := 0 to M do // iterate through the triple list


```
if relation'=="combination”:       
      Determine whether the Chinese herb in the triplet contains a dosage unit attribute. If it does, extract the attribute and store the extracted result in the knowledge graph. 
Else: Directly write the extracted results into the knowledge graph.
end for
```





# Experiment



This study utilizes a dataset of 353 pre-prepared medical cases as the foundation for knowledge extraction experiments using large language models (LLMs). In the experiment, other LLMs are employed for data annotation, followed by manual verification and correction to ensure the accuracy and reliability of the annotated data. This process serves to evaluate the knowledge extraction performance of each model. The Bert-BiLSTM-CRF model is selected as the baseline for joint entity and relationship extraction, and the results of automatic extraction using the Bert-BiLSTM-CRF model are compared with those obtained from large language models, primarily GLM3, GLM4, and ChatGPT-4. The evaluation metrics include F1 score, precision, and recall, with the experimental results presented in the table.
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/%E9%BC%BB%E7%82%8E%E7%9F%A5%E8%AF%86%E5%9B%BE%E8%B0%B1/2.png)



# Knowledge Graph Display


This study leverages the constructed knowledge graph to analyze and mine medication patterns used by a master physician in treating rhinitis, such as identifying the top 10 drugs most frequently prescribed for severe sneezing symptoms. The following Cypher query is executed to achieve this:

```
MATCH (v:Patient)-[:HAS_SYMPTOM]->()-[:SPECIFIC_SYMPTOM]->(v1) 
WHERE id(v1) = 'severe sneezing' 
MATCH (v:Patient)-[:PRESCRIBED]->(v3)-[e2:COMPONENT_OF]->(v4) 
RETURN v4, count(v4) AS cnt 
ORDER BY cnt DESC 
LIMIT 10;
```



This query identifies patients exhibiting severe sneezing symptoms, retrieves their treatment prescriptions, and sorts the drugs by frequency of occurrence, returning the top 10 most frequently prescribed drugs. The top 10 drugs are: Cicada Skin, Windproof, Ink Plant, Licorice, Earthworm, Black Soybean Coat, Chebulic Myrobalan, White Atractylodes, Rubia Root, and Astragalus.
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/%E9%BC%BB%E7%82%8E%E7%9F%A5%E8%AF%86%E5%9B%BE%E8%B0%B1/3.png)


This paper introduces how to build a knowledge graph for the treatment of rhinitis with traditional Chinese medicine using NebulaGraph.

Rhinitis Knowledge Graph in Traditional Medicine Using NebulaGraph

We are thrilled to announce the General Availability of the NebulaGraph Cloud Standard Tier with 14-day free trial! [NebulaGraph Cloud](https://www.nebula-graph.io/cloud-2025) is a fully-managed graph database service designed to support and enhance Graph RAG projects. It offers native support for ISO-GQL, the industry's first standardized graph query language, ensuring seamless integration with various AI models and tools. This support for ISO-GQL enables efficient querying and retrieval of data from the graph database, providing the necessary context for AI models to generate high-quality content.

# The Ideal Choice for Various Users

Graph databases excel at handling complex, interconnected data by modeling it as nodes and edges, which represent entities and their relationships, respectively. This structure enables efficient querying and analysis of data connections, making it ideal for applications where understanding relationships is crucial. The Standard Tier of NebulaGraph Cloud is tailored to meet the needs of different user groups:

- **Individual Developers**: For those looking to expand their skill set or build innovative projects, such as Graph RAG, the Standard Tier offers an affordable and accessible tool for learning and experimentation. It allows them to focus on developing their Graph RAG models without worrying about the underlying infrastructure complexities.

- **Data Scientists and Researchers**: The platform provides a robust environment for academic research and experimentation with Graph RAG. Researchers can leverage NebulaGraph Cloud to analyze complex datasets, develop novel Graph RAG algorithms, and gain valuable insights into the intersection of graph databases and generative AI.

- **Startup Founders and Small Teams**: For startups and small teams, the Standard Tier offers quick setup and minimal maintenance, allowing them to rapidly prototype and scale their AI projects. It helps them bring their innovative ideas to life without the need for extensive resources or expertise in managing graph databases.

# Key Features of NebulaGraph Cloud:

- **ISO-GQL Support**: NebulaGraph Cloud is the first to support the ISO-GQL standard graph query language on the cloud, allowing users to experience this powerful querying capability firsthand.

- **Beginner-Friendly**: Features no-code graph creation and interactive visual analysis, along with built-in demo datasets, making it accessible for beginners.

- **Flexible Data Modeling**: Supports multiple data types and complex relationship modeling, making it versatile for a variety of applications.

- **Observability**: Includes a monitoring dashboard with visual charts and continuous performance and resource utilization reporting.

# Special Launch Pricing:
**For the first 14 days after creating an instance, NebulaGraph Cloud Standard Tier will be available for free.** After the trial period, if the instance is not deleted, it will automatically start charging at a special discounted rate, with the benefit of this discounted pricing extending for the first six months.

Don’t miss this opportunity to innovate with NebulaGraph Cloud. **[Sign up for the 14-day free trial](https://cloud.nebula-graph.io/login) and experience the future of graph databases with native ISO-GQL support now!**

We are thrilled to announce the General Availability of the NebulaGraph Cloud Standard Tier with 14-day free trial!

Unlock the Power of Graphs: NebulaGraph Cloud Standard Tier Launches with 14 Day Free Trial!

SQL (Structured Query Language) has been the standard language for managing and querying relational databases for decades. Relational databases store data in tables and use structured schemas to define relationships between these tables. However, with the increasing complexity of data relationships in modern applications, there has been a growing need to model and query data in ways that go beyond traditional tabular structures.

Graph databases, such as Neo4j, Amazon Neptune, and NebulaGraph, have emerged to address these needs by storing data as nodes (entities) and edges (relationships). They are optimized for traversing and querying complex relationships, making them ideal for applications like social networks, recommendation engines, fraud detection, and network analysis.

In response to the rising popularity of graph databases and the demand for more flexible data modeling, several major SQL database systems have introduced support for graph queries. This includes the ability to create, manage, and query graph structures directly within a SQL database, leveraging the familiar syntax and capabilities of SQL. 

This introduction does bring benefits to organizations looking for unified data management as both relational and graph data can be managed within the same database system, simplifying their data architecture and reducing the need for multiple specialized databases. However, it does not necessarily mean that graph databases will no longer be needed or that they will be replaced. 
Here are several key points to consider regarding the impact of this development on graph databases:

# Data Model Complexity and Flexibility
The graph database is a natural fit for graph data. If the data inherently represents complex relationships and networks (e.g., social networks, knowledge graphs), a graph database provides a more natural and intuitive way to model and query the data. What’s more, graph databases offer more flexibility in evolving the data model. In relational databases, schema changes can be complex and disruptive, whereas graph databases allow for more dynamic and flexible schema evolution.

# Query Language and Usability
Graph databases often provide specialized query languages (e.g., Cypher for Neo4j, Gremlin for TinkerPop) that are designed specifically for graph traversal and pattern matching, making it easier to express complex queries. Since the ISO-GQL was officially released in April this year, the graph database industry is expecting this standard graph query language to provide a unified and standard experience for developers familiar with graph concepts, as using a standard graph-specific query language, can be more intuitive and efficient compared to using SQL extensions for graph queries.

# Real-Time Analytics and Insights
For applications requiring real-time insights and analytics, such as fraud detection or recommendation engines, graph databases are optimized for low-latency query execution and can handle real-time data updates and queries more effectively. Some graph databases are designed to integrate seamlessly with streaming data sources, enabling real-time graph updates and analytics. Apparently, under situations requiring real-time analytics and insights, even though relational databases can perform graph queries, they may not be ideal options.

# Scalability and Distributed Processing
In terms of scalability and distributed processing, relational databases with graph query support might not be competitive to dedicated graph databases. Many graph databases are designed to scale horizontally, distributing data and queries across multiple nodes in a cluster, for instance NebulaGraph. This can be particularly important for large-scale graph applications where the data volume and query complexity require distributed processing. Besides, dedicated graph databases often come with built-in, optimized graph algorithms (e.g., shortest path, centrality, community detection) that can be executed efficiently at scale. 

# Complementary Use Cases
Graph databases are optimized specifically for graph data and queries, offering advanced features such as efficient graph traversals, pattern matching, and handling of complex relationships. While SQL databases with graph query support can handle basic graph operations, dedicated graph databases are likely to remain superior for use cases that require high performance and scalability in graph processing. Therefore, SQL databases with graph capabilities and dedicated graph databases can coexist, each serving different needs and use cases.

# Performance Considerations
While SQL databases with graph query support can handle graph data, they might not match the performance and efficiency of dedicated graph databases, especially for large-scale graph processing and real-time analytics. Graph databases are designed with specific optimizations for graph workloads, such as index-free adjacency, which can significantly improve query performance for certain types of graph operations.

# Conclusion
In summary, while the support for graph queries in SQL databases enhances their capabilities and provides more flexibility, it does not render dedicated graph databases obsolete. Each type of database has its strengths and is suited for different use cases. Organizations will continue to choose the best tool for their specific requirements, and dedicated graph databases will remain crucial for applications that demand high-performance graph processing and advanced graph analytics. The coexistence of these technologies provides organizations with a broader range of tools to meet their diverse data management needs.

While the support for graph queries in SQL databases enhances their capabilities and provides more flexibility, it does not render dedicated graph databases obsolete.

Graph Databases vs. SQL with Graph Queries: Friends or Foes?

GQL, a property graph query language newly released this year by the ISO, is the second international standard database query language since SQL's debut over 40 years ago. It integrates the strengths of Cypher, SQL, and various general programming languages, making it a powerful tool for analyzing complex graph data.

# Building on Cypher: How GQL Enhances Graph Queries

## Enhanced Graph Pattern Matching

### Powerful Label Matching Syntax

One of the standout features of GQL is its advanced label matching syntax. This allows for more complex queries using logical operators such as `&`, `|`, and `!`.

In Cypher, a typical query might look like this:

```
MATCH (n:Person)
WHERE n.age > 30
RETURN n
```

With GQL, you can perform more sophisticated queries:

```
MATCH (n:Manager & FullTime | !Intern)
WHERE n.age > 30
RETURN n.name AS managerName, n.department AS dept
```

This GQL query finds nodes that are both `Manager` and `FullTime`, or not `Intern`, and have an age greater than 30.

### Regex-like Variable-Length Path Pattern

GQL introduces a regex-like syntax for variable-length patterns, enhancing flexibility in path matching. Examples include `-[e]->{1,3}`, `-[e]->+`, `-[e]->*`, and` -[e]->?`. This allows for more complex path pattern matching compared to Cypher’s syntax.

### Path Restrictors

GQL provides four path restrictors—`WALK`,`TRAIL`,`ACYCLIC`, and `SIMPLE`—to control whether paths can have repeated nodes or edges.

### Path Selectors

GQL offers versatile shortest path queries, including options for finding all shortest paths, any shortest path, and the top k shortest paths. This flexibility allows for detailed and efficient path retrieval in various scenarios.

## Modern Variable Definition

### Local Variable Definition

GQL introduces a dedicated syntax for defining local variables at the beginning of a procedure, similar to early C language practices. These variables are visible throughout the entire procedure scope. The introduction of local variables allows GQL to express nonlinear data flows, enabling data to be reused multiple times.

For instance, when users need to perform multiple analyses on the same dataset, GQL's local variables provide an efficient way to store and reuse intermediate results. This is particularly useful for complex calculations or when the same base data needs to be processed in different ways.

Consider a scenario where we want to analyze user interactions in a social network:

```
TABLE userActivity = {
    MATCH (u:User)-[a:ACTION]->()
    RETURN u.id AS userId, a.timestamp AS actionTime, a.type AS actionType
}
 
VALUE activeUsers = VALUE {
    FOR i IN userActivity
    WHERE i.actionTime > datetime('2024-01-01')
    RETURN collect_list(DISTINCT i. userId)
}
 ​
VALUE uniqueActionTypes = VALUE {
    FOR i IN userActivity
    WHERE i.userId IN activeUsers
    RETURN count(DISTINCT i.actionType) AS uniqueActionTypes
}
```

In this example,` userActivity` captures the base dataset of user actions, which is then reused to identify active users and calculate action statistics. This demonstrates how GQL's local variables enable efficient data reuse and modular query construction.

### The LET Statement: Another Way to Define Variables

The LET statement in GQL defines variables by adding a new column to the current output table, unlike VALUE, which creates procedure-scope visible variables. LET is non-blocking, allowing you to define new variables without interrupting the flow of existing ones, unlike Cypher’s WITH, which requires manual inclusion.

In Cypher, you must explicitly pass all existing variables when defining a new one:

```
MATCH (v)-[e]->(v2)
WITH v, e, v2, 1 AS a
```

Or use `WITH *` to retain all:

```
MATCH (v)-[e]->(v2)
WITH *, 1 AS a
```

In GQL, `LET` simplifies this process:

```
MATCH (v)-[e]->(v2)
LET a = 1
```

Here, `v`, `e`, and `v2` remain accessible, and `a` is seamlessly added. This makes `LET` a more efficient and intuitive choice for variable definition.

## Complex Nested Queries

GQL's `CALL` statement allows you to encapsulate a set of statements into a subquery block, treating them as a single unit that can be referenced by outer statements. This is particularly useful when you need to apply operations on the combined results of multiple queries.

For example, to sort the combined results of two different queries:

```
CALL {
    MATCH (v:Person) RETURN v.name AS name
    UNION
    MATCH (v:City) RETURN v.name AS name
}
ORDER BY name
```

The `CALL` block enables the `ORDER BY` to be applied to the unioned results, rather than just the last query.

# Comparison between GQL and SQL/PGQ

SQL/PGQ extends its graph query capabilities based on SQL, and it shares a read-only graph pattern matching syntax with GQL. However, compared to SQL/PGQ, GQL provides a complete set of read-write syntax, which can better meet the various operation requirements of graph databases.

In addition, although SQL is powerful, its syntax design has some well-known issues. For example, the clause order of SQL is not intuitive and difficult to combine, and users often need to use workarounds to achieve complex requirements. Google recently published an article titled "SQL Has Problems. We Can Fix Them: Pipe Syntax In SQL," pointing out these syntax design issues of SQL and proposing a special pipeline operator aimed at making clauses more linear and combinable, thereby enhancing the flexibility and intuitiveness of SQL.

GQL, on the other hand, is inherently linear and composable. It features orthogonal statements like `MATCH` for graph pattern matching, `FILTER ` for filtering results, `FOR ` for iterating over lists, `LET` for variable definitions, and CALL for complex nested queries.

In addition, GQL includes `INSERT`, `SET` and other DML statements, which can be also elegantly combined in a linear manner with DQL statements.

For example, you can match nodes and then insert an edge between them:

```
MATCH (a:player{id:1, name:"Tim"}(b:player{id:2, name:"Jerry"})
INSERT (a)-[:follow{followness:90}]->(b)
```

The following two figures intuitively demonstrate the differences in syntax between SQL and GQL.

**Figure 1: SQL's Rigid Clause Structure**

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/74ac57c6f7a292190fc6b1ff2b10139f.png)

**Figure 2: GQL's Linear Statement Composition**

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/c5ab0435a24e95b58f87f65bde9d2103.png)

# Looking Forward: The Road Ahead for GQL

The first version of GQL has already included numerous features, showcasing the outstanding contributions of the standard committee members. Personally, I look forward to the possibility of future developments such as subgraph extraction, diverse table construction methods, window functions, and advanced programming constructs like conditional statements, loop statements, and lambda expressions. These enhancements will further solidify GQL's role as a powerful and user-friendly query language。

As a modern, advanced data query language, GQL excels in functionality and ease of use, making it essential for industries managing vast networks, such as telecommunications and social media. Its capability for real-time analytics provides immediate insights, which is crucial for decision-making in dynamic environments. Looking ahead, GQL's ongoing development promises to shape how we interact with data, paving the way for innovations in AI, healthcare, logistics, and beyond.

In conclusion, GQL is set to transform data management, and we eagerly anticipate its future advancements.


GQL, ISO's new graph query language, boosts complex data analysis with advanced pattern matching and versatile queries, vital for network-intensive industries.

Tag