Goodbye to sequential integers, hello UUIDv7!

At Buildkite, we've historically stored our data with two keys. We use sequential primary keys for efficient indexing, and UUID secondary keys for external use. The upcoming UUIDv7 standard offers the best of both worlds; its time-ordered UUID primary keys can be utilized for indexing and external use. This blog post will take you on the journey Buildkite took that led to our eventual adoption of

[daruyanagi]

“UUIDv7 is time-ordered, values generated are practically sequential and therefore eliminates the index locality problem”

[yug1224]

sortableなUUID良いな。ULIDがずっとメンテされてなかったからこれ使いたい。

[gettergot]

“. As UUIDv7 is time-ordered, values generated are practically sequential and therefore eliminates the index locality problem.”

[efcl]

(Postgres)順序性がないUUIDv4だとPrimary Keyとして使った場合にインデックスの局所性がないためRead/Write時に負荷が発生しやすい。 そのため、timestampを使って順序性のあるUUIDv7を使うことで時間的局所性が良くなってパフォーマ

[kiririmode]

UUIDv4はそのランダム性ゆえにデータの時間的局所性の課題を解消できなかったが、UUIDv7はプレフィクスがタイムスタンプなので性能が出るようになり主キーとしても扱いやすい

[tmatsuu]

UUIDv7はULIDと同じ発想なんだけどUUIDのフォーマットに準拠してるのがメリットか。ULIDとtimestampのbit数は同じだが、乱数のbit数はUUIDv7が少なめ。とはいえ問題にはならないだろう。

[onk]

これは reasonable。（私は 64bit int の主キーに慣れてるので引き続き Snowflake 系を使い続けそうだが）

[spark7]

「time-ordered UUIDv4」これでもよかった感あるが正式な仕様がある方が良いか。