[leourbina]

UUIDs are very wasteful [1]. For most use cases you can replace them with much shorter strings and still have very low chances of collisions [2]

[1] https://henvic.dev/posts/uuid/

[2] https://alex7kom.github.io/nano-nanoid-cc/

[cogman10]

Call me crazy, but I'm simply splitting my UUID into the higher and lower bits and indexing off that.

IE

    CREATE TABLE foo(
        id_ms    UNSIGNED BIG INT NOT NULL,
        id_ls    UNSIGNED BIG INT NOT NULL,
        PRIMARY KEY (id_ms, id_ls)
    ) WITHOUT ROWID;

That works well with UUIDv7 and is just storing 128bits rather than a full string. In most languages it's pretty trivial to turn 2 longs into a UUID and vice versa.

[diroussel]

Is there any advantage to this approach over Postgres native uuid support which should store the same number of bits?

[cogman10]

No. This approach is strictly for DBS like sqlite without uuid or 128bit integer support.

[PittleyDunkin]

Sure, at cost of increased complexity of access. Sometimes the waste is worth the simplicity.

[dymk]

Sounds complex, just use a UUID. If that’s the dominating factor for storage, then you have a different problem to solve.