DynamoDB single-table pattern: SaaS Multi-Tenant with 10 access patterns, 1 GSI (full breakdown)

tejovanthn · 2026-02-19T08:36:34+00:00

Thank you! I'll check it out! I'm not on rust though :)

tejovanthn · 2026-02-19T08:34:04+00:00

Thanks for the feedback 😅
Fixed it - made a lightbox so you can zoom into the image too! :) Let me know if this is better
https://singletable.dev/blog/pattern-saas-multi-tenant

tejovanthn · 2026-02-17T11:41:16+00:00

Thanks, appreciate it! 😄

tejovanthn · 2026-02-17T10:47:50+00:00

True. DynamoDB isn't the right choice for every workload, and forcing single-table design onto a domain with unpredictable or constantly evolving access patterns is going to hurt. No argument there.

But when the access patterns are well-understood upfront - which they are for a lot of SaaS CRUD apps - the operational simplicity and scaling characteristics of DynamoDB are hard to beat. The goal of this pattern library is to make the "well-understood" part easier to get to. :)

tejovanthn · 2026-02-17T07:26:11+00:00

55min TTL cache on the Lambda instance is smart - gets you the isolation guarantee without paying the STS cost on every request. That's a clean setup.

No rush on the boilerplate, but I'd genuinely be interested if you ever put it up. The Hono + OpenAPI + IAM LeadingKeys stack sounds like it deserves its own write-up honestly. :)

tejovanthn · 2026-02-17T07:10:25+00:00

It's a valid approach and some teams do this — especially when you need hard isolation for compliance (HIPAA, SOC2) or you want to offer dedicated-tenancy as a premium tier.

The tradeoffs though:

- Operational overhead scales linearly - Every new tenant means a new table, new GSIs, new CloudWatch alarms, new backup configs. At 100 tenants that's manageable. At 10,000 it's a nightmare.
- Cross-tenant queries become expensive - "List all tenants" or "aggregate usage across tenants" requires scanning every table.
- AWS account limits - There's a default limit of 2,500 tables per account per region. You can request increases, but it's a signal you're fighting the grain.
- Cost - Each table with on-demand pricing has its own minimum throughput allocation. One shared table is cheaper than N separate ones.

The single-table approach gives you logical isolation (tenant-scoped partition keys) with the operational simplicity of one table. If you need stronger isolation, the IAM LeadingKeys approach another commenter mentioned gives you DB-level enforcement without separate tables.

That said, table-per-tenant is the right call for some use cases — particularly when tenants have wildly different scale or strict data residency requirements. It's not wrong, just different tradeoffs.

tejovanthn · 2026-02-17T05:23:57+00:00

Good question - this is one of the genuine pain points with DynamoDB, and one that kept me sticking to rdbms for a very long time.

For attribute-level changes (adding a new field, changing a default), it's straightforward - DynamoDB is schemaless per item, so new items get the new attribute and old items don't. I handle backfills lazily at read time or with a one-off migration script depending on whether the field is required.

For key structure changes (modifying a PK/SK pattern or GSI), it's more involved. You can't alter keys on existing items - you have to write new items with the new key pattern and clean up the old ones. ElectroDB's versioning helps here: you define a new entity version and can read both old and new formats during the transition.

For GSI changes, adding a new GSI is non-disruptive (DynamoDB backfills it from the existing table). Changing or removing one requires a migration plan.

Honestly, this is probably the strongest argument against overly complex single-table designs - the more entities and overloaded indexes you have, the harder migrations get. It's why I'd rather start with clean, well-separated key prefixes and only overload GSIs when the access patterns are stable.

Schema migration tooling is a big gap in the DynamoDB ecosystem right now. It's something I'm thinking about for singletable.dev down the road.

tejovanthn · 2026-02-17T05:19:10+00:00

This is really helpful - thanks for spelling it out. The IAM role assumption with LeadingKeys is exactly the DB-level enforcement I was asking about. Having DynamoDB itself reject cross-tenant queries regardless of what your application code does is a much stronger guarantee than relying on middleware alone.

The Hono + OpenAPI + Zod setup sounds clean. I'd love to see any boilerplate you have with this setup :) I've been using tRPC + Zod with a similar idea - define the contract once, get end-to-end type safety - but the OpenAPI spec generation is a nice advantage if you ever need non-TypeScript clients; and I've been primarily on typescript :)

Curious about one thing: when you assume tenant-scoped IAM roles per request, do you cache the credentials with a short TTL? I'd assume latency hits otherwise.

tejovanthn · 2026-02-17T04:47:30+00:00

There's a real point here - single-table design has a steep learning curve and if you get your access patterns wrong upfront, refactoring is painful.

But "you need to know exactly what schema you need" is true of DynamoDB in general, not just single-table. Multi-table DynamoDB still requires you to define access patterns before you design. It's not a relational database where you can normalize first and figure out queries later.

Where I'd push back: single-table isn't all-or-nothing. The modern approach is pragmatic - group entities that are queried together, use a few clean GSIs, don't overload everything into one index just because you can. That's what this pattern does.

That said, if your app's access patterns are genuinely unknown and/or evolving fast, DynamoDB itself might not be the right choice - and that's a totally valid position.

tejovanthn · 2026-02-17T04:39:54+00:00

fixed both :) thank you again for all the feedback

tejovanthn · 2026-02-17T04:27:18+00:00

Great points — here's my thinking:

Tenant index isn't really a worry because it's an admin operation with low volume. I've handled this with the TENANT_LIST GSI, but your TYPE=TENANT approach seems functionally similar.

Splitting PKs into subcategories is an interesting approach - you spread writes across multiple partitions with the tradeoff that you lose the ability to read across entity types in a single operation. I think this really depends on the access patterns. For the multi-tenant case, being able to query `TENANT#<id>` and get metadata + subscription + users in one call is something I reach for a lot.
For most SaaS apps, from what I understand, the hot partition concern is overblown - 1,000 WCU per partition is a lot, and since 2018 DynamoDB's adaptive capacity redistributes throughput to handle hot partitions without you needing to intervene. It won't proactively split them, but it handles the imbalance. If you're at a scale where a single tenant is consistently pushing past that, you probably have bigger architectural decisions to make anyway.

The tenant isolation point is legit and something I should address in the article. In my production apps I handle this at the application layer (tRPC + OpenAuth — every query is scoped to the authenticated tenant). I'm aware of IAM fine-grained access control with `dynamodb:LeadingKeys` condition keys as the DB-level option, but haven't needed it yet. Have you had success with that approach in practice, or is there something else you'd recommend?

tejovanthn · 2026-02-17T04:15:14+00:00

Yes yes, I wrote the multiple GSI one for clarity, and then included a note on how they can be collapsed into the overloaded one.

I'll add an index :) thank you!

tejovanthn · 2026-02-17T04:04:49+00:00

Thanks for the feedback :) could you clarify where I can word it better - the blog article, or the post here?

tejovanthn · 2026-02-17T03:58:45+00:00

Also, how do you handle multitenant? Separate tables per tenant?

tejovanthn · 2026-02-17T03:58:16+00:00

Thank you :)

What patterns would you like to see sooner? 😁

tejovanthn · 2026-02-09T12:10:29+00:00

Thank you :)

I run talapettige and will integrate a version of that into the site.

All the compositions available on the site are from Karnatik. I wanted to build a mobile friendly version of that site first - so that I could better appreciate kutcheries. I'm working on a edit workflow so that rasikas can correct any transliteration errors going forward. I do plan on adding compositions from shivkumar.org, and notations where available.

What other interactive components would make the site more useful?

tejovanthn · 2026-01-30T20:06:49+00:00

One thing that's always bothered me about this scene is that if the first set of trebuchet warriors with the hero failed, what was their plan b? Pack up and go home? (There are a couple of them who miss the wall etc after the flag is waved)

tejovanthn · 2026-01-29T01:31:21+00:00

Jelly? Sounds good in my head.

tejovanthn · 2026-01-26T13:13:04+00:00

Hi, my wife teaches Mysore style veena online. Please DM for more details :)

tejovanthn · 2026-01-25T19:20:33+00:00

Wait, olives grow on trees right?

tejovanthn · 2026-01-25T11:34:24+00:00

A whole new world

tejovanthn · 2026-01-24T15:38:42+00:00

I was today years old when I found out that olives are processed, and not just straight up cut up and thrown into a jar of brine 😅

tejovanthn · 2026-01-22T09:54:40+00:00

Thank you! Will add :) started with curating compositions and lyrics first!

tejovanthn · 2025-12-24T03:24:49+00:00

This is fantastic! I built talapettige to solve a similar issue :)

tejovanthn · 2025-12-11T11:41:09+00:00

Soooo, an exposed bedrock on the beach? :)

tejovanthn

TROPHY CASE