That's unbelievable! As in "I did not believe it". I mean it's nominally true, but only because this table has almost nothing in it, so a second index on random uuid is a visible cost. If this was actual table in actual software it would hold few other indexes and many fields and uuid+rowid vs int primary key would be a rounding error.
I never wished, gee, why didn't I use integer key. But so many times I wished I used uuid because eventually your data rows are going to need to have identity that is not local to this specific database instance.
Comments
It's " WITHOUT ROWID" problem.
Why would you force database to order rows on the drive according to random id?
If you had read the article, you'd have seen that UUIDv4 with Rowid was slightly slower than UUIDv7
That's unbelievable! As in "I did not believe it". I mean it's nominally true, but only because this table has almost nothing in it, so a second index on random uuid is a visible cost. If this was actual table in actual software it would hold few other indexes and many fields and uuid+rowid vs int primary key would be a rounding error.
I never wished, gee, why didn't I use integer key. But so many times I wished I used uuid because eventually your data rows are going to need to have identity that is not local to this specific database instance.