Local dev environment for AWS graph and cache databases

A developer reaches the point where every time they run tests or spin up a local environment, they either point at a real AWS endpoint and rack up unexpected charges, or they paper over the gaps with mock libraries that don't actually behave like Neptune or MemoryDB. The complaint 'no local deployment and only available with AWS' isn't just inconvenient — it means you can't reliably test locally, and your CI/CD pipeline either costs money per run or lies to you.

Amazon has no structural incentive to fix this. Every dev-environment connection to a real AWS cluster is billable. Local emulators cut into consumption revenue. They shipped a DynamoDB local emulator years ago and it never kept pace with new features — which tells you exactly how much prioritization local dev gets when the cloud meter is running.

Existing mock libraries and emulators cover DynamoDB reasonably, but Neptune (property graph and RDF, with Gremlin and SPARQL interfaces) and MemoryDB (Redis-compatible with durable persistence guarantees) have almost no maintained local equivalents. Developers working with these either hit the cloud for every test or skip meaningful integration testing entirely.

This is a recurring business need, not a one-time fix. Every new developer who joins a team using these databases faces onboarding friction. Every new CI job needs a local-equivalent endpoint. Every cost-conscious team that wants to gate cloud access hits this wall repeatedly. Teams don't buy this once — they depend on it continuously, and the need compounds as headcount and CI job count grow.

What to build

Build a locally runnable Docker image that faithfully emulates Neptune's Gremlin and SPARQL query behavior and MemoryDB's Redis-compatible persistence semantics, with a configuration layer that lets developers swap endpoints between local and AWS without changing application code.

Where to start

Target Neptune specifically, since it has the worst local dev story and the smallest existing ecosystem of workarounds — a team that has committed to a graph database is in more pain than a DynamoDB team that can at least use the official (if stale) local emulator.

The hard part

Neptune's query execution behavior — especially around Gremlin traversal semantics and SPARQL inference — is underdocumented at the engine level, meaning you'll hit correctness gaps that users will find quickly and that are expensive to diagnose and fix without access to Neptune's internals.

How it makes money

Free tier for solo developers running the container locally; paid team license per month that unlocks CI/CD integration configs, multi-version support, and a management UI — priced around what a team currently wastes monthly on dev-environment AWS charges.