Tejovanth N

I've been building on DynamoDB for a few years, mostly single-table designs. Some schemas went smoothly. Some I've had to rethink across millions of items. The content here comes directly from those - the access patterns I had to figure out, the GSI calls I'd make differently, the key decisions that looked right until they didn't.

Production systems

• rasika.life - a cultural events platform built on single-table DynamoDB. The events entity alone has six GSIs - by creator, status, festival, venue, organiser, and art form. This is what motivated SingleTable.
• rekha.app - built on ElectroDB + single-table DynamoDB.
• rrmstays - Airbnb management system. Another single-table design with booking, availability, and guest management patterns.

All three run ElectroDB on a single DynamoDB table. I've also built proof-of-concept e-commerce, analytics, and SaaS apps on the same stack - that's where most of the messier patterns on this site came from.

Why SingleTable

There's no good tool for designing DynamoDB schemas visually. You're either reasoning about it in your head or finding out in production that the key structure doesn't work. SingleTable is the schema designer I wanted: canvas-based, access-pattern-first, with IaC export. The content site is phase one while the tool is in development.

Writing

I write about code, culture, and building at codeculturecob.com. For DynamoDB-specific content, you're already in the right place.