collaboration
Shared Config Document
One item per document, and what happens as it approaches 400 KB.
A settings document that grows. DynamoDB caps an item at 400 KB, and every write and read is charged on the whole item however little of it changed - so a config that started as one tidy row becomes an expensive one, and the fix is to stop treating the document as the unit.
The model
ConfigSection
One section of a document, rather than the document as a whole.
- pk
- DOC#<docId>
- sk
- SECTION#<sectionId>
Attributes: settings (S), approxBytes (N), editedBy (S), editedAt (N)
Access patterns
- QueryRead a whole document
Every section of one document, reassembled by the caller.
- UpdateItemUpdate one section
SET the attributes that changed, in the section that changed.
- GetItemRead one section
A single section, when that is all the caller needs.
Design notes
400 KB is a wall, not a guidelinewhy
An item cannot exceed 400 KB, and there is no warning as it approaches: the write that crosses the line is simply rejected. A document stored as one item works perfectly until the day someone adds a section, and then it stops. The tax-rules section here is 173 KB on its own - as part of a single billing document it would already be most of the budget.
You are charged for the item, not the changewhy
A write costs capacity for the whole item, so updating one flag in a 300 KB document is charged as a 300 KB write. Splitting the document by section means a change to routing pays for routing. That is where the saving is, and it is far larger than anything gained by tuning the update expression.
SET the attribute, do not rewrite the itemtrade-off
UpdateItem with SET changes named attributes in place; PutItem replaces the whole item. Reading a document, editing one field in the application and putting it back is the pattern that both costs the most and loses concurrent edits, and it is the one most people write first because it is what an ORM does.
The cost of splitting is reassemblytrade-off
One item is one read. Five sections are still one Query, but the caller now stitches them together and has to cope with a section that is missing. Split too far and a document becomes a hundred rows nobody can render without all of them - the section boundary should follow what is edited together, not what is structurally tidy.
Guarding a section is a design here, not a live demonstrationtrade-off
Concurrent edits to the same section still need a version guard - the mechanism the Change & Audit Log model covers - and the resolver does not emit writes as runnable, so this page reads the sections rather than editing one.
Every section of one document, reassembled by the caller.
Run an operation to see the raw engine response.
The in-browser engine is a preview build. Transactions, vector search, streams, tags and TTL are among the operations it doesn't implement yet.