[outside1234]

If you don't have a natural primary key (the usual use case for UUIDs in distributed systems such that you can have a unique value) how do you handle that with bigints? Do you just use a random value and hope for no collisions?

[benwilber0]

You use a regular bigint/bigserial for internal table relations and a UUID as an application-level identifier and natural key.

[hellojesus]

Wouldn't you just have an autoincrementing bigint as a surrogate key in your dimension table?

Or you could preload a table of autoincremented bigints and then atomically grab the next value from there where you need a surrogate key like in a distributed system with no natural pk.

[outside1234]

Yes, if you have one database. For a distributed system though with many databases sharing data, I don't see a way around a UUID unless collisions (the random approach) are not costly.

[tbrownaw]

Peel off a few bits at one end, and assign a value per instance.

[hellojesus]

Yes. This is the way so long as you can guarantee you wont grow past the bits.

Otherwise you can still use the pregenerated autoincrements. You just need to check out blocks of values for each node in your distributed system from the central source before you would need them:

N1 requests 100k values, N2 requests 100k values, etc. Then when you've allocated some amount, say 66%, request another chunk. That eay you have time to recover from a central manager going offline before it's critical.

I have no problem with using uuids but there are ways around it if you want to stick with integers.