Throughput and capacity calculator for AWS specialty databases

The moment this becomes a real problem is when a developer is staring at DynamoDB's capacity mode settings or ElastiCache's node configuration before launch, realizing they have no principled way to pick numbers — so they guess, go over-provisioned by 10x to be safe, and get a surprise bill, or they under-provision and get throttled in production.

AWS has no incentive to make this easier. Over-provisioning means more revenue for them. The buyers here are often senior engineers or architects who have enough credibility to push back, but they're too busy to fight this battle — and the actual users (mid-level developers) don't have the organizational standing to get tooling budget approved for something this narrow. That's why the gap persists: the person who feels the pain most isn't the person signing the procurement check.

The specific complaint that cuts deepest is 'you have to have a lot of esoteric knowledge about calculating throughput in order to set things up.' That's not a complaint about missing docs — it's a complaint that the mental model required to use the product correctly isn't teachable in an afternoon. Existing capacity estimators are either built into the AWS console (which requires you to already understand the units) or are generic infrastructure cost calculators that don't understand the access-pattern-driven nature of DynamoDB reads/writes or Neptune traversal costs.

This is a business and not a feature because the need recurs at every new project, every traffic spike re-evaluation, and every time a team onboards a new database service. A team that launches three new services a year is doing this calculation three times with real money at stake each time. The cost of getting it wrong isn't just the bill — it's the incident, the weekend on-call, and the re-architecture that follows.

What to build

Build a web-based calculator where developers describe their access patterns in plain terms (reads per second, item size, query shape) and receive a recommended DynamoDB capacity mode, ElastiCache node tier, or Timestream magnetic vs. memory store split — with a cost projection and a plain-language explanation of what changes if traffic doubles.

Where to start

Start specifically with DynamoDB capacity mode selection, because it has the sharpest documented user pain ('calculating throughput') and the most binary, high-stakes choice — provisioned vs. on-demand with RCU/WCU math — where a wrong decision shows up immediately as either throttling or a bill shock.

The hard part

The hardest thing is that accurate recommendations require enough context about access patterns that the input form either becomes intimidating (defeating the purpose) or stays too simple to produce trustworthy output — you have to find the minimal set of questions that still produces a defensible answer.

How it makes money

Free for single calculations; $29/month per team for saved configurations, change history, and alerts when AWS pricing changes in a way that shifts your optimal setup.