Inside Nebula Graph: Architecture, Cloud‑Native Challenges, and DBaaS Solutions

Graph databases use nodes, edges, and properties to model semantic relationships, enabling use cases such as social friend recommendation, financial risk control, and real‑time retail recommendations.

Nebula Graph Overview and Architecture

Nebula Graph is a high‑performance, linearly scalable, open‑source distributed graph database that separates storage and compute. Its architecture consists of three core services—Graph Service, Meta Service, and Storage Service—each replicated across nodes for fault tolerance.

The Graph Service (process nebula-graphd) is stateless, parses nGQL queries via a lexer and parser, generates execution plans, and executes them using schemas from Meta Service and data from Storage Service.

The Meta Service (process nebula-metad) implements a Raft‑based distributed cluster, storing metadata such as spaces, schemas, partitions, tags, and edges, and handles data migration and leader election.

The Storage Service (process nebula-storaged) follows a shared‑nothing design with local KV stores (RocksDB or HBase) on each node, using Raft for consistency.

Nebula Graph provides client libraries for C++, Java, Go, Python, and Rust, communicating via RPC over Facebook‑Thrift, and can be accessed through nebula-console or nebula-studio.

Multi‑Cloud Architecture Challenges

Business challenges : Need a unified resource abstraction model across cloud providers, plus internationalization for regional regulations and user habits.

Performance challenges : Cross‑cloud network latency can become a bottleneck; auto‑scaling across multiple clouds is complex.

Operational challenges : Managing large Kubernetes clusters, standardizing operations, visualizing management, and ensuring data security during cross‑region migrations.

DBaaS and Cloud‑Native Strategy

Nebula Graph is positioned as a Database‑as‑a‑Service (DBaaS) platform, leveraging cloud‑native technologies for elastic scaling, cost control, and multi‑cloud deployment.

Cloud‑native concepts provide agile, elastic, and reproducible resource usage, moving from IaaS to cloud‑native application layers, increasing modularity, automation, and fault tolerance.

NebulaCloud User View and Architecture

Users can interact via a web‑based Studio or a private‑link that connects directly to Nebula instances using nebula-console or client libraries.

The NebulaCloud architecture has three layers: a resource‑adaptation layer abstracting multi‑cloud resources, a business layer (instance management, tenant management, billing, data import), and a gateway layer exposing services.

Internal Process Example (AWS)

When a user requests a new instance, the nebula-platform service schedules resources based on provider, region, and specifications, creates the cluster via the nebula-operator API, and configures an ALB for access.

Nebula‑Operator and Kubernetes Integration

The Nebula‑Operator uses a CustomResourceDefinition (CRD) to manage Nebula clusters within Kubernetes, enabling elastic scaling, rolling upgrades, and API‑driven management for PaaS integration.

KubeSphere Multi‑Cluster Management

KubeSphere provides a unified management console for all Kubernetes clusters, supporting multi‑cluster deployment, IaC‑driven provisioning (Pulumi), automated alerts (email and DingTalk), and intelligent operations with global dashboards and predictive fault analysis.

Future Plans

Upcoming work includes custom alert strategies, a monitoring panorama covering Nebula metrics, multi‑dimensional alert mechanisms, enhanced tooling to reduce human error, and a DevOps workflow that streamlines development, testing, staging, and production.