Nikolay Samokhvalov
Founder of Postgres.ai, working on tools for safe schema changes and query optimization in Postgres.
“I like Aurora because they charge you for IO, and your work on query performance optimization can be measured in dollars. … If it affects this particular index, UUID version 4 will cost you roughly 10 times more than UUID version 7 in terms of IO costs on Aurora. It's not a measurement, it's prediction.”
Postgres FM · Hands-On Engineering Podcasts · October 2026
Context
The hosts had just found that random UUIDs slow inserts once an index no longer fits in memory. Samokhvalov estimates what that means for the bill on Aurora, which charges per I/O, and is careful to call it an estimate rather than a benchmark result.
Transcript
…say, like, oh, like with UID version 4, you write like 10% more wall. It's hard to say because it will be purely synthetic. And in real systems, a lot of things are writing to wall, including autovacuum, right? So, but definitely with UD version 4, it's somewhat bigger in terms of wall rates. And
…challenge is when the checkpoint comes, so it's not just the number of rows you write. It's the number of rows and the number of leaf pages they fit into and the frequency of checkpoints. Those three things are working into you. And it makes up, I understand, about half of the loss of performance.
Yeah. So a few days ago, when we still had iterations for Forge running, remember we discussed that you mentioned, I mentioned Aurora and you also mentioned that I don't remember exact question, but you pointed to some ideas that Aurora doesn't have checkpoints. And maybe there is no such benefit of having UID version 7 on Aurora because it doesn't have like how wall is organized, right? Like if there are no full page write is off on Avarora. So there's no this effect of touching the whole page and the need to compress it. By the way, For non-Aurora, we should have compression on. LZ4, ZSTD, this is probably another Forge experiment, right? But we compress it. And on Avarora, this is not needed. And I was like, oh, yeah, like, unfortunately, yeah, because I like Aurora because they charge you for IO, and your work on performance on query performance optimization is exactly like can be measured in dollars. This is good. So I asked Forge to the next round to explore that. Well, not with Aurora, just like understanding what to expect. And we have numbers. Numbers are impressive. So numbers…
And to be clear, when we first did the ULID and UUID v7 work, one of the people who ran into this problem, it was a cost issue with Amazon. And that's what caused them to look into the problem. So it was at the brand. It was Aurora. Yeah. So they were using Aurora and it was a massive increase…
Yeah. Yeah, yeah. So inserts, like there is degradation at inserts rate, but also in some systems, you start paying for additional I.O. Yeah. So should we say that this is a kind of performance cleave? It's not like acute cleave, but you know, like in real world, not all cliffs are like this.…
of like a performance hill, but let's be honest. When do we care? And I'm a hot sauce advocate from years ago. And their answer was always the right answer late is the wrong answer. And I kind of like that. And they said, if speed's important to you, timing must be built into your system. So part…
More from Postgres FM
