4 ms·

I'm probably at least partially wrong about everything.. It's true that PostgreSQL uses a write-ahead log, but it's still going to do that seek when it checkpo

by paul 20y ago

I'm probably at least partially wrong about everything.. It's true that PostgreSQL uses a write-ahead log, but it's still going to do that seek when it checkpoints, correct? I don't think that it will be able to sustain high transaction rates (100,000 tps for small transactions should be very doable). If you find that this isn't true and that someone has demonstrated these rates, let me know -- it would certainly be good news.

brlewis 20y ago
Yes, it will still do that seek when it checkpoints, but I seriously doubt it will do one seek pert transaction at that checkpoint. Still, I doubt 100,000 tps can be achieved with PostgreSQL. As for being wrong, that's one of the privileges you lose with celebrity. Everything you write in your blog is going to be preceded by "The guy who wrote gmail says..." When you say something that looks like it might become a popular misconception, guys like me will jump up and down, scream, and tear at our hair. Or maybe we'll just post terse, cold, unfriendly corrections. We still like you, though. My main issue with your post is the way it comes across as saying databases are overengineering for 99% of web sites, but mainly deals with a performance issue that won't matter for 99% of web sites. I would have no problem if you framed it as high tps vs low tps for certain classes of application, not as simplicity vs overengineering. Using a relational database is a fine default choice for web apps today, just as you expect to have an OS on your server by default.