storage
Folder Tree
A file hierarchy encoded in the sort key, so a subtree is one read.
There is no tree type in DynamoDB, and no need for one. Writing the full path into the sort key makes the hierarchy an ordering: everything under a folder shares its prefix, so one read returns a whole branch and an exact key returns a single file.
The model
Node
A file or folder, identified by its full path.
- pk
- DRIVE#<driveId>
- sk
- PATH#<fullPath>
Attributes: kind (S), sizeBytes (N), owner (S)
Access patterns
- QueryList everything under a folder
Every node whose path starts with the folder's, at any depth.
- GetItemFetch one node by path
A single file or folder, by its exact path.
Design notes
The sort order is the treewhy
Nothing stores a parent pointer, and nothing walks one. Sorting paths as strings gathers every descendant of a folder into one contiguous run, in depth-first order, so a prefix read returns a branch without any traversal. Look at the sort-key column: the shape you are reading is the folder structure, produced by ordering alone.
Mind the trailing slashtrade-off
begins_with(SK, "PATH#/docs") also returns /docs-archive and everything in it, because that is genuinely a string starting with those characters. Worse, "-" sorts before "/", so in the table /docs-archive lands between /docs and /docs' own files - the parent is not adjacent to its children. The fix is one character: prefix with "PATH#/docs/" and the run is exactly the subtree. This is the bug the pattern invites, so the drive here is seeded to show it rather than to hide it.
One read for a branch, at any depthwhy
begins_with(SK, "PATH#/docs/") returns the whole subtree in a single Query, however deep it goes. The alternative - a parent-id column and a query per level - costs one round trip per directory, which is the classic adjacency-list problem this key design sidesteps entirely.
The console reads the whole drivetrade-off
The preview resolves only the partition half of a key condition, so the Query returns every node on the drive rather than one branch. The ordering is real either way, and it is what makes the narrower read possible.
What a rename coststrade-off
The path is the key, so moving /docs to /documents rewrites the key of every descendant - there is no cheap rename. Systems that need one store an immutable node id as the key and keep the path as a secondary lookup, paying on read instead of on write. Which way round to be wrong is the actual design decision here.
Taught in the course
- One query, a whole collection - Items that share a partition key are read together in one Query.
- One key, every level - A path in the sort key lets one begins_with read any level of a hierarchy.
Every node whose path starts with the folder's, at any depth.
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.