Why this site uses one DynamoDB table for everything

This site stores every kind of content in one DynamoDB table: the site config, every Notes post, every bookmark, every page block. Not one table per content type.

DynamoDB rewards this. A single table with a well-chosen partition key and sort key handles very different item shapes just fine, as long as the access patterns are known ahead of time. I query by a prefix on the sort key: POST#, BOOKMARK#, PAGE#. That replaces joining across tables, since DynamoDB has no real join.

One table also means one DynamoDB Stream. Every change to any content, of any type, triggers the same rebuild function. I did not have to wire up a separate trigger per content type.

The tradeoff: a single table's items are less self-documenting than a table per type. I lean on Terms sections in this project's own specs to keep that readable.

For a site this size, one table is simpler to reason about, cheaper to run, and fast enough that I never think about performance.