5mins of Postgres E59: UUIDs vs Serial for Primary Keys - what's the right choice?

preview_player
Показать описание
Today, we talk about deciding whether to use UUIDs vs bigints for your primary key.

*Find the article on our blog here:*

*Learn more about pganalyze:*

*Check out the pganalyze library for eBooks, webinars, and more:*

📑 *What we have discussed in this episode of 5mins of Postgres:*

*UUIDs vs serials for keys - by Christophe Pettus*

*Christophe Pettus on Twitter*

*Identity Crisis: Sequence v. UUID as Primary Key - by Brandur*

*Brandur on Twitter*

*Postgres Hackers thread about UUIDv7*

*5mins of Postgres E58: Handling integer sequence overflow without downtime in Postgres*

*pganalyze newsletter issue of April 2022 about ULIDs*

*5mins of Postgres E10: max_wal_size, Postgres full page writes and UUID vs BIGINT primary keys*

*Effective indexing in Postgres - eBook*
Рекомендации по теме
Комментарии
Автор

You could use a sequential key as primary key and then have a uuid as just a property. That way you can use the index in relations / server side stuff, and the uuid’s with client interactions

luca
Автор

Here in the Netherlands the tax people require that your order numbers (well, the invoice numbers at least)) are consecutive, if you do have gaps then you have to account for the gaps as they see gaps as potential fraud. Random numbers are therefor simply not an option.

One downside to UUID's that have made me shy away from them is that they are impossible to reliably pass form one person to another if you cannot copy/paste them. The length and composition simply make it impossible to reliably transfer more than a handfull, which is really really bad when you have a customer on the phone complaining about a number of orders that need to be fixed *NOW*.

As for distributed systems, al you need is a way to make sure none of the systems generate the same number. A prefix will do that.

vinny
Автор

I am trying ULID, it goes like using ULID and then converting it to UUID. So it can be sequential and yet unique and able to store in the UUID field

stephenljk
Автор

Currently spending the next 6 weekends purging data from a large complex 3nf database with UUID FKs between all of the tables. On an extremely large instance(192G Ram, 48 vCPUs) I'm getting <31 deletes/sec with all the ugly UUID FK lookups.

awksedgreep