DynamoDB UUID Generator
Published: September 19th, 2026
DynamoDB will not make an id for you, so every item needs one generated in your own code. Here are the four formats people use as DynamoDB keys, stamped a second apart so you can see which ones sort.
2adca4cd-6701-42e0-be3c-ddfa6e819860
611bd089-4da7-418c-bcd5-7122ae8a7023
0153443a-b09f-4a2e-abf9-7f4417ac0dba01a0b989-a200-741f-8f0b-a9abfae67a58
01a0b989-a5e8-758d-8d6a-6125d07e0338
01a0b989-a9d0-73fc-b82d-a17a2b90c2a701M2WRK8G0K6K8NTF7AGFWPGW9
01M2WRK9F8GMGAYS0SXDJ1RQ1Y
01M2WRKAEGVDNTH72SGQQWB7WK3JXtNWRbB0QLDq8QPActqTjhhf5
3JXtNcFCGxK4FkI2H6LHWsnH8Wv
3JXtNgYKRafZOeYyviRg22LNvwSDynamoDB does not generate ids
There is no auto-increment and no server-side UUID. Every item you write carries a partition key you chose, so the id is generated in your code before the PutItem call. That leaves one decision: which format, and whether it should carry the time.
Does a sequential id hurt a DynamoDB partition key?
No, and this is where advice from other databases misleads people. DynamoDB puts the partition key through an internal hash function and the hash decides which partition stores the item, so items are not held in partition key order. AWS says it plainly: "Note that the items are not stored in sorted order. Each item's location is determined by the hash value of its partition key." A run of UUID v7s, which share a leading timestamp, hashes just as evenly as a run of v4s. What matters for spread is how many distinct partition key values you have and how evenly traffic falls across them, not whether they look sequential.
The sort key is where the choice bites. Within one partition key, DynamoDB stores items "in ascending order by sort key", so a time-ordered id gives you chronological ordering for free: a Query with ScanIndexForward: false returns newest first, and a range on the sort key becomes a range on time. A v4 sort key gives you none of that, and you end up carrying a separate timestamp attribute to sort by.
Which format to use
UUID v4 is random and has no time in it. It is the right default when the id is only ever looked up directly, and it is what most libraries give you without asking.
UUID v7 (RFC 9562) puts a 48-bit millisecond timestamp in the leading bits, then randomness. It is still a UUID, so anything that takes a UUID takes it, and it sorts. This is usually the best choice for a DynamoDB sort key.
ULID encodes the same 48-bit millisecond timestamp plus 80 bits of randomness into 26 characters of Crockford base32, which leaves out I, L, O and U so a transcribed id cannot be misread. Ten characters shorter than a UUID, so ten bytes off every item that carries it.
KSUID is 27 characters and keeps only seconds, so two ids made in the same second sort in an arbitrary order. Fine when your events are spread out, wrong when they are not.
One trade to make deliberately: v7, ULID and KSUID all encode when the item was created, and anyone holding the id can read that back. RFC 9562 calls the embedded timestamp "a very small attack surface". If exposing creation time to whoever sees the id is a problem, v4 is the format that carries nothing.
Whichever you pick, the id is a string attribute like any other, so it counts against the 400 KB item limit and the capacity every read and write consumes. For how the key fits the rest of the table, see DynamoDB keys explained and the schema design tool.