The situation that drives someone here: a developer needs to answer a business question from DynamoDB data — find all orders over $500 in the last 30 days across multiple users — and realizes they either need to scan the entire table (expensive), build a secondary index they didn't plan for (requires schema changes), or export to S3 and query with Athena (slow, requires knowing Athena, and as users note, 'the data exported format is not in JSON'). What should take two minutes takes two days.
The gap persists because AWS's incentive is to sell more services — Athena, Lambda, ElasticSearch — not to make DynamoDB self-sufficient. Every complex query need is a revenue opportunity for another AWS product. The user who needs to 'write a ton of lambda functions for DynamoDB, unlike RDS which supports views, stored procedures, and functions' is generating more AWS spend, not less.
What's specifically missing is a query interface that understands DynamoDB's actual data model — partition keys, sort keys, sparse indexes — and lets developers write something resembling SQL or a MongoDB-style filter without needing to know whether it'll result in a Scan or a Query under the hood, and without paying for an Athena job or standing up an ElasticSearch cluster. Users also call out that they 'cannot export the output to Excel sheets directly' from the console, and that exports require S3 and produce non-JSON format — meaning even basic data verification tasks require multi-step AWS workflows.
This is a business because every developer who joins a team using DynamoDB hits these limitations within their first week, and the pain recurs with every new access pattern. It's not a one-time migration problem — it's a daily development workflow problem. Teams don't abandon DynamoDB because they're already committed to it; they just absorb the friction, which means they'll pay to reduce it.
What to build
Build a desktop and web app where developers connect to a DynamoDB table via AWS credentials, write filter expressions in a SQL-like or MongoDB-style syntax, see the underlying DynamoDB operation (Query vs. Scan) and estimated cost before executing, and export results directly to JSON, CSV, or Excel without touching S3.
Where to start
Start with the export use case only — CSV and JSON export from the browser console is a universally requested feature that requires zero query planning complexity and has immediate, obvious value for any DynamoDB user who needs to verify data or share results with a non-technical stakeholder.
The hard part
DynamoDB's query model is fundamentally different from SQL — translating arbitrary SQL-like syntax into efficient DynamoDB operations without silently falling back to expensive full-table scans requires a non-trivial query planner, and getting that wrong destroys trust immediately when a user gets a surprise bill.
How it makes money
One-time purchase for the desktop app at $79, with a team license at $199/year that adds shared saved queries and team access controls.
See the evidence. The complaints behind this idea, the products they came from, and similar ideas in Database as a Service (DBaaS).
More ideas in Database as a Service (DBaaS)