Why I’m Building a Visual DynamoDB Schema Designer

I’ve been building on DynamoDB since SST made it easy to set up and deploy. Over the past couple of years, I’ve shipped rasika.life (a platform for Indian classical arts events), rekha.app, an Airbnb property management tool, and a handful of proof-of-concept SaaS, analytics, and e-commerce apps — all on single-table DynamoDB with ElectroDB.

I know how to design these schemas. What I don’t have is a good tool for doing it.

The process that works (but shouldn’t be necessary)

Here’s what my actual schema design workflow looks like today:

1. Write down access patterns on paper or in a notes app
2. Mentally map each access pattern to a PK/SK structure or GSI
3. Open my editor and start writing ElectroDB entity definitions
4. Realize halfway through that GSI3 conflicts with the access pattern I planned for GSI4
5. Refactor. Test. Refactor again.
6. Deploy, discover I missed an access pattern, add another GSI

For my events entity in rasika.life, I ended up with six GSIs — by creator, by status, by festival, by venue, by organiser, and by art form. Each one sorts by startDateTime so I can query upcoming events efficiently. I also denormalize artist data into the event record for read performance, then maintain a separate junction entity for reverse lookups (find all events for a given artist). When an artist’s name changes, a cascade function propagates the update.

None of this is exotic. It’s standard single-table design. But I designed it entirely in my head and in code, with no visual representation until after it was built.

The tools that exist aren’t solving this

I tried NoSQL Workbench. The UX is genuinely painful — desktop-only, form-based input for every attribute, a “facets” feature for access patterns that’s so clunky I gave up and went back to my notes app. One reviewer summed it up well: they were confused about who the product was actually for. I share that confusion.

Dynobase was the community favourite for a while, endorsed by Alex DeBrie and Rick Houlihan. But it hasn’t been meaningfully updated since 2022. GitHub issues pile up unanswered. It’s effectively abandoned.

Hackolade is a serious schema design tool, but at €175/month per seat, it’s built for enterprise teams, not for an indie developer shipping a side project on weekends.

There’s nothing in between. No web-based, visual schema designer where I can drag entities onto a canvas, define PK/SK patterns, wire up GSIs, validate my access patterns, and export infrastructure code. The dbdiagram.io for DynamoDB doesn’t exist yet.

What I’m building

SingleTable is a visual DynamoDB schema designer — web-based, built for single-table (and multi-table) design patterns.

Here’s the plan:

• Visual canvas — entities as draggable cards with color-coded types, PK/SK patterns visible at a glance, GSI connections rendered as visual links between entities
• Access pattern validation — define patterns like “get all events for a venue, sorted by date” and the tool maps them to your schema, flags gaps, and shows a coverage matrix
• IaC export — generate working CDK, SST, Terraform, CloudFormation, or SAM code from your visual design. No more manually translating a schema diagram into 200 lines of CDK
• Schema pattern library — battle-tested templates for SaaS multi-tenant, e-commerce, social feeds, chat apps, and more. Fork one and customize it.
• Shareable links — send your schema to a teammate or post it in a PR review. No screenshots of spreadsheets.

I’m building this on the same stack I use for everything: SST v3, React, TypeScript, DynamoDB (dogfooding my own tool from day one).

Why content first

Before I write a line of product code, I’m publishing the schema patterns I’ve learned from building real apps. Each pattern — SaaS multi-tenant, e-commerce orders, event management — will be a blog post with access patterns, PK/SK structures, sample data, and ElectroDB entity code.

This serves two purposes: it builds credibility in a space where credibility matters (DynamoDB design is opinionated and experience-dependent), and it creates the pattern library that will eventually live inside the tool.

If you’re a DynamoDB developer who’s tired of designing schemas in spreadsheets, sign up for updates. I’ll be sharing patterns, build progress, and early access as the tool comes together.

You can also follow the build on Twitter/X at @singletabledev.

---

This is post #1 of building SingleTable in public. I’ll share the technical decisions, the mistakes, and the metrics as I go.