# Scheduling Amazon Neptune Cluster

> Neptune stops as a cluster, taking writer and up to 15 read replicas together via the management API, and AWS restarts it on its own after 7 days. Storage and backups bill through the stop, and the first morning queries run against an empty buffer pool, so expect slow traversals before the caches refill.

Source: https://zop.dev/integrations/aws/neptune/schedule
Updated: 2026-08-19

---

## Writer and replicas move as one

Neptune's stop is cluster-scoped. The writer and every read replica shut down in the same
operation and return in the same operation; there is no leaving one replica up for a
skeleton-crew workload. That makes multi-replica development clusters the highest-value
candidates: each replica is its own instance-hour meter, and the stop pauses all of them at
once.

## The one-week ceiling

Like its relational cousins, a stopped Neptune cluster does not stay stopped past 7 days.
AWS starts it to apply pending maintenance. Nightly and weekend schedules reset the clock every
cycle and never hit the ceiling. The trap is reserved for clusters somebody stopped by hand and
walked away from: those return unbidden and bill on.

## Storage does not stop with the cluster

Graph storage, automated backups and snapshots continue at full rate during the off window. A
cluster with a large property graph keeps paying for every gigabyte at 3am. The schedule's
saving is the instance-hours of the writer plus replicas, and nothing else. Quote it that way.

## Cold buffers make slow first traversals

Neptune leans hard on its buffer pool cache, and a freshly started cluster has an empty one.
The first multi-hop traversals of the morning read from storage and can run several times
slower than the same queries at 5pm the previous day. If a dashboard or batch job runs at open
of business, either warm the cache with representative queries after start or set the start
early enough that organic traffic does the warming.

## Interrupted work does not resume

Bulk loads via the loader endpoint, long-running Gremlin or SPARQL queries, and streams
consumers all stop when the cluster does, and none of them pick up where they left off. Close
the nightly load before the stop cron, or make the loader job responsible for checking the
schedule before it starts.