bddicken

Author here. You're right! I'm fixing now.

I appreciate this feedback, and then you read through it with enough rigor to notice.

Notation is useful. Citations are nice for further reading. But I don't agree more of this makes for a better article!

Author here. Thank you! These visuals are built with js + gsap (https://gsap.com)

Author here. This is good feedback.

The combination of transactions, isolation levels, and MVCC is such a huge undertaking to cover all at once, specially when comparing how it's done across multiple DBs which I attempted here. Always a balance between technical depth, accessibility to people with less experience, and not letting it turn into an hour-long read.

This is changing soon with Neki.

https://www.neki.dev

Love how easy it is to visually correlate schema changes to performance improvements in Insights.

Hi, author of the blog here. Benchmarking can be tricky, but I did my best to make this fair and useful to other DB engineers. Ask me anything!

Thank you!

Thanks for the feedback!

Yeah, I purposefully "simplified" how virtual memory works here so that the focus could be on multitasking and context switching, but agree that isn't totally accurate. I actually had hoped to do a part II on virtual memory, but we'll see if time permits that :)

Author of the article here. Hope you love it, and I'm hanging around to answer any questions.

Still in virtual machines, but ones with local NVMe drives rather than network-attached storage (EBS, Persistent Disk). This means incredible I/O performance.

https://planetscale.com/blog/benchmarking-postgres

It's real Postgres operated by PlanetScale. You get HA by default, the best performance, query insights, etc.

https://planetscale.com/blog/benchmarking-postgres

In the database world, serverless/autoscaling pricing is almost always more expensive for real workloads. The % of workloads where it makes sense is small. Ones where 90% of the time there's little small traffic and 10% of the time the DB sees large traffic spikes. Otherwise, just pay a fixed cost for the hardware you need.

Why? Neki is built by the the engineers who have built, maintain, and operate massive-scale Vitess databases.

The Postgres team incorporating io_uring into PG 18 is a good example of this: https://pganalyze.com/blog/postgres-18-async-io.

This was a great read - thanks!

Hey, Ben here from planetscale. I'm happy to answer any questions about this, or route the appropriate engineer (like the incredible vmg).

Or in this case, to spend far more $$ on io2.

For writes, yes. But what if your workload is 90% reads?

Yeah I think the visuals really add to this one, especially given the time element of explaining latencies.

Interesting! Any errors you can report? Should work in safari but maybe you have something custom going on, or an older version?

Thank you!

For PlanetScale Metal, we use semi-sync replication. The primary need to get an ack from at least one replica before committing.

Thank you! The visuals definitely add something special to this post specifically since time is a big element in explaining latencies.

Technically any drive has a finite IOPS capacity. We have found that no matter how hard we tried, we could not get MySQL to exhaust the max IOPS of the underlying hardware. You hit CPU limits long before hitting IOPS limits. Thus "infinite IOPS."

Whoah, thanks for sharing the paper.

Bartosz Ciechanowski is incredible at this type of stuff. Sam Rose has some great interactive blogs too. Both have had big hits here on HN.

Interesting. Running any chrome extensions that might be messing with things? Alternatively, if you can share any errors you're getting in the console lmk.

Ohhh interesting! Obviously not ideal, but I guess just an extension issue?