The UUIDv7 spec actually allows you to use the 12 rand_a bits as a sub-millisecond timestamp, or alternatively I think you’re allowed to use up to all 74 random bits as a monotonic counter if you really want to.
So if you want to you can absolutely order them while still following the standard.
BTW the bit about LSMs in this comment is actually wrong as I eventually found out.
LSMs can benfit from k-sortable ids in a number of ways. For one, when keys are inserted in strict monotonic order there is an optimization which allows the engine to avoid rewriting the SST. This is similar to the optimization you would use when building a Btree from perfectly sorted data.
Also I think inserts in “mostly”-sorted order would still reduce write amp in leveled LSMs.
The point being: there is more nuance to this than you might think, and I clearly did not deeply understand LSMs when I wrote that reply lol. The btree stuff is correct, though, and it is true that LSMs are “less” affected by random keys.
This is a reasonable callout.
In the systems I work with, I try to keep “record identity” and things like business logic relevant dates/times, or sequencing generally, conceptually and structurally separate… even when there’s a high expectation that timing in record creation could also be used to establish business timings or that a business timing could be used as a record ID date component. Yes, I spend extra bytes per record and related processing when I do this, but I find that keeping these distinct concepts separate I have many fewer questions after the fact about things like business relevant/sequencing and the like.
While building business-meaningful sequencing into your record IDs is something you can get away with for a long time (maybe forever even) I’m a veteran of enough corporate merger related data migrations to know some of the tricks we play with surrogate key IDs just to get data sets merged without collisions… and it ain’t always pretty. Yes, UUID should avoid that sort of problem… but you never know what you’ll run into.
Rounding off a late-year cycle of releases that started with SpeckEx and NoNoncense 1.0, Once 1.0 is out! It adds the following:
1.1.0 is out and full of new IDeas!
The highlight is Masked IDs, which provide a middle ground between plaintext and encrypted IDs. IDs are stored as plaintext in the database but encrypted when retrieved by the Ecto type. These can be combined with other functionality like prefixes and time-sortability, and can be stored/rendered in all supported formats (signed, unsigned, hex, hex32, url64 and raw).
Benefits: Masked IDs have the database performance of plaintext IDs (written sequentially to the right of the index), but the application sees encrypted values so they are unpredictable and can’t be enumerated. ORDER BY id and keyset pagination work transparently (cast decrypts input). No database migration is needed for existing IDs.
Trade-offs: Database and application IDs look completely different (operational friction with SQL/BI tools), slight performance cost for encryption/decryption on every read/write, ordering info can leak into the application when using ORDER BY id queries.
Once 2.0 is now available with support for NoNoncense 2.0.
NoNoncense 2.0 introduces supervised machine ID management for distributed nonce generation. It can coordinate IDs through PostgreSQL/MySQL, Redis/Valkey, Kubernetes StatefulSet ordinals, or fixed host identifiers, and stops generation if an acquired lease can no longer be proven safe.
This lets Once users adopt NoNoncense’s new machine ID strategies for reliable ID generation in dynamic deployments. See the NoNoncense 2.0 documentation and migration guide for details on supervised coordination, and the Once documentation for the Ecto integration.