--- title: "Why Aerospike Graph" description: "Discover why Aerospike Graph is ideal for large-scale workloads, featuring predictable NVMe performance and Gremlin." --- # Why Aerospike Graph > For the complete documentation index see: [llms.txt](https://aerospike.com/docs/llms.txt) > > All documentation pages available in markdown. Aerospike Graph is built for teams running large-scale, latency-sensitive graph workloads who can’t afford performance that degrades under load or operations that don’t scale. Whether you’re migrating from another graph database or starting fresh, here’s why teams choose Aerospike Graph. --- ## Predictable performance as you scale _“We had to cut our dataset by 100x to fit in memory so queries wouldn’t time out”_ With Aerospike Graph, you don’t have to choose between dataset size and query performance. The [Hybrid Memory Architecture (HMA)](https://aerospike.com/blog/hma-storage-engine-explained/) keeps indexes in RAM while storing data on high-speed NVMe, delivering predictable latencies that don’t depend on cache hits or misses. - **Consistent latency as you scale:** Query performance stays the same whether you have 1 million, 1 billion, or 100 billion elements. - **Tight percentile variance:** P50 and P99 latencies remain close, so tail latency doesn’t spike unexpectedly. ::: architect **Why it matters:** Set SLAs you can actually meet. No query rewrites or caching layers as data grows. No surprise timeouts after migrations. ::: --- ## Scale compute and storage independently _“Every time we need more query throughput, we have to spin up another read replica with a full copy of the data”_ Aerospike Graph separates compute (AGS) from storage (Aerospike Database), so you can scale each layer based on what you actually need. - **Scale query throughput:** Add or remove stateless AGS instances without touching your data layer. No data migration required. - **Scale storage:** Add database nodes when you need more capacity. Your compute layer stays the same size. ::: operator **Why it matters:** Pay for what you need. Scale up for peak traffic, scale down when it’s quiet. AGS instances work with Kubernetes HPA like any stateless service. ::: --- ## Use standard Gremlin, not a proprietary language _“We don’t want to bet on a query language only one vendor supports”_ Aerospike Graph implements Apache TinkerPop. Gremlin is an open standard with drivers for Java, Python, Go, .NET, and more. - **Migrating from another Gremlin database:** Your queries work with minimal to no changes. - **Coming from openCypher:** Your graph thinking transfers. Only the syntax changes. - **New to graph databases:** The Gremlin community has extensive resources. Check out [Practical Gremlin](https://kelvinlawrence.net/book/Gremlin-Graph-Guide.html) for a primer on Gremlin. ::: developer **Why it matters:** No proprietary query language. Your skills stay transferable, your code stays portable. ::: --- ## Lower infra costs, deploy anywhere _“Every graph database we’ve evaluated is prohibitively expensive at our scale”_ Graph database costs typically scale with DRAM and coupled compute/storage. Aerospike Graph eliminates both constraints. Data lives on NVMe instead of DRAM, and compute scales independently from storage. Infrastructure costs grow linearly with your data, not exponentially. - **Lower memory requirements:** Only indexes live in RAM. Far less memory than databases that keep everything in DRAM. - **Higher storage density:** More data per node means fewer nodes for the same dataset. - **Run anywhere:** Deploy on-prem or any public cloud, self-managed or fully managed. ::: architect **Why it matters:** Infrastructure costs can be 2-6x lower compared to other enterprise graph databases. No cloud lock-in. ::: --- ## Sharding and operations are handled for you _“We spent months figuring out how to partition our graph so connected vertices live on the same machine”_ Distributed graph databases typically require manual partitioning to colocate connected vertices, otherwise traversals slow down crossing network boundaries. Aerospike Graph doesn’t have this constraint. - **No manual partitioning:** Data is distributed and rebalanced automatically. No domain-based partitioning schemes to maintain. - **True distribution without the penalty:** Sub-millisecond element access means traversals don’t slow down when crossing machine boundaries. - **Rolling upgrades:** Upgrade your cluster without taking it offline. ::: operator **Why it matters:** Your graph can grow and evolve without rearchitecting how data is distributed. Add nodes, and the cluster rebalances automatically. ::: --- Ready to try it out? [Quickstart](https://aerospike.com/docs/graph/quick-start/) Want to see the numbers first? [View benchmarks](https://aerospike.com/resources/benchmarks/aerospike-graph/)