News for hackers. Stuff that matters.

Ask HN: Primary key based on high-resolution timestamp

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 points | on HN )
Re:Ask HN: Primary key based on high-resolution timestamp by bengunnink on Sunday September 02, 2018 @09:02PM (#17899547)
The only problem is it's guaranteed to fail for any non-trivial workload.
Re:Ask HN: Primary key based on high-resolution timestamp by prmph on Monday September 03, 2018 @05:45AM (#17901538)
OK, so what will you recommend to achieve the requirements?