Ask HN: Primary key based on high-resolution timestamp

2 points by prmph ↗ HN
I'm seeking a primary key for my relational database tables that: - Can be generated on the client and has a low chance of collisions - Can support fast (and possibly clustered) indexes well - Will play well with federation, sharding, and migration scenarios - Does not leak data about my system internals when used a public object id

At first, I thought of using an internal auto-increment integer primary key, and a public client-generated GUID surrogate key. But there are issues with this approach [1]

After further thought, I'm thinking a timestamp (with millisecond resolution) primary key will meet all these requirements well.

Are there possible problems with this approach?

[1] https://tomharrisonjr.com/uuid-or-guid-as-primary-keys-be-careful-7b2aa3dcb439

2 comments

[ 2.9 ms ] story [ 17.2 ms ] thread
The only problem is it's guaranteed to fail for any non-trivial workload.
OK, so what will you recommend to achieve the requirements?