Postgres FM - MVCC

Episode Date: August 7, 2026

Nik and Michael are joined by Radim Marek to discuss MVCC, including his recent article on how Postgres chose to implement it compared to other systems. Here are some links to things they mentioned: Radim Marek https://postgres.fm/people/radim-marekBoringSQL https://boringsql.comPostgreSQL's MVCC is bad. So is everyone else's (blog post by Radim) https://boringsql.com/posts/mvcc-bad-bad/PostgreSQL MVCC documentation https://www.postgresql.org/docs/current/mvcc-intro.htmlPostgreSQL Storage Internals series by Radim https://boringsql.com/guides/postgresql-storage-internals/PgQue https://github.com/NikolayS/pgqueThe next ten years of Postgres (talk slides by Álvaro Herrera) https://www.postgresql.eu/events/pgconfde2026/sessions/session/7744/slides/866/edb-keynote-pgconfde-2026.pdfEpisode on RegreSQL https://postgres.fm/episodes/regresqlDryRun MCP https://github.com/boringsql/dryrun~~~What did you like or not like? What should we discuss next time? Let us know via a YouTube comment, on social media, or by commenting on our Google doc!~~~Postgres FM is produced by:Michael Christofides, founder of pgMustardNikolay Samokhvalov, founder of Postgres.aiWith credit to:Jessie Draws for the elephant artwork

Hello, hello. This is PostGosafam. My name is Nick. PostG.I. As usual, my co-host is Michael. P.G. Mastered. Hi, Michael. Hi, Nick. And today we talk about fundamental topic. And we have a returning guest, Radim, from Boring SQL. Hello, Radim. Thank you for coming again. Hello, guys. Hello, Nick. Hello, Michael. Hey, good to have you. I remember we had very interesting discussion and you obviously have interesting. points of view. So this topic, you recently published an article and it was broadly discussed in community on Hacker News everywhere. Let's start somewhere. What caused writing this material? Okay, that's a very good question because I'm not sure if you know it, but I published a series about Postgres internals. And that was a death on arrival. I think there is a audience that reads it, but the real CD back I'm getting is actually during the conferences.

So I think I've decided to write this article during the PG data in Chicago because I'm actually doing the visualizing Postgres internal series. And this is where most of the interesting ideas and interesting question happens. And many questions because people on those conferences are Oracle practitioners, now switching to Postgres, even if they, some of them want. Some of them are not so keen, and they ask very uncomfortable questions. Very uncomfortable in a way why it's built this way. And then I'm also working with other database systems.

I'm not actually like Oracle DBA, but I work a lot of with SQL server, Informics. I did a lot of things. So people who I deal with, they ask me the same questions, why it happened. And the final straw was a friend of my who went to some unrelated database event, and he was just sending me slides how non-Posgress companies are blaming Postgres for MVCC. And I was like, there's no response. So my goal was actually write a piece that will say there is nobody to blame. And I hope that message actually got across.

I was actually surprised about the reception. That's the other thing. It says the Postgres MBCC is bad, but the goal wasn't to say it's the worst. goal will say this is a very difficult topic that nobody has a universal answer because it all depends on your flow and those are the examples how can it be done so actually the question is because to both of you you have experience with postgres so how did that article actually how did you read it that's actually something that I'm curious about I can go first for me I really liked the framing.

I think I mostly ignore titles because I know titles often have to get people to read it in the first place. So I didn't feel negatively about the title, NVCC is bad. I was more focused on, oh, this is really interesting. He's going to actually compare it to other systems. And I don't think anyone's done that at least well or in detail for a long time. and I found it really interesting to think through how are they? You listed four big kind of architectural decisions and listed how several database systems had made different trade-offs

or chosen different strategies on each of those four axes. I thought that was the clearest way I've seen it explained. I didn't agree with every one of your conclusions on what's good and what's bad and what should change, but I did agree with the premise that they're a trade-offs. the database performance and correctness and things, different systems have chosen different tradeoffs, even when their goals are largely seen to be the same. If you think about the goals of Oracle, SQL, SQL server, Postgres, it's not like they're targeting fundamentally different

workloads. It's not OLAP versus OLTPs, largely OLTP systems that have much the same requirement. So I found it really interesting how different some of those architectural choices were. And I think I knew more about the failure modes in Postgres than I did in all the other systems. So I found it really interesting learning about some of the others. Yeah. So in my case, I think you're touching the topic where people have pain, true pain. And it's like we have the deboss recently and also the topic of implementing cues in post-gast. It's also like painful. And. But still, these topics, they flame huge discussions because there is a real pain people experience.

Right. And first of all, I liked the depth and visualization piece. Obviously, you use the AI for it. This is great. I like it a lot. And comparing to others, I think the main thing which is hanging in the air is that Bosgus needs multiple different tangents. and this is a demand for it.

Because this approach that we have right now, the only approach, it has issues in some work clothes, and it's inevitable to hit those issues, right? You just said it in some workloads. We can't be comparing apples and oranges. And I think actually you summarise the goal that I had. I wanted only to point out, there is no free lunch.

You have to know what you... And this is what I'm doing with a boring SQL. You need to know what you are optimizing for. And actually, Nick, your Q implementation is one that actually started a discussion because now I have to admit I was in a... I don't mind Q's in Postgres.

I work with the dam, but you did actually the turnover. You changed the bloat situations into a something... Just in case, it was not me. I just repackaged Skype. 20 year old implementation, I just repackaged it so you can use it everywhere. It's a very old thing. Just modernized, that's it.

So it's not my idea. I also think calling it a queue is a little bit misleading. We talked about this a while ago, but I think it's important because I think actual cues do need updating and things. And this is a screen that doesn't need. I'm ready. If Brandur is okay and all maintainers of river are okay, I'm ready to swap names because this thing is actually a stream of events. It's more like a river than a queue. So what's swap names? But I think we just got right into middle of the discussion because just realizing the difference between Q and stream,

you need to be able to make that distinction because otherwise you will choose the bad design and you will never know what hit you. at, I'm using this analogy 3 a.m. in the morning, you will get a page and you don't know what it is. So for me, this was the case. And this is why I'm doing the Postgres internals, not because I would believe Postgres is the best in everything. I just believe for a lot of scenarios, postgres is a good choice. And more you know about the internals and the tradeoffs, the better design you can do. And that's why you have to compare the different post-mortems why Post-Mortems why Postgres didn't work for people. And you can evaluate, you can understand

what are the kind of edge cases, why it doesn't work. There are other edge cases where different database systems wouldn't work for the same scenarios. I think the cues is a shared topic. It wasn't an article, but what I actually did, as part of the writing, I did research how different systems work with the cues.

And I actually found it's a surprising topic because all of them have a support to make this happen. So this is one of the things I didn't expect. We see it from Postgres because we are using it, we are interested to make it better, because I don't live in an Oracle ecosystem, but they have commercial product that effectively does the same. Microsoft SQL server has a optimization for it. So Q is a pattern that actually causes issues and they all have to work with it in one or another way. Nice. On that note, I think you laid it out really nice in the article with these four key areas. I wondered if you wanted to lay out kind of what,

maybe briefly, what is it, what's MVCC and why are these four decisions quite important? Okay, so what I'm trying to, during my sessions, I'm trying to make people about that as long as you have a one consumer or producer and that's all you have, life is easy. Effectively, you do everything. If you have a short transaction, And there is nothing, and you can pretty much pick any engine you want. When you introduce concurrency, this is where you start having issues, because concurrency will introduce this element of doubt, let's call it, because not everything might end up as you're expecting, as transaction time will increase. You will be looking at the different versions of the data, and the longer you have and the bigger scale you have, the more problems you have. And actually it was something, I think you Michael said it when you were reviewing your perception of the article, and you mentioned this.

If we would live in a strictly OLTP world, this wouldn't be such a big issue. But this is the thing where people are actually mixing OLTP and OLTP, and they introduce the variables that actually affects all this. So you can have an extremely scalable OLTP system up until somebody said, I want a report. Sure, there are ways how to work around this one, but this is not what everybody will do, because first it's the one report. So they will say, okay, we'll use the same database, and suddenly you have a query that runs for 30 minutes, two hours. Every Sunday you will lock your, let's say, transaction horizon for hours.

And that will cause some of us. So for me, the fundamental situation is to make people aware that database, are there to build for thousands of transactions per second. And in order to support this, there are tradeaus. And I wouldn't call, you know, I'm not there to judge the systems. I think it would be actually silly to judge a four, maybe five decades of research and different database lineage. I think the database lineage also plays the role.

So I'm not going to judge it. I'm more like, let's see how different systems work with it. And especially painful part is when something goes wrong, what is the recovery mode? So that's why I had to do the four charges. I know I was receiving a lot of blame photos, four charges, at least how they are named, because the original versions, and I wrote it somewhere, was like Guy Ritchie's style of storytelling. Because, yeah, I'm not sure if you are Guy Ritchie fans. I'm not a, like a storyteller, but I love his kind of how to uncover things.

So for me, the original version actually had four different, how to put it, not scenes, but like setups. And that was actually describing how it is. And then you changed it? Yes, I changed it. Why? This is a whole separate discussion because I'm a non-English speaker for me. Even though I love to read, I can't write the way I would love to write in English. spent like a decade, maybe more, getting editors than learning how to do certain type of writing.

Now, LLMs, they did completely opposite, they send it in another direction. So if you go through the subtitles, I try to experiment with it, but it's also a very touching factor for some people. If you actually go through the article, you will see how I start learning, how to structure, how to keep the idea flowing, and so on. It's a lot of work for me. And this article hit every single point. I'm actually happy for it. I'm happy to admit. It's part of my boring SQL kind of marketing, semi-marketing.

But this one was difficult because I think there were some hateful emails that arrived. Even like saying, how can I, they doubt that I work with databases. Effectively, they thought it's a slop. So that was actually, it was painful at the time, but it served the purpose. So I'm actually happy for it. So those emails are against Postgreaves or against Articles or what? Against everything. I receive hate from MySQL people.

I receive hate from people that I haven't written a single line in that article. I received hate that I think there was one comment somewhere that I can't know more than one or two database systems, which is irony because I do work with a lot of database system. So for me, this was I knew what I'm doing. when I published the article, but it was the first time I faced this community response that was very toxic. This is true success, first of all, if you receive such emails, it's good, it's good. But also community, there's no single community in open source. There are many bubbles and so on.

But I have to say, I did not receive a single negative feedback from Postgres community. So people, most people know me. So I think it starts, a lot of people were able to, that's why I ask you, what was your perception. Yeah, let me play negative feedback producer role. First of all, I cannot agree with you like we shouldn't judge. We should judge. Fresh look and I was smiling when you talk about judging because literally I have right now set up with Claude and I say, offload, long-running, coding tasks to codex to save on cloud capacity, but don't

off-load judging, judging on cloud. So I think judging is fine. It's like a scientific approach. You should doubt everything, always, right, and check. And why, like, why, when I realized how PostGus and VCCC, like, it was many years ago, I realized, it's like someone designed the system thinking the rollbacks will happen more often. Rollback optimistic and commit a pessimistic approach because

you write a new location not to old one. It means that if rollback happens, then data will be in the same position which is good for like nothing moves. For example if we used cluster command

and our doubles are in specific order, we which is very good for performance. We will be happy if more all backs happen than commits. Because commits move our tuples unless it's hot update. Right? And this is weird. I realized that, well, this is weird. Isn't it be better to put tuple it right there

and move old tappel somewhere else? Maintaining the layout, right? But I will stop you actually because this is us discussing a, what they are, it is, 2026 systems and for last 10 years, we live in a high transactional times, but

this is the reason why, when I start thinking about this one, when I first came across databases, they were connected to a Windows or some sort of fed client, where literally when you open a form, your transaction

started, and you did the work. So, I think this is the fundamental difference, because this So I said the lineage and actually time is what makes difference because right now I do agree with you. We have database systems which have let's say baseline 5,000 QPS rollbacks unless you're doing maintenance or there's an error or 2xA happens rarely. But at the times when I started it was like, not CRMs, ERPs, economic systems and literally people where individual users were holding transactions for a long time. and when they did something wrong, it came to some sort of bad scenario. Okay, I started with databases 25 years ago.

And it was HDDs, no SSDs, right? And physical layout of tuples makes a lot of sense, especially if it's rotating disk, which is sequentially reading something. If you start moving your tuples with your updates all the time, system degrades. It was known long ago, long ago, right? But nevertheless,

this approach was chosen. I just think it's a mistake. Simple mistake. People just didn't think, didn't compare pros and columns of, like, let's just go this. And we know Postgre started how it was started. It was started.

It's a search project, right? And let's just go this way. And now everyone is suffering. That's a simple position, right? I agree with you, Nick, and I think Radeem agrees as well in terms of right now, in most systems we look at, in a healthy state, it makes tons of sense to optimize for commits over rollbacks. But I hadn't considered, before reading Radeem's article, the other side effects of that design,

like the MySQL DBAs or Oracle DBAs that have a runaway update query, updating a lot of rows, maybe it's already gone for an hour and then they need to cancel it because it's causing issues we've all had to cancel long-running queries that are causing issues and then it takes just as long to cancel or it takes another hour to cancel

that is just an issue we don't have in post-square. So that's a really interesting difference that whilst rollbacks might be rare when they're important, they can be very important. So that was a really interesting trade-off that I hadn't thought about before. This is exactly what I wanted to discuss.

Okay. But still, yeah, still, I wish Tapples wouldn't be moved by updates all the time. It's just a lot of headache all the time. This is why we talk about partitioning, attempt to just to contain them to smaller places and so on. Partitioning is important and so on. But still, yeah, I understand.

And SQL server also have, I've heard about headaches. They have, which is explained by, design there as well. Yeah. So anyway, okay, I have another thing to criticize your article. You talk about long-running transactions, but somehow you forget about long-running transactions happening on replicas, on standbys, and abandoned logical replication slots, not used to application slot, catalog X-min horizon, or abandoned prepared transactions and so on, right? Is it just things that need to be polished in your article or what? I wouldn't be writing article in that case.

I would be writing book about code always. I already have this. I cannot agree with you because this is exactly what we see with customers. They like the case when you have long running transaction on the same server, it's like it's a simple, the simplest case. But they hit problems when like everyone is playing with logical replication these days too much. Right. We just like actually postgist should have something better in this area.

like it's abandoned slots it's a headache all the time and I'm just proposing mentioning them in one paragraph funnily enough because I do work on I will continue with my Postgres internal series and I spent a lot of around the page what happening on the physical page the next one is the replication the wall how it affects things like this one so you see I'm building the case because I'm not looking at this one from a I think your position it might be different because you are effectively talking about top 1% of the edge cases. What I'm talking more is the articles, not this one, but the internal storage internal articles are for people who don't know it.

Surprisingly, a lot of people, even like a staff engineer and architect level, they usually like that knowledge. So this is my case for building such cases. So I can't actually overhound people. Because if I would stack everything into a one piece, people wouldn't understand. I even have problems, and those are not a hypothetical cases, when I read the feedback of audience during the sessions, you would be surprised how many people might be using a Postgres for a decade,

and they are not aware. They might not understand hot updates. They might not understand changing. I'm not surprised to deal with them all the time. With back-end engineers who, like, we always try to find the language to explain difficult problems in an easier way. So I cannot agree with you about 1% at all. And moreover, I think it's like a few months ago we started with discussion on this very

podcast with Michael that it's misleading to say long-running transactions are harmful. Actually, your article explains it. Repeatable read versus read committed. Read committed shifts in the X-Men Horizon, right? if it's like statement level. While statement lasts, X-Men Horizon is blocked. Statement finished, we switched, shifted, right? So saying, oh, what happened?

You have a lot of blood. Maybe you have long-grinding transactions. We heard about these decades, and I'm trying to say, like, we should just stop saying that. And we should start, we should introduce X-Men Horizon concept to everyone. I know it's like maybe not trivial, but saying long-grinding transaction is, like, is a wrong thing completely. I do understand what are you saying,

but I would still challenging on understanding, because if we said about hot updates, okay, this is Postgres statistic, I'm not very optimistic about actually people understanding the transaction isolation. That's the other thing.

I'm just working with what I have. What I hear is we can have a discussion, and the humble part is I wouldn't actually say bad decision back then. I think decisions was that were made and we paying tax of it. We can optimize it by understanding but we need people who don't have full understanding to work much better with it. Because you can design a perfectly working system even if I would accept the premise that the post-gress and VCC is really bad and mistakes were made, you can still work around this one

because I think three of us, we know what are the limits, we would design it in that way, and this is effectively all the reviews I'm doing are about the same. Like, you can't do this one, do it this way, and then I face the people who have actually, they have no interest in database, and they ask why. So I think the balance is I'm looking at it, I'm not trying to change the world by saying,

I wouldn't even dare to challenge post-gram. and I'm actually, I have a story from the hacker newsletter from Postgres, how sometimes it's very, what's the word, humbling to understand all the decisions that were made over a long period of time. So I'm actually avoiding that area. I think this is the one area where I'm trying to avoid because it might be the same one as other RIVRIES, you know, AI Rewrides. it only needs to be proven over time. I'm not saying Postgres is best.

I think Postgres has a reasonable default and a lot of engineering that went to most of the cases if you are ever how they work. So this is effectively my position. Nice. On the charges that you listed, which do you see affecting people the most or which do you see people getting confused about the most?

I think understanding versioning is there is not a one charge, which would be most problematic. I think it started with versioning. As soon as you have a multiple version of the same data or similar data, people get confused over time, and that's where the problem starts. We are right in the middle of MVCC. Versioning is actually what makes it difficult.

discuss whatever it's because people don't get maybe the full impact of isolation levels. But this is something they have to work with. Specifically to Postgres, that could be one thing that I would love to have improved from the other systems, is indexes. I actually, and I said, I won't criticize Postgres. I don't want this to be like a tech on Postgres, but I don't like, you know, they are pointing to CTIDs. Because index bloat is, if I would say that's 70% of problems I'm dealing with in performance, because index bloat is there. And the other article, again, it's always the articles that are slightly touching the boundaries.

The vacuum is lie. That was another one. And you wouldn't believe how much discussions I find online still months after it was published. and there are trackers mentioning it and only people realizing it. That's why it's slow because they don't even consider there could be a problem with index. So this is where I believe pointing at the primary key or some ID which is fixed on the row is actually better design because then you don't have to do, if you have an over-index table, which is a common issue, you don't have to actually do maintenance of all of them.

And updates are faster. Updates are faster. Exactly. In the spirit of your article, thinking about why don't we do it, there is at least one cost, right? Every read on that index, which could be a lot, right? If you think about systems that have a lot of reads for every right, every single one of them is having to do one more hop, right? Like going to the logical pointer and then to the physical. So there is a cost, but that cost is so low, especially nowadays.

It's one hop extra, and it'll always be one hop extra as far as I understand. So it's a reasonable cost and it's a fixed cost But we're willing to pay on every read But there is an additional cost Yes, I think that pretty much nails it for me. It's just as I said I don't judge If I would have a wish list this would be a direction if we would go there I would be happy because it would make a lot of people Understanding systems easier and that it would behave as they expect because as I said it starts with a versioning

So now you see how it's connected if you pass the storage internals, you can get your head wrapped around the page and how it's moved. But when the indexes come, suddenly they don't understand. And then you have to start understanding why there is a gap and so on. And then it goes to the hot update. So certain problems can be mitigated. And again, this is my personal idea. I actually love that design.

So if there is a one point from that article and from database systems I ever touch, this is the design I prefer most. That makes a lot of sense. Nick, if you had one thing, what would you want? I would want, I would want OREOLIDB to succeed so we could choose storage engines and have a lot of good stuff. This would modernize Postgres a lot.

So I'm rooting for that project a lot. And I keep exercising every piece of Postgres. This is my nature. I cannot stop. So yeah. Just maybe too much of a tangent, but you brought up OREOLODBD-B, Redding, and I wondered if you had thoughts on the table access method

that systems like that would need or a new storage engine would need, do we have enough yet in progress for them to succeed? Because I think, like, Oriola still need patches for their implementation. And I just get the impression it's not ready for a, an extension to do it for sure. But do we know where we're up to there? Okay, I do agree. Let's start with this one.

Table access methods, I think it's an amazing way. One of the things that is worth linking to this article is this post-Grenrenren presentation that was in a BGConv, Germany. And it has an improvement. It mentions a couple things like Zadheap, that's the project on its own. I think that's now stale anyway. but table access methods are listed as a number one improvement that made it. Based on that, I thought I would be clever and I thought I will explore,

but I hit the limits quite fast. It wasn't for anything in production, it was just for experimenting, but I found the limits quite fast. And if I'm able to do that, I think that actually is the feedback, because if a developer of my kind can hit the limits, it's not going to give us or LDB kind of level support we need because there's much more. There are things that are probably not aware.

I think indexes are generally a problem. I think they are not touched at all. That was finding I had because I had some crazy idea about indexes and figure out... What do we not touched? I think there was some limitation. I would have to dig because it's a couple months back. I played with it and I had some issues

finding there was no interface I couldn't find in the table access method that I can use. Okay. Yeah. There are many improvements like de-doplication in 13, 14, or these things. There is an ongoing Google Summer of Code projects. I'm rooting for a lot as well, which is trying to implement merge for B3. This would solve many cases with blood, actually.

Yeah, but this is on the regular. This is like the current implementation of the heap, right? Yeah. Yeah, yeah. Many directions, things are trying to happen, but there are, of course, obstacles. And, yeah, it would not eliminate the problem of X-Men Horizon being blocked, and vacuum cannot delete datapples, but merge in B-3 could make B-3 automatically healing after multiple cycles of vacuuming. So because right now it can only split page and grow in size, and that's it. And not necessarily.

empty, if in the middle of it some pages fully empty, it can be removed. Auto vacuum will remove it. But if it has little, at least one link to a couple, this page won't be removed. And for integer 8, for example, a big serial or something, right? Or UID version 7, we always insert on one side, like all the pages, if you delete rows, they hang a lot of empty space. and they cannot reuse

this space cannot be reused this is the interesting piece so re-index concurrently is inevitable also that's great that we have repack concurrently in postgast 19 this is a very big gift I think and we had an episode about that

where in the end of episode I discovered it's going to happen in 19 soon right we didn't know I was surprised that we didn't know it will be brought to core We just talked about PGSQQIZ, right?

So anyway, OREDB is a very big project, right? I wouldn't say I'm rooting for it. I think it's an exciting project. I think that's the word that needs to push database development forward. And yes, I'm very excited to see. I think a little bit of history, how the decision was made, to put new row versions, new tapples to new positions. It was made originally in 80s.

So there is an article, the design of the PostGus storage system from 87, VLDB, by Stonebreaker and others. And the decision was like, if you maybe know that time PostGus had time travel capability. That's what I was about to mention, that logic. because... And look, follow my hands, so to speak. So the trick was, the idea was, let's not have wall.

Nothing to undo, nothing to redo. Let's just keep everything. And then vacuum was born as an archiver. Right. And then it stayed like there until in 1999, Vadim Mikhail said, proposed and implemented, a change to get rid of table level log because there was a table level lock.

So table level lock was removed and the concept of snapshots of data was introduced. And a couple of years later, wall was implemented by Vadim Mijev. So now we have, and then time travel was removed, this capability was removed. Now we have a piece of thing which was designed to not to have wall, right, but we fall. and snapshots and everything. This is very interesting evolution, right? And we have all the rights, and my position is we have all the rights, and many people have all the rights to criticize this state. But also it's obvious that it's extremely hard to implement new approach

in the life rapidly evolving system which has releases every year. And we know also EnterpriseDB attempt that heap. was not succeeded, hasn't succeeded, right, in this, to implement a new storage. Yeah, but anyway, I think people have all the rights to desire the choice inside postgues, because actually the people who desire the choice, they want to stay inside postgues, usually, right? They like everything else around, right? Yeah, exactly. And I'm actually happy that you mentioned it, because for me, this is the lineage.

database lineage, where we came from, how we got to that decision. That's why I mentioned those systems like different transaction profiles and everything. Because for me, those are decisions that were made over time. I think I mentioned it. I'm not sure where. I'm mentioning quite often. For me, the painful scenario, because my official title when I'm presenting myself on conferences, is skeptic-turned-believer.

I was the guy who destroyed databases. because even Postgres and Unix said it spinning disk you need to shut down something and it writes and writes you hear that loud noise or spinning disk writing something or you're hitting that query killing doing a rollback and it needs to write a lot of data and funny thing is actually the change is a difficult one so people from the SQL server they actually this is not something I'm no but they actually faced the same problem because they had a problem with them DB I think it's called so it's run out of this space because there was simply nothing so they spent

actually the Microsoft did an investment on ADR if I'm mentioning it correctly so that was that was 2019 and it's actually a accelerated database recovery and what they did behind the scene is they also introduced something like a Bay Q because what they needed to do is move where the data for the log are stored, so it's now on the table space, it's not a different one, so we can go back to a table space discussion behind the different databases. Even today in Postgres and in Oracle, I'm not sure about other systems, you can work and optimize a lot by table spaces.

But Microsoft had to do actually a lot of engineering work to get this one. So that's why I'm saying I'm disagreeing and agreeing you at the same time. it's extremely difficult to do so. I can't even imagine how all the core commuters find agreement on doing things like this one. Postgres is a decentralized project and I still don't know how they do it. Like how they find that agreement, that's one thing. But the point I'm trying to make is, you just said it, we've been through a series of designs and a lot of difficult choices we made,

but that's also case for the other systems. So everybody is trying to fight. And if there was one goal of that article was saying, literally, there's no free lunch. You have to understand all the moving systems. I'm now playing with the M-Loc on Oracle. It's also not a free lunch because you move a load to producer.

So you effectively hit the application with that cost. We can go, another article I'm still working on, is views, materialized views and all this. And there is always so many different aspects that needs to be considered. And this is what I'm not trying to judge. So if you ever read something that I'm judging, and I don't mean judging the AI output, for me it's always the humbling history.

So that's why I agree and disagree with you at the same time. So I believe Postgres has a chance to improve. it will improve. Projects will improve. I actually love how Postgres is able to not be ready for one change year one, and then year plus four, five, you suddenly have the technology available, and still the design decisions that were made long time ago, they still apply, more or less. So I actually trying to find us a balance. I actually, that's why I said I wouldn't ever criticize that decisions were made,

and that's a story for me. So I agree there's no free lunch, but also I want variety of lunches. I do agree. I would just add, because the previous episode I was on this podcast was Regress QL and that for me, I'm still working on it, by the way. Just the learnings I'm getting to understand,

sometimes it happens in the hacker newsletter. I just, the amount of decision and the knowledge that goes through commuters' hands is actually amazing wealth of knowledge that I've learned not to, I'm questioning, but they usually convince me, they know why it was made, and I need to respect a decision.

So this is effectively my background. What are your next plans in this direction, like you said? You said you are working on internals, you plan to visualize more, right? Try to present internals of Postgres in a new way and so on and what's the plan overall in this area? Overall plan is expanding the understanding because I think people still need a simple way how to understand.

I actually love the SimCity kind of. But for me, this is like different approach. So why I like it, I don't imagine showing this one to a random ATMD of my sessions. They would just... Simple already, yeah. It's not simple. It's not simple.

That's the thing. I still try to make things boring and reliable. AI is playing a big role, so I do a lot of work on that harness level. So, for example, one thing, just to mention this one, outside the commercial things, the regress QL I'm trying to, and I'm actively testing for now a couple months, a regression harness for Postgres itself. It found one buck before it was merged. That's one of the things. When you get to commit fast level of reviews, I'm running that suite, but I'm usually finding false positives.

So this is where I'm still working in. I'm still very deep into the statistics ecosystem and how to enrich it. I have some new ideas how to make the whole regression testing faster. But effectively for me, I found out that this is such a difficult topic we can discuss. but to get adoption even for open source tool is actually very difficult. So I actually took a detour and I'm working on, I have an MCP called Dry Run, which finds with other MCPs, which is not a point. The full circle is actually to make people get the setup.

They can actually do the regression testing and actually get LLMs producing code that is judged, not by LLMs, but having more predictable output. But this is a personal project of mine. Otherwise, the education still stays. So I'm expanding. And I'm preparing... I think I have now 11 articles in words because I changed my writing model.

Because when I started, I didn't know how to write for a blog. So it was like all energy into a one blog post and then I published something that didn't have a structure and everything. Now I have to, if I have idea, I do some writing, then I leave it, I come back to it, and I'm trying to avoid kind of this structure. So actually, I actually had to redo some parts of website, because now you see like there's the internals guide that actually lists chapters. It looks more like a book, and that's why I said, I know what's the cost of writing ever-expanding articles. believe me I have one article which will go live it's not educational one

and it's already read time about 45 minutes and I can't cut it down so this is actually stuff we are talking about and it's about four months of work which so yeah what I'm working on cool cool okay good that sounds amazing that sounds exciting

I can't promise I'm going to read the 45 minute one but I will definitely try but yeah it's always fun reading what you put out And thanks for fighting the good fight on the education front. So yeah, thanks for coming on as well. Thanks for you for having me again. Have a good week. Bye.

Okay, you too. Bye, guys.