pgrust Faster Than Postgres? | Scaling Postgres 426

[00:00:00]I had heard about PG Rust maybe a couple of months ago and I heard someone was rewriting Postgres in Rust and I probably had a little bit of an eye roll with regards to that and I thought it was maybe just a developer being a developer and everything is better in Rust or whatever language you happen to like at the time. But because I'm talking about this as the lead to the show, it might be something to start to pay attention to because it just crossed passing 100% of the Postgres regression tests and you can start it up on your existing Postgres directory. So we'll talk about that this week, but I hope you, your friends, family, and co-workers continue to do well. Our first piece of content is the four horsemen behind thousands of Postgres outages. This is from maliceberg.mme.

[00:00:52]And of course, this is a clickbay title, but these are some of the things he sees and suggests he wants to change or fix in PG Rust. And again, this is a Rust rewrite of Postgres. So, the first thing he addresses is vacuum and transaction ID wraparound. And transaction ID wraparound is a definite concern as your database grows because we're still using 32bit transaction IDs. And I can only assume he's going to be using 64-bit.

[00:01:22]And his intent is to change how rollbacks happen and use an undo log like Oracle does probably to avoid having to vacuum the heap. But both of these are goals. They are not present yet presumably because he has to get the regression tests passing. So he's just trying to match Postgress at this point.

[00:01:41]These are just future looking things as far as I understand it. The next is connection limits and query parallelism.

[00:01:48]And he's basically knocking the Postgres process model. Although he makes some of these statements that I'm like that doesn't happen because he says quote if more things try to connect to Postgres than the connection limit, they won't be able to. That's true. And your database will go down. I've never seen a database go down due to too many connections. The database stops additional people from connecting. But basically he's going to be using a threadbased model. And he says this was architected from day one with it. And he says even though the process model is safer, Russ provides safety guarantees for these threads. So it should be fine. The next item he calls out is bad query plans. Now again with PG plan advice, this is not as relevant too much anymore. But again this is all forward facing that he wants to do with PG Rust is he wants to build an adaptive query planner and that if a query normally takes 10 milliseconds suddenly takes 10 seconds PG Rust would detect the regression check if the plan changed or check if the statistics drifted and make a correction although in theory you could make this enhancement to Postgres today it should be tracking sufficient information to detect plan flips I'm not saying it would be easy but I could see how that feature could be added. Next, he talks about JSON and the fact it does not collect statistics and that's something he wants to do. But again, Postgres could start tracking some sort of statistics for JSON as well. So, this gives you a sense of what he's going for. The next post is PG Rust passes 100% of the Postgres regression tests and that's with Postgres 18.3 and it's discompatible with Postgres. So you can boot from an existing Postgres data directory but of course it's not production ready yet not optimized not compatible with existing Postgres extensions but still this is a significant milestone nonetheless and then the next blog post how PG Rust was built four attempts to rewrite Postgres in Rust with AI. Now, this is a much longer blog post, but it talks about his technique for using AI to do it. And in terms of the TLDDR, after four attempts in dropping $100,000, we succeeded in using Opus to rewrite Postgres and Rust. So, they had four iterations to try and get it and spent $100,000 at the end. But you'll see they've actually added another $100,000 near the end of this blog post. Now, of course, the issue with using AI for building these is, are you going to, I guess, quote unquote, paint yourself into a corner? Is it going to have too much bloat or slop or whatever you want to call the code to be able to move forward? And it's interesting that he says for this first attempt, it got very close to completion, but ended up having fundamental issues that made it unsalvageable, which philosophically any software can be altered and improved. So I think it's a pretty significant statement to call it unsalvageable and they said this attempt was mostly port one feature at a time and he goes into details about that. Uh the second attempt was to basically transpile the postgres code from C to Rust. So basically matching it up line by line with a Postgres code.

[00:05:06]But the problem with doing that it basically generated 5.3 million lines of unsafe rust code. Now what's interesting about this attempt, it completely passed the Postgres test suite and passed 100% of the regression suite and had similar performance to Postgres, but it was even ABI compatible with Postgres, which means the extensions would work as well.

[00:05:29]The problem was when they tried to convert the code into idiomatic Rust, that's where things fell apart and it was taking hours to do this type of conversion. So the idea for the next attempt was to rewrite the generated C to rust code crate by crate because there were approximately a thousand rust crates that was initially output. And he goes through over the skills and some of what he prompted to try and do that. But he had a lot of problems with token usage. And he makes a interesting comment here. Now, I may be a little crazy or maybe very crazy, but I thought if I could complete PG Rust for under $100,000, it would be worth it. Now, the problem is in C the circular dependencies looks to be what might have killed him with this because rust crates forbid the creation of circular dependencies. And then going back to one of the previous iterations being unsalvageable. Here he says, quote, when Fable came out, he said, all right, let me try to get Fable to resolve this. and he says, quote, "Even Fable couldn't recover this version that he's calling PG Rust idiomatic." Quote, "Is there any way to save PG Rust idiomatic? Does it just make sense to start over again?"

[00:06:43]And he had spent a lot on these cla dynamic workflows up to $50,000 at this point. So the fourth attempt he called PG Rust Fabled, but the spoiler was it was not built by Fable because Fable was released and then Anthropic did a rug pull and you could only have Opus. So that's what he did. I kept going with Opus. And he talks about his different skills and how he approached this a little bit differently. and he prioritized implementing seams between the crates and updated his audit skill to give it more things to look for. So he regularly ran this audit skill and was consistently making sure all the seams were wired. But ultimately he got this version PG Rust fabled although written in Opus was able to pass 100% of the Postgres regression suite and using idiomatic rust at the cost of another $50,000. So $100,000 in total. Now then he says okay what's next? He says quote the big issue with PG Rust Fabled is it's really slow eight times slower than Postgres. So they're doing the next version presumably based on this code called PG Rust Fast. And this is crazy to me. So far they've put in $200,000 into PG Rust Fast on top of the $100,000 they put into Rust idiomatic. So it's using a new vectorz executor, a new JIP compiler that cuts the latency of JIP compilation from 50 milliseconds to five microsconds and auler that dynamically adjust the prioritization of queries.

[00:08:20]Now this is still an internal test but he says this altogether the optimizations we've made have made PG Rust fast over 50% faster than Postgres on transactional workloads and about as fast as ClickHouse for analytical ones.

[00:08:37]If this is true that's pretty amazing and they plan on releasing this within the next two weeks. And this blog post was released today as I'm recording this. So, it definitely looks like something to keep an eye on, but what do you think? Feel free to let me know in the comments. Next piece of content, philosophy behind PG hard storage. This is from cyber and postgress.com.

[00:09:02]And again, this is the PG backup tool that cybert keeps on talking about now.

[00:09:07]But basically, they just wanted another alternative in the community. They're not saying you should drop your existing tool, but they were looking for particular feature set and that's why they chose to build their own. And I'm sure the PG backrest issues that had happened earlier prompted them to continue doing it. But some of their focus has been they wanted to make it cloudnative by default. So basically everything can work over a lib pq connection. So it can work with managed postgres as well as running your own bare metal servers. They wanted to use streaming replication as a first class citizen. So no archive command is required. It just uses the replication slot. It's patroni aware from the start.

[00:09:51]So it can follow leader switches with zero gap. So I believe they have customers who are using patroni. So this was a requirement for them. They also are offering dropin compatibility shim.

[00:10:02]So if you're migrating from PG back rest or bar man they give you a path to move to their solution and every feature of the backup is Apache 2.0 0 license. And as a reminder, they are offering five different key management service backends, five different storage backends you could use, as well as some other things we've discussed. Some things it does not have yet, it doesn't have a built-inuler, although you could easily use cron or your ownuler. It doesn't have a web UI. It's all CLI at this point. It doesn't have a snapshot aware fast path yet, but that's on the road map for version 1.1 and it looks like they may support plugins with the tier 2 plug-in registry. So, feel free to check this out if you want to learn more. The next one, architecture behind PG hard storage, the replication protocol. And this goes into more detail about how they're just using a single replication slot and the replication protocol to do all of your backups of the wall and even the base backup. and they list the consequences from that one. Manage Postgres works automatically. You don't need an archive command. You don't need SSH access to the host, etc. Consequence number two, the privilege model is dead simple. You just need to be able to connect to the database with a replication role and be able to read all data and of course execute the relevant functions. uh back pressure is the slot at the replication slot handles that if the agent goes down, it starts accumulating wall until the agent comes back up. Uh fourth consequence, you get dual stream wall essentially for free. So you can set up wall streaming from both the primary and a fast following replica or they're calling the lowest lag replica because it's doing chunk ddups. It's not like you're having to retain everything twice. You can have two or more sources of the wall but only one copy gets ultimately stored. And the fifth consequence is failover is a reconnect.

[00:12:00]So if patron has a failover, it just reconnects up to the new primary. Now in terms of trade-offs, you know, you do have network egress on the source side because all the data needs to get out through the agent. There is one replication slot per agent. So you need to have one free. And if the agent has a long outage, you're going to be accumulating wall. And there's no archive command double archive on managed Postgres. Basically, the streaming path is the only path if you're using managed Postgres. But if you want to learn more, definitely check this out. Next piece of content, listen carefully. How notify can trip up your database. This is from virus.org.

[00:12:40]This is Jimmy Angelo's presentation that he gave at Posette talking about lifts and notify and how if your traffic ramps up, it does create a global lock on the PG database system view which can slow down everything. And as he describes it here, how the internal serialization of notifications triggers access exclusive lock cascades on PG database. and they fixed it using unlock Q tables and transaction level advisory locks. So you can watch the YouTube video of that here and look at the slides down here. Next piece of content also from Jimmy Angelacos is LinkedIn live fixing bad SQL and PostgresQL with Jimmy Angelos and this is basically from his book PostgresQL mistakes and how to avoid them and you can look at the video of it here. Next piece of content, how SQL PGQ rewrites to joins on Postgress 19. This is from cyberchive and postgressql.com and this goes over the detail about how graph queries get rewritten to SQL in the planner in particular with regard to indexes. So if you want to learn more about that, you can definitely check out this blog post. Next piece of content, how much do you really need to know about databases? This is from karenjex.com and this is from a presentation she gave at Euro Python in 2026 and it's actually not so much about what developers or software engineers need to know but it looks like if you wanted to become a DBA kind of all the different areas you would have to know and be familiar with. So if you're interested in that you can check out this presentation.

[00:14:20]And next piece of content the test passed the plan didn't. This is from boringsql.com and he's talking about the tool he released regressql that does regression testing of your SQL to make sure that the results of your query still return them what they're supposed to but there is still a gap with that if an index gets dropped well you still get the right answer but it's so much slower. So they've just released a version two that also tests for plan differences. So he says, "Test the plan, not just the rows." So if you're interested in that, definitely check out this blog post. And the last piece of content, making 768 servers look like one. This is from planetscale.com.

[00:15:05]And what they're talking about is sharding. And I know we've talked a lot about PG Dog and Multigz recently. Well, there's also Neki, which Planet Scale has made for Postgres. They do use the test for MySQL but they have developed necki or neki for postgres. So they have their own sharding solution as well that you can check out and learn more. I hope you enjoyed this episode. Be sure to check out scalingpostgres.com where you can find links to all the content mentioned as well as sign up to receive weekly notifications of each episode. There you can find an audio version of the show as well as a full transcript. Thanks. I'll see you next week.