You want to add a knowledge graph to your agent pipeline — GraphRAG, entity resolution, something that actually needs relationships. You look at Neo4j Aura. The free tier caps at 200K nodes. You need more. The next tier is $65/month for a tiny instance. A production instance? Thousands. And that's one graph. You need one per tenant? Per agent? Forget it.
Graph databases have some of the worst price-to-value ratios in all of data infrastructure. The technology is genuinely powerful. The economics are hostile. And the deployment story is somehow worse than the pricing.
#The sticker shock
Real Neo4j Aura pricing:
- →Free: 200K nodes, 400K relationships. Enough for a toy.
- →Professional: starts ~$65/mo for 1GB. Grows fast.
- →Enterprise: “contact sales.” Translation: $thousands/month minimum.
- →Self-hosted Enterprise: $100K+/year license just for the software.
Compare against the rest of the database world:
| 10GB on... | Monthly cost |
|---|---|
| Postgres on Neon | ~$19/mo |
| Redis on Upstash | ~$60/mo |
| Neo4j Aura | ~$500+/mo |
| Amazon Neptune | ~$400/mo + I/O charges |
Graph databases cost 5–25x more per GB than relational or key-value. That's not a premium. That's a different category.
#How Neo4j pricing actually works
What you're actually paying for:
RAM-based architecture. Neo4j keeps the working set in memory. You're paying for the instance size, which means you're paying RAM prices 24/7. Whether your graph is being queried or sitting idle at 3am — same bill.
Always-on. No scale to zero. Neo4j Aura pauses “free” instances after inactivity, but paid instances run continuously. You can't pause a Professional instance.
Per-instance isolation. Want separate graphs for separate tenants? Each one is a new instance. A new bill. There's no multi-tenant isolation within an instance — just label-based filtering, which isn't real isolation.
Enterprise licensing wall. Community Edition is limited (no clustering, no security features, no hot backups). Everything you need for production requires Enterprise license or Aura Enterprise.
Open drivers, closed features. The Bolt drivers are open source. The server features (online backup, causal clustering, role-based access) are behind the paywall. You build on open drivers, then discover you need closed features.
#The managed alternatives aren't better
The grass is not greener anywhere in the graph ecosystem:
Amazon Neptune: Starts at ~$115/mo for the smallest instance (db.t3.medium). Charges per I/O request ON TOP of the instance cost. No Cypher — you're stuck with Gremlin or SPARQL. Different query language, different ecosystem, different pain.
Azure Cosmos DB (Gremlin API): Pay-per-RU model makes costs unpredictable. It's not really a graph database — it's a document store with a graph API bolted on. Traversal performance reflects this.
Memgraph Cloud: Genuinely better pricing than Neo4j (~$50/mo for small instances). Cypher-compatible. But still server-based. Still always-on. Still one instance per workload. The architecture is the same; the price is just lower.
FalkorDB: Open source, Redis-based graph module. Interesting technology. But no managed offering with good economics. You're back to self-hosting.
The common thread: every option is server-based. The pricing problem isn't about any one company being greedy. It's structural. Graphs on servers are expensive.
#The deployment tax
Pricing is only half the pain. The deployment story for graph databases is brutal.
Self-hosting Neo4j: JVM-based. Requires Java 17+, significant heap tuning. Get the memory settings wrong and you get GC pauses or OOM kills. Configuration is a maze — neo4j.conf has hundreds of options. Default configs are not production-safe. Clustering requires Enterprise Edition. Community is single-instance only. Upgrades between major versions require migration procedures.
Docker: Official image works but resource management is tricky. JVM inside containers requires careful memory limits. No easy way to run hundreds of isolated instances on one machine.
Kubernetes: Neo4j has a Helm chart. It works. But each Neo4j instance is a StatefulSet. Running 100 tenant graphs means 100 StatefulSets. Resource overhead per instance is significant (JVM baseline ~512MB).
The pattern: graph databases assume you're running one big instance for your whole application. The tooling, configuration, and operational model all reflect this assumption. Per-workload isolation wasn't a design goal.
#Why it's this way
This isn't entirely greed. There are real technical reasons.
Graph traversals are memory-intensive. Following relationships across nodes is a random access pattern. RAM is genuinely faster for this. Neo4j's architecture — keep the graph in memory, traverse pointers — made sense when RAM was $3/GB and getting cheaper.
But RAM isn't getting cheaper anymore. DRAM spot prices tripled in 2025. Server DDR5 contracts are rising 18–23% per quarter. AI is consuming wafer capacity. No relief until 2027+. The “keep everything in RAM on a dedicated server” model is getting structurally worse every quarter.
The business model reinforces the architecture. Neo4j makes money selling instances. Making graphs cheap to idle or cheap to create would cannibalize their revenue. They have no incentive to solve this.
And the use cases have outgrown the architecture. When Neo4j was designed, a “graph database user” was a company with one big graph — social network, fraud detection, recommendation engine. Run one instance, query it from your application. The model worked. Now? GraphRAG pipelines want a knowledge graph per query. Agent platforms want a graph per session. Multi-tenant SaaS wants a graph per customer. The “one big instance” model breaks at exactly the moment graph databases are becoming more useful.
#The use cases are changing
The fastest-growing graph use cases all share a pattern: they need many small, ephemeral, isolated graphs — not one big shared one.
GraphRAG: Build a knowledge graph from retrieved documents, traverse it to find relationships, discard when done. You don't need a $500/mo instance for a graph that lives for 30 seconds.
Agent knowledge bases: Each agent session builds context as a graph — entities, relationships, conversation history. Needs to be isolated per session. Needs to be disposable.
Entity resolution: Match and deduplicate records by building a graph of similarities. Run it as a batch job. Delete when done.
Per-tenant data models: B2B SaaS where each customer has their own relationship data. 500 tenants = 500 graphs. At Neo4j pricing? That's $32,000/month for 1GB each.
These use cases need: instant creation, scale to zero, per-workload isolation, and cheap idle costs. The graph database ecosystem offers none of this.
The graph database ecosystem has a structural problem: the architecture assumes one big always-on server, but the fastest-growing use cases need many small ephemeral graphs.
In Part 2, we'll make the case that your graph database should be a file.
There's a better way
Cinch Graph: Bolt-compatible, Cypher queries, scale to zero, a fraction of the cost.
GET STARTED →