Episode Transcript
[00:00:00] We definitely have a fluid situation going on with Postgres 19 and its release date and questions about what will actually be released.
[00:00:11] But at least as I'm recording this today we know that the beta 4 has been released, but I hope you, your friends, family and co workers continue to do well. Our first piece of content PostgreSQL 19 Beta 4 is released. This is from PostgreSQL the next planned release is the release candidate, which should occur in early October according to this, and then hopefully a couple of weeks later PostgreSQL will be generally available where they say PostgreSQL19 may also occur in October, so there's no guarantee, but the hope is it will get released in October. And again, what makes this delay different this year is probably the the use of AI and having it find all sorts of edge cases that should be resolved before releasing the product.
[00:01:02] This is very much True here. The PostgreSQL community strongly believes that first and foremost PostgreSQL must be reliable, but that also needs to be measured against striving for a predictable release schedule. So with those two guidelines we tend to get things cut to be able to make release dates if they can do it. And in the changes since beta 3 there aren't as many reverts as was mentioned previously. So we do have the merge split partitions was reverted. We know the SQL property graph support was removed. We also heard about the online disabling of checksums and temporal updates and deletes provided by for portionedof. They also removed some pgget functions as well as a change that forced LC cholate to C in the postmaster process, but those seem to be the only reversions listed here. I know previously they talked about groupbyll being removed. I don't see that mentioned as well as toast compression not changing to LZ4, I didn't see that mentioned as well. So maybe some of these will still get in. Don't know, we'll have to see. But if you want to learn more, definitely check out this blog post.
[00:02:17] Next piece of content PgBouncer 1.26 is released which fixes 3 CVEs and 2 of these can be caused by unauthenticated clients. So definitely important to upgrade this if your PgBouncer is open to the Internet, which you probably shouldn't do anyway. One of these is caused by a scram client final message without a nuance, other is caused by an integer overflow in the packet buffer growth logic and then the third one not triggerable by unauthentic clients is actually when you have a malicious Postgres server. So it's the server can cause unbounded scram iteration count. But if you want to learn more, you can definitely check this out.
[00:03:01] Next piece of content Systemic Risks in the managed PostgreSQL industry. This is from maimitinsk.net and this was actually from August, but I hadn't heard of it. And this is the first of six blog posts and the extended title is Systemic Risks in the managed PostgreSQL extension risks are real so exploiting post GIS memory corruption bug at Neon db, Supabase and more.
[00:03:29] So this is a long discussion, but basically he was investigating a hosting solution I guess from a security perspective and how he chose to compromise the systems is using an extension, specifically PostGIS and its address standardizer. So he found a vulnerability in that and was able to leverage that to gain access to the hosted system, which is no bueno. He was able to do it for multiple managed services and he goes over the whole process of doing that here. Now the good thing is the managed services were able to patch those issues quickly, but still and here he shows videos showing remote code execution zero day on Neon DB and Supabase and Zeta. And if nothing, I think reviewing this can help you improve your own database's security. But the next blog post, Part two has been released. This one Breaking the Super User guardrails Attacking Security hardened extensions. Systemic Risks in the managed PostgreSQL industry.
[00:04:39] So here he's leveraging the security hardening extensions that temporarily grant permissions to do something above what you would normally be able to do in a hosted database. And he was able to leverage this to attack the systems. And he goes over in all the detail about how he did this as well.
[00:04:59] So again, another justification to treat security seriously for your own database system. But if you want to learn more, definitely check out these two blog posts and the next piece of content. There was another episode of Postgres FM last week. This one was on Clickhouse Managed Postgres and Nick and Michael were joined by Sy from Clickhouse. And actually Sy was on the show a couple of years ago I think when he was the founder, I think, or one of the founders of PeerDB whose objective was to make streaming data out of Postgres easy into an analytics solution. Since that time ClickHouse has acquired PeerDB I believe, and the show talks about where they are going in terms of Clickhouse so much like Snowflake and DataBricks have acquired Postgres hosting solutions.
[00:05:50] Clickhouse has done the same, although I don't know if it was an acquisition or more. Working with the people at UBI Cloud to set up a hosted Postgres service. Their hosted service does rely upon NVME drives to give you the type of performance you may see from PlanetScale, for example. And what Clickhouse is trying to do at this point is make it super easy for application developers to seamlessly talk to their Postgres database for transaction processing data, as well as their Clickhouse data store for all of their analytics. So they're making the data produced in Postgres be able to seamlessly transfer as fast as possible to a clickhouse analytical environment. And one of the main things they've built is something called Wall Shadow.
[00:06:37] So as opposed to relying on logical replication to sync from Postgres to Clickhouse, they they've actually worked on using physical replication to do it. The reason is because that gives you much lower latency than logical replication would. So they're trying to get latency down to on the order of milliseconds from the point at which the data is in your transactional database until it gets into the analytic database. So basically Clickhouse has a managed Postgres solution that you they are using click pipes to stream that data into a Clickhouse analytics database. They're using Wall Shadow to give you very low latency copies from Postgres to ClickHouse. They're using PG ClickHouse, which is an extension that allows you to query Clickhouse from Postgres.
[00:07:28] So they're really trying to make working with a transactional database and analytical database work as seamlessly as possible for your application. And of course they talked about many more subjects on the show. So if you want to learn more, you can listen to the show up here or watch the YouTube video down here.
[00:07:46] Next piece of content related to Wall Shadow is the Shadow Nose. This is from thebuild.com and he talks about what Clickhouse has built with Wall Shadow in terms of using physical replication as opposed to logical replication, and some considerations that had to be done with that. So if you're interested, you can check this out. Next piece of content. Being considerate of other people's time. This is from Vondra Me and it really sounds like for people who are reviewing Postgres code and contributing, first thing he mentions, you know, if you could do more, you probably should.
[00:08:20] So basically you should get patches into as good a merge state as you possibly can yourself and and then ask others for assistance if needed. But he says, well, what about experimental proof of concept patches? Well, with regard to that, you probably want early feedback as much as possible. So at this point it is okay to bring people in to get their feedback prior to you building a complete solution. So in this scenario that is okay to reach out a little bit early.
[00:08:48] And then he also talks about huge patches suck because basically people don't have time to review mammoth changes to the code base and making sure that there aren't side effects that are taking place as a result of that patch. So basically small and focused is the key. But if you want to learn more, check out this blog post. Next piece of content 10 years of Postgres logical replication this is from Tapou eh.org and he does talk about the declarative partitioning history of Postgres from Postgres 10 till today.
[00:09:20] He shows an example of what's changed in each release in terms of additional features. And then he talks about a write out scaling solution he built one time and how with logical replication today it could take over many of the responsibilities and code that were necessary to get it working.
[00:09:37] Now would you necessarily want to do a write scale out using this today?
[00:09:42] Probably not, but it is indicative of how far the features have come in logical replication. But he uses that as an example throughout this to talk about the new features that have been added over the years. So check this out if you want to learn more. Next Piece of Content the call is coming from inside the session. This is from thebuild.com and he's talking about a runbook giving an AI agent access to database logins, and it typically contains something like this.
[00:10:12] Know you're going to alter the role. You're going to set the user to a particular statement timeout and to make sure transactions are read only. The problem with this is that this is merely a default and once logged in the agent can change statement timeout to infinite and disable the transactions read only. So you're not going to want to use this method to try to set restrictions on your agent. You need to use explicit grants on objects to do it, and he talks a little bit about that in this blog post.
[00:10:46] Next Piece of Content the Architecture of Nikki this is from planetscale.com Last week or a week and a half ago PlanetScale did release Nikki. This is their sharding solution for Postgres similar to vitess for MySQL, and this blog post goes over its arch architecture. So if you want to learn more about how it's structured, you can definitely do that.
[00:11:10] Next piece of content 25 years of contributing to Postgres with Peter Eisentraut this is the most recent episode of the Talking Postgres podcast, so if you want to learn more about Peter and his contributions to Postgres, you can listen to it here or watch the YouTube video down here.
[00:11:28] And the last piece of content, the hacking workshop for October 2026 is going to cover Robert Haas's talk about PGPlan advice. So if you want to learn more about that, there's a form to sign up for it here. I hope you enjoyed this episode. Be sure to check out scalingpostgres.com where you can find links to all the content discussed, as well as sign up to receive weekly notifications of each episode there. You can also find an audio version of the show, as well as a full transcript. Thanks. I'll see you next week.
