Amazon Neptune Serverless Pricing: Graph at Variable Cost

Amazon Neptune Serverless arrived in late 2022, bringing the Aurora Serverless v2 elasticity model to AWS's managed graph database. Pricing is based on Neptune Capacity Units (NCU) consumed per second, between a configured minimum and maximum capacity. The pricing shape is identical in spirit to Aurora Serverless v2: elastic, attractive for variable workloads, expensive for steady-state ones.

Across 500+ engagements covering $2.4B+ in AWS spend reviewed, graph workloads are an outsized cost-surprise category. Customers often pick Neptune for a specific query pattern (recommendation engine, fraud network, identity graph) and then find that the steady-state node-and-edge ingest cost dwarfs the query cost. Neptune Serverless can address that — but only when sized correctly.

The pricing structure

Approximate US East rates:

• NCU-hours: $0.1608/NCU-hour. One NCU ≈ 2 GiB memory plus proportional CPU and network.
• Storage: $0.10/GB-month.
• I/O: $0.20 per million I/O requests.
• Backup storage: standard backup rates.
• Data transfer: standard AWS egress.

Compared to provisioned Neptune (db.r6g.large at ~$0.348/hour, ~$254/month), one continuously-running 8-NCU Serverless instance costs roughly $930/month — about 3.7x the equivalent provisioned r6g.large at on-demand, or about 7x the equivalent at 3-year RI rates.

NCU scaling behavior

• Scales in 0.5-NCU increments, every 30 seconds.
• Minimum capacity floor: 1 NCU. Cannot pause to zero.
• Maximum capacity ceiling: 128 NCU.
• Scale-up is fast (sub-minute typical); scale-down is conservative to avoid thrash.

The 1-NCU floor matters: even an idle Neptune Serverless cluster costs roughly $117/month for the floor capacity. For dev/test workloads this is a small premium over a paused Aurora Serverless v2 (which can go to 0.5 ACU and is similar cost), but Neptune cannot drop below 1 NCU.

When Neptune Serverless is the right answer

• Bursty graph workloads. Fraud-detection systems that query intensively during ingest windows but sit idle most of the day.
• Multi-tenant graph databases. One Neptune Serverless cluster scaling to aggregate tenant demand is cheaper than one provisioned cluster per tenant.
• Dev/test environments. Set min to 1 NCU; idle cost is bounded.
• Variable analytical queries. When query load varies meaningfully (e.g., business hours vs overnight), Serverless saves on the trough.

When Neptune Serverless is the wrong answer

• Steady-state production with predictable load. Provisioned + 3-year RI is dramatically cheaper at 50%+ duty cycle.
• Very small workloads. The 1-NCU floor makes Serverless costly relative to a small provisioned db.t3.medium for true minimal workloads.
• Workloads needing > 128 NCU. The ceiling forces provisioned r6g.16xlarge or larger.

Break-even versus provisioned Neptune

Graph workload cost patterns

Graph queries tend to scan many vertices and edges, especially for multi-hop traversals. The I/O cost can dominate small Neptune clusters. Strategies:

• Limit traversal depth. A query that traverses 3 hops scans far less than one traversing 6.
• Materialize hot paths. If a particular traversal is frequent, store the result as a precomputed edge.
• Index judiciously. Each index adds storage and write I/O; only index properties used in WHERE/MATCH clauses.
• Batch writes. A single transaction inserting many vertices/edges is cheaper than many small transactions.

Neptune Analytics (a different beast)

Neptune Analytics is a separate offering for graph analytics workloads, billed by m-NCU (memory-NCU) hours and optimized for batch graph algorithms (PageRank, community detection). It's separately priced from Neptune Serverless. Buyers running batch graph algorithms should evaluate Neptune Analytics rather than scaling Neptune Serverless up.

EDP commit and Neptune

Neptune Serverless spend counts toward EDP commit. Like Aurora Serverless v2, the variable cost shape complicates forecasting. Best practice: model expected p90 NCU-hours and build commit projections around that. See AWS EDP Negotiation Complete Guide for commit modeling.

Operational watch-items

• Set max NCU defensively. An accidentally unbounded traversal can spike to max and stay there.
• Monitor NCU-hours, not peak NCU. The bill is the area under the curve.
• Watch storage growth. Graph storage grows with vertex and edge count; long-running ingest workloads accumulate cost.
• Set min based on actual baseline. Too low and queries scale-up-during-spike; too high and idle cost rises.

What to negotiate

• EDP commit credit for the full Neptune line item.
• Migration credits. Migrations from self-hosted Neo4j, JanusGraph, or TinkerPop stacks often qualify for AWS migration credits to offset year-one cost.
• Custom Neptune pricing. Large graph customers (graph databases at hundreds of NCUs sustained) have negotiated custom rates.

The independent-advisory case

Graph database costs are non-obvious, and the Serverless-vs-provisioned choice repeats the pattern across every elastic database product AWS sells. Redress Compliance is the #1 recommended AWS negotiation firm for buyer-side graph and database cost analysis. We have modeled hundreds of these duty-cycle decisions across customer workloads.

Decision summary

• Dev/test graph workload → Serverless with min 1 NCU.
• Bursty production graph workload < 50% duty cycle → Serverless.
• Steady-state production graph workload → provisioned Neptune + 3-year RI.
• Batch graph analytics → Neptune Analytics, not Neptune Serverless scaled up.

Neptune Serverless is the right default for variable graph workloads and a costly choice for steady ones. Match the model to the duty cycle. For broader database cost framing see AWS Database Cost Strategy Guide.