@charl brought up a similar topic a year ago around ULID as a primary key. (https://forum.cockroachlabs.com/t/best-practice-for-uuid-primary-keys/1520)
In there, @david talked about making
UUID instead of type
string, to store into 16 bytes to save space.
xid's are similar to
xid's are stored in 12 bytes, not 16. However, they are not backward compatible with
UUID's, so they’re not a drop in replacement.
Would you recommend a similar path for using
xid's (github.com/rs/xid)? I was planning on using a
bytea to store
xid's as my
PRIMARY KEY, and foreign key’s. Do you see any downsides to this approach, or would it be safer to use as a
STRING albeit with more data storage bloat.
I’ve read the reference in relation to Postgres (github.com/rs/xid/issues/14), but I’m curious the best practice with how CockroachDB is structured.
I know you’ve looked into adding
ULIDs, (github.com/cockroachdb/cockroach/issues/24733) but my vote is for
xid's; solves the same problem in less space and doens’t require a lock when used concurrently (github.com/rs/xid/issues/42).