Everything Glacro stores lives in one table. Users, projects, deployments, credit transactions, invoices, audit entries — one table, one set of keys.
The key design
PK = USER#<userId>
SK = PROFILE
PROJECT#<projectId>
DEPLOY#<deployId>
TX#<timestamp>
INVOICE#<invoiceId>Every record belonging to one account shares a partition key. Loading a dashboard is a single query on USER#<id> that returns the profile, the projects and the recent deployments together, rather than three round trips to three tables that then have to be stitched back together in application code.
What it costs
Queries that cut across users — every project on the platform, every deployment today — do not fit the partition and need a secondary index. Those are almost entirely administrative, which makes the trade a comfortable one: the common path is fast and cheap, the rare path is a little awkward.
Access goes through helpers
Routes never touch the storage driver directly. A small set of helpers — getItem, putItem, updateItem, queryByPK, queryByGSI — is the only way in. That is what makes the key convention above enforceable rather than aspirational.