Postgres FM - Postgres year in review 2025

Episode Date: January 2, 2026

Nik and Michael discuss the events and trends they thought were most important in the Postgres ecosystem in 2025. Here are some links to things they mentioned: Postgres 18 release notes https://www.postgresql.org/docs/18/release-18.htmlOur episode on Postgres 18 https://postgres.fm/episodes/postgres-18LWLock:LockManager benchmarks for Postgres 18 (blog post by Nik) https://postgres.ai/blog/20251009-postgres-marathon-2-005PostgreSQL bug tied to zero-day attack on US Treasury https://www.theregister.com/2025/02/14/postgresql_bug_treasuryPgDog episode https://postgres.fm/episodes/pgdogMultigres episode https://postgres.fm/episodes/multigresNeki announcement https://planetscale.com/blog/announcing-nekiOur 100TB episode from 2024 https://postgres.fm/episodes/to-100tb-and-beyondPlanetScale for Postgres https://planetscale.com/blog/planetscale-for-postgresOracle's MySQL job cuts https://www.theregister.com/2025/09/11/oracle_slammed_for_mysql_jobAmazon Aurora DSQL is now generally available https://aws.amazon.com/about-aws/whats-new/2025/05/amazon-aurora-dsql-generally-availableAnnouncing Azure HorizonDB https://techcommunity.microsoft.com/blog/adforpostgresql/announcing-azure-horizondb/4469710Lessons from Replit and Tiger Data on Storage for Agentic Experimentation https://www.tigerdata.com/blog/lessons-replit-tiger-data-storage-agentic-experimentationInstant database clones with PostgreSQL 18 https://boringsql.com/posts/instant-database-clonesturbopuffer episode https://postgres.fm/episodes/turbopufferCrunchy joins Snowflake https://www.crunchydata.com/blog/crunchy-data-joins-snowflakeNeon joins Databricks https://neon.com/blog/neon-and-databricks~~~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

Ho, ho, ho. Hello, and welcome to Postgresfm. My name is Michael. I'm a fan of PG-Mustard, and I'm joined, as always, by Nick from Postgres AI. Merry Christmas, Nick, and Happy New Year. Yeah, you too. And to all our audience, which is roughly, as we just counted across all the platforms, roughly 10,000 people, so it's impressive. Yeah, it's kind of wild. But yes, thank you, everyone, for another good year. Yeah. obviously we wanted to do some overview of this year 2025 for posgues i think it's a great year for postgess because a lot of stuff a lot happened and a lot is still happening and vector of development of product and communities around it and companies and everything ecosystem it's astonishing right yeah absolutely feels like it's going from strength to strength and yeah as you say another good year

yeah so what to start let's maybe start with some technical topics first maybe postgis 18 obviously one of them and we had a whole episode about that and what do you remember what are achievements of postgis 18 which shine yeah good question i guess one thing we didn't have When Postgres 18 came out and we did the episode was a little bit of hindsight, we didn't know how it was going to go. With a major version, you're always a tiny bit worried there's going to be a big issue in it. And once you get through the release candidates and the beta without that, that's either means there isn't a big issue or it hasn't been found in testing yet. So now with a bit of benefit of hindsight, I think it's gone pretty well, hasn't it? I mean, touch wood, it feels like not only has it gone down well, but people have been reporting.

some performance improvements people have actually been upgrading i'm actually seeing people in our case submitting version 18 query plans to the product so they're using it on production and already looking into performance things with it so they've not only upgraded but have had it in production for a little bit so yeah it seems like people are upgrading which isn't always the case when a new major version first comes out and seeing some wins which is cool yeah i also feel the pace of upgrades is improving from year to year, I think managed post-gast providers they polish the procedure and make new post-gust available sooner than in previous years. So it's obviously being noticed, right?

So, but in terms of post-gast 18, I remember things like in any overview, somehow UID version 7, native support of it made it to the short list of always mentioned. things and yeah it's great because again like it started or during postgist tv hacking sessions online it's i'm super proud of this like you know like finally it made it after a couple of years of waiting because of like waiting for rfc standard to be finalized postgis was very conservative compared to others it's great that this thing made it and it's not a huge thing but it's obviously very useful helpful for people? Not a reason to upgrade, though, right?

No, no. In my reasons, I wanted to mention specific one. I know we have customers who are working on upgrade sooner and already made decision to upgrade much sooner than usually to PostGus 18 just because lock manager, lightweight lock contention is fully solved. And I have a series of articles exploring this in detail, showing benchmarks. it. You just raise, if you upgrade, you just raise max locks per transaction parameter, which requires a start, unfortunately, but it's like easier than suffering, you know,

suffering from lightweight lock, lock manager contention. And that's it. Like, it's soft. So this work also took a few years to, to made it into final release and finally we have it. And this is definitely one of the reasons to upgrade. You know, if there are other reasons, I also noticed, as we discussed, AIO. That's a huge one for people. I actually haven't seen many, I think a few people have blogged kind of theoretically about the performance improvements that could be possible there. But I haven't seen anybody publish anything that they upgraded and saw a big improvement due to AIO. But I would say it has driven a lot of interest in the major version.

And it could be that it is proving really good for performance. But more than that, it's like a good marketing feature. Like it has driven a lot of interest in the upgrade and people actually considering it. Yeah, I saw it not in upgrade, but I saw it in, well, it's actually my blog post, Maximson mine, blog post. Yeah. And I suddenly noticed that before single thread that PG base backup only could do three, four hundred megabytes per second. But in Postgres 18, it's gigabyte per second on fast disks. so it was a big surprise to me

and it's also like one of the reasons I think should be considered to upgrade sooner. Yeah, enough, we can dive into technical details for another episode, but let's move on. What's next? What is big in 2025 on your opinion in terms of technical stuff?

On just the technical side, that's an interesting question. I've got a lot actually in and around the community, but on the technical side, I think one of the bigger things we saw was more efforts. Actually, maybe that's community still. Do you consider kind of the efforts to empower and grow more hackers,

like more actual Postgres developers, people working on the Postgres core base? Do you consider that technical or more community? Well, it's less technical. Technical, if you mentioned the word hackers, let's use this word in different meaning. Remember, you're a treasury hack? Oh, yeah. Yeah, this is quite technical. And there was a case when it was not so good, right?

And Posgis obviously used everywhere, so vernilabilities happen from time to time. And it's obviously technical-wise, Postgres has great process to fix, to issue a new set of minor releases which close virulability, but still, like, due to very wide use of post gas, I think this year, PostGus made it to moon technical media, right? Yeah. Because of that. And it was mentioned in the context,

oh, okay, there was like hackers from China, hacked the US infrastructure, and Posgis was involved. So this, I think, it's also kind of trend and it's slightly less technical, but there is some technical aspect in it. Yeah, yeah. Obviously, it means that, you need to upgrade in terms of minor upgrades always like patches should be applied promptly because things happen bad things happen and it's better to keep progress up to date in terms of minor version right so this is what i just remember this this thing nice i have one more technical one yeah yeah feels like it was a big year for announcements at least in the sharding space we we got at least three three big new projects

projects kicked off to try and shard postgres specifically for OLTP. Yes, exactly. So we had episodes with PG-Docke, Lefkotov, PG-Dog. Yep. We have had episode with Sugu, Maltigress, which is developed inside Superbase. And yeah, these are two things which are purely open source, and there is a non-open source product plan scale is developing, right? So, yeah, I think they've said they're going to open source it,

but it's all private at the moment. Yeah. Yeah. We have two open-source things we can. Actually, not we can. My team has already tested in terms of latency overhead, almost all of them. Is Maltegress testable already?

I've heard kind of yes, I cannot say for sure. Okay. Yeah, there is something there already, yeah. So I will let them to announce all the things, but it's definitely being developed quite rapidly. You can go and check pool requests. What I like about open source is very transparent, right? So you know what's already happening in a vector

in which it's being developed in both cases, Pichirok and Montegress. This is great power of open source. Yeah, true. And it's, yeah, it's interesting, like, how they're choosing slightly different trade-offs. And I think it will be fascinating in the coming years, kind of three, four years' time. I'd be really interested to see who's using which systems, what are the trade-offs, like which kind of systems benefit most from one approach versus the other.

Does the license matter? I think PG-Dog and Multigris have gone different directions on the licensing front. Language, yeah, exactly. So it will be interesting, but this felt like the big year. I think it was, I've written down, it was May that PG-Dog was first announced, June that Moldegos was first announced, and August that NECI was first announced. So, quite a short, you know, if you consider how long it's been since we had a new potential sharding solution and then three come along in a few months. It feels like the timing was right

for that to happen now. So yeah, there are companies which do need it and there is big demand, including companies who don't need it. This is like taking part with sharding. More people think they need it and actually need it. But it always was a weak side of PostGGIS ecosystem, lack of reliable and mature sharding solution. We had CITOS, we had PGCT, we had SPQR. And none of them was publicly known to be used in big OTP projects, like huge, huge scale.

Like for VETS, we have GitHub, Slack, and so on, Pinterest. here we didn't have such stories. We still don't have such stories yet, but I'm 100% sure we will have it soon, just because of this year development. Yeah, the big projects that sharded Postgres, almost all of them seemed, or at least the ones that have talked about it publicly,

did so application side. So they have sharded, but it's all on their own heads, basically, or, you know, using a framework, not a... Oh, yeah, yeah. We had episodes 100 terabyte. It was great, and two or three guests, I think all the guests use, basically, application side sharding, but at least one of them have good articles about this.

I think Notion, right? Notion. And figmented too, figmented. Okay, great. So, like, you can do sharding yourself, of course, right, but it's good to have some system. Yeah. Obviously, we are going to have multiple systems, which will be used in big companies soon. I think the vetesting is really interesting as well, though, because I think there's, you mentioned more people want sharding than need sharding.

I think there is like a really attractive thing to early stage start-ups that, you know, having to tell all their investors they're going to be the biggest thing ever probably have to believe that as well. So they want, and some of them, it is true, right? Like some of them are going to need, we talked about one last, last week where it was they should have partitioned a year ago, but they only launched a year ago. So there are these startups that need a small database at the beginning and they're going to need sharding within a couple of years because they're going to scale that fast. So for them, the story of, and it used to be, let's say, planet scale with the test, or just for tests in general,

was you can start small with us and then we, you know, you can have a sharded set up when you're ready. It was the same story with Mongo many years ago. It was this kind of like unlimited growth or web scale. Do you remember that phrase? So it is really, yeah, it will be nice. And I think that kind of transitions onto two things I had on my list.

One was, I think MySQL's loss is Postgres' gain this year. I think there's been quite a few, like, firstly, planet scale coming into the Postgres ecosystem, but also I think there were some stories more recently around a lot of MySQL's team getting laid off. So I think momentum on that's been kind of shifting and slowing for a while since the Oracle acquisition, maybe longer.

But I think Postgres is ready. is like ready to take up the slack and the work on sharding is part of that story because I don't think we did have a good answer to Vitesse until well and we maybe arguably still don't but feels promising that one of these three if not more than one of these three proved to be good yeah I I agree with you and that's why I actually mentioned the stories matter so we have stories published about successful sharding of postgustal great scale in DIY approach but we need more like case studies and I think I'm looking forward to next couple of years to to hear about successful use of new sharding solutions so it's

going to be great I like this is this is great foundation this year basically answered that postgres won't be considered as very limited all TP database system where you will be scared to hit some walls All right. So this is a great year for this topic. I like it a lot. Okay. Let's move on. Maybe you mention less technical stuff. I think there is a big movement in terms of startups and post-guist companies, pure post-guise companies, and less pure, but also very post-gist-related companies. For example, let's start from maybe, like, there are bad news and good news, right? Bad news, I think, what do you think about Yuga-Bite? I think Yuga-Bide is struggling.

It's not pure PostGos, but it showed some way to also solve a solution, right? But I think it's struggling. I see people left, many people. And I also think the topic we just discussed, that native sharding solution will have multiple OTP to achieve great scale and automation. they are going basically to say Yugaabite is not needed anymore.

Yeah, I honestly don't know and I think when we said lots of people, more people want sharded than need it. I think the same is true for distributed. I categorize them slightly differently in my mind like sharded and distributed and I think maybe the difference is

the idea of writing to multiple primaries in different availability zone. It feels like it's this kind of like you pay the tax on latency and for some it's 100% worth it. But for a lot, that trade-off isn't worth it. And I think a lot more people think they want multi-master, multi- or whatever the, I don't know what the appropriate phrase is for that now, but they're multi-primary. Multi-master is fine these days again. I'm joking. Interesting.

Yeah, I don't. But yeah, so my main point. is, I think, for the kind of financial institutions or big banks that need it, it's hugely valuable. But I think most companies don't need that and the trade-offs aren't worth it. But I don't have no idea how they're doing. And also, it's kind of Postgres compatible, right? Do you consider it post-gres? Well, yeah, yeah, you're right. You're right. It's more Post-Gos-compatible than Kouche, but it's definitely not pure post-Gus. Anyway, I think solutions we just discussed are going to meet needs of people who start with just small one post goes, like more naturally, you know,

like then migrating to other systems. Although at the same time, we must admit that, for example, AlloDB feels good. I have customers who migrated to AlloDB. And actually, I can mention a gadget, for example, we had an episode with Gadget, CTO, right, Harry. And we just found out that our monitoring system works well with alloy db and like alludeb also has blood and so on things to take care of it's interesting so it feels like postguess although there is a lot of of rewritten also this year i think it's important to mention amazon d sql although yeah it's not open source at all but it also like plays in the same area for enterprises they like we are not limited, distributed, everything, multi-region, everything.

And they are quite active in terms of development, I think, although it's not my area at all. Like, I'm pure Postgres guy, and I consider all these friends of Postgres, so to speak. Some of them open source, some are not. It's just like, for me, it's kind of, it's great to have them around, but I think pure Postgres should be a majority of, in terms of choices. Yeah, and while, like, each of the, each of the, each of the, hypers

has their version of this product right, this kind of distributed Postgres compatible for whatever

definition of Postgres compatible that they're going with this year but there has still been significant

contributions from these hyperscalers to pure Postgres and I think there's a there is a

kind of alternative timeline where we wouldn't be seeing the likes of AWS and Microsoft and even a little

bit Google Cloud but like lots and lots of companies but including those fiber scale is actually contributing back to pure Postgres, not just making their own proprietary forks. So it's, it's been quite, I don't, I really hope it continues.

But this year, it certainly feels like a lot of the contributions we got. A lot of the improvements in Postgres 18, a lot of the community efforts came from these big companies. And I would include EDB in that as well in terms of big companies continuing to like invest in pure Postgres. Microsoft Horizon DB, just, this is fresh news. Yeah. I've lost track for this enterprise attempt, like Enterprise Posgast topic, right? Like so many options.

I think pure Posgos is a player in Enterprise, and it's going to stay as a player enterprise. Although we have Aurora, AlloDB, HorizonDB, DSQL, who else? EDB, everything. Yeah, but all of them also offer a separate product that is much, much closer to Pure PostG. Right. So, AWS have RDS, Google have CloudSQL. You know, I actually always forget what Microsoft call theirs, but every single one of them

have one that... No, have one that looks just like Postgres, that acts just like Postgres. Yeah, it's something like... Okay. For Postgres QL or something, but I can't remember. We have customers, but I don't remember. With Microsoft, I touch Microsoft much less and others, yeah. Microsoft is good at a lot of things, but naming products is not one of them.

Well, Google is champion. Yeah, fair. So, only, we have so many flavors of Postgres, right? And obviously, there is an interesting competition in the area of Sharding, and there is obvious competition, which not started this year, it started much much earlier, that now it's becoming definitely, like kind of red ocean in terms of enterprise topic, right?

This is absolutely a red ocean every big company is playing there. Every big cloud company is playing there. Yeah, that's an interesting point because if you're talking about it being highly, highly competitive, normally what you'd expect to see if that was

the case would be prices starting to come down. And I don't think we've seen that. I still think they're charging quite a premium for it. But if it was truly a red ocean I don't know maybe I'm not seeing

the kind of enterprise contract negotiations maybe that's where the prices are coming down well yeah maybe you're right

I think there are segments there and the segment of like big Polsgues enterprise posbors I think

there are different methods to cut prices they all like normal cloud ways you know like like savings

plans and so on yeah but they don't rush and to go in down in terms of prices for post goes for one machine of obviously there is big

primary yeah yeah in terms of technical things trends this year not touching a i yet but maybe moving closer to it i think branching is becoming like slowly very slowly it it makes its way to be in commodity it's not yet there at all like i think and branching is is uh still very rare it's not it's not like not everyone is has it. I feel like there's two trends, right? Like I feel like there's branching and there's also cloning. And these are very kind of like similar topics.

And they're kind of being converged at. And some platforms and some systems offer cloning. Well, some platforms, some platforms offer thing cloning, some, but mostly it's thick cloning. But that's still, that's still valuable for some amounts of like experimentation and test. Adios had always, like, since the very, almost very beginning. And now... But Heroku even, Heroku even had offered it, yeah. Right, but if it's thick, well, tooling is improving there, for sure.

But I'm a big fan of, you know, like, I'm a big fan of think cloning, and we have our own product DBLAB, for database branching and think cloning. And I think if before this year, Newman was there, DBLAP was there, and that's it, Now we see timescale, Tiger data playing there. That happened this year. Understanding its role for AI and experiments. It's great. This is exactly how I see it for many years already.

And there CTO Mike just posted yesterday an article how Replit is doing this similar thing. So experimentation at scale, like in isolated environments and to make it fast and cheap, you need copy and write. So this is the way. Basically, you can have a lot of ideas how to improve your database. And not everything can be verified on think learning, but a lot of ideas can be verified and in the isolated post-guise instances

and database branching is great. For example, definitely everything related to query optimization at macro level. We discussed it many times. We're working with plans, verifying ideas. this is absolutely needed thing otherwise you become too slow too expensive and you are limited and in the topic of self-driving postgres we actually yesterday i noticed big trend like people started talking about autonomous postgres and self-driving postgres we had i have a post someone from edb mentioned something and i also posted so this is part of autonomous postgast for sure automated experimentation and

branching is essential part of this vision and we have pieces already when companies start implementing this yeah so this works at GitLab with DB Lab for many years already so I'm happy this topic becomes more and more popular and future of self-driving postgres also like it's still foggy but we have components which already becoming quite clear and we see how to achieve levels of automation, very high levels of automation. Did you see, on this topic area of like branching, thin cloning and copy on right, did you see there was a recent post by Redeem at Boring SQL talking about a feature in Postgres 18 that I'd missed that is like you can create database within Postgres and specify a strategy

and that can use, if your faster supports, yeah. Yeah, yeah, I actually, I also missed it. I remember this discussion on Hacker's mail list, but I somehow overlooked it. So it's already Postgres 18, are you sure? Yeah. Wow, that's cool. I haven't verified myself, but this blog post says so, yeah. Yeah, I'll share it.

It has a limited scope of use. So I think if you control everything, all experimentation environments very well, you can definitely use it. So basically, you have one single Postgres instance, and each create database, if it's based on copy and write. It's fast and cheap. It brings you isolated logical database for experimentation, but it's not for everything. For example, in case of DBELAP, you can perform major upgrade of clone. Here, it will be not possible because it's a single instance.

Although working with ideas, how to verify indexes, tone tuning, this will work for sure. This is great. Yeah. And baked into Postgres already, that's. That's super cool. Yeah. Well, that's cool. That's cool. I need to revisit this somehow I've looked as well.

Great. Great. I think what we see in the future, more tools which will automate experimentation for optimization, performance optimization. And instead of like, phone something to LLM and sitting with ideas which you don't know which of them are correct, which are completely wrong, you will throw to some tool and the LLM will generate ideas. Well, this is actually already

happening. We just don't have it connected to all the pieces, right? But we ideas are verified on clothes, on thin clothes, right? Yeah. And the user receives already ideas which were considered during brainstorm phase and then

ideas which didn't work and ideas which worked best proposed for to apply in production. Yeah. I personally think this is something this is a topic that has got a lot of legs for the coming years but i don't think we've seen yet that much like i don't think i think we've only seen the beginnings of this topic well and the pieces uh some basically like building blocks we have yeah the final like the whole

solution is yet to build i agree did you see much progress on that kind of the vector search side of things this year oh yeah i remember i started here looking at at turbo puffer we've found that we also had an episode. So it confirms it's great, successful year for PostGus, but also for PostGus FM podcast. Because we had great episodes covering areas which are important for users, right? So TurboPath are great. And this approach with vectors in S3, and you know, S3 also now has a vector type. Yeah.

I revisited recently, and it's outside for PostGus. But while I started looking at it, because I noticed clients who come to us using Postgres, they use them. And also I noticed it's used in cursor, so that's how I, there's Turpapather. So combination of Postgres plus turbopather, it's kind of, like, I saw trend similar to, you know, like elastic, Postgres plus elastic. Similar, like something happening. And I thought, like, it's great, like in terms of price and, like, technology is great. and S3 also has vectors now but I think it's still to be understood

use cases for all of these approaches and PG vector is going to stay I wish it was in core I don't see how it's possible now but I've there been conversations about I haven't seen I haven't been looking closely but I might have missed them have there been conversations about doing something in core

like formally all beginnings of conversations were just like interrupted like this index type is not normal because it's it's answering different results right because it's due to its approximate nature basically it's not it's not deterministic right yeah and this brings the new challenges so to be considered as a like core thing but in my opinion it must be in core to be in core to be developed properly and be considered as something like super standard

although PG vector is super standard thanks to all managed platforms supporting it as well so all people start there I wanted to say this I don't see anyone who solved one billion vectors problem yet all those who

claim they solve it I think they are lying it's like the spacing right what they call it like they say you don't but but you need to to basically

cluster and not cluster partition it right so it's not one index it's multiple indexes

like key spaces namespaces use any word but what it means it you don't have a single index which supports good OTP

scale OTP latencies meaning it's definitely much faster than one second for single query

and has covering one billion vectors Nobody does it. S3 including, right? S3 also has maximum, I don't remember, 50 million or how many vectors in one index supports.

So anyway, this is an unsolved problem. And it's unsolved, I think, everywhere, not inside post-guist ecosystem. So it's a big problem still. How to have a single index? Why do we need a single index? Maybe we don't need it. Maybe we can always split it.

PG-Doc also showed how to combine sharding and PG-vector, right? So you can have multiple post-gris instances and so on. Yeah. Questions about price and so on also can pop up, but TurboPuffer is not open source. Again, like we have great open-source tooling already, and if you combine with sharding, maybe you are fine. But I haven't seen a single one-billion scale in. index, which would work.

Why does it matter? Like, if I have a partition table, that's not, that doesn't have a single index on it. Right. But I, so why does it matter? Complexity. If you talk about regular indexes, having a few billion records in a table, it's not a problem at all. And latency will be amazing if you have index only scan, or just index scan.

If you, you know it very well, right? If you don't have this rows filtered out, right? But when it comes to vectors, if you have. have one billion vectors and you try to cover it with single index, build time will be terrible for HNSW, latency will be terrible, so it's not LTP. It doesn't need LTP standards, which we know like 100 to 100 milliseconds maximum because of human perception. Yeah, but not for search.

For search including, for people. Search is one of those use cases where people are willing to, okay, fine. No, no, no. Are you okay if you Google something? and you need to wait 10 seconds you're not okay um yeah it's a good point actually i think google is probably the proof that search is important to be fast of course that's what they've always focused yeah people knew it everywhere like you you have mobile app you you type something you want to you want like to move it very fast like simon if it's below 100 milliseconds it doesn't feel like

slow that's great so we have human perception which which defines all tPs right so you don't convince me that performance matters that and it's good, but I was just thinking it might. Search is considered part of application. It's not like we have search system, okay, in some cases, okay, if it's some, if it's a lawyer who needs to pull some lawsuits from history,

like related to the topic they're working on right now, they can wait a minute, no problem. Or if it's like BI report. This actually means we overlooked one trend as well. analytical thing, right? So, parquet, Iceberg and DuckDB

and how to bring all this in Posgars, a few companies played good game and we are acquired, right? Yeah, I would say this was like, this was huge news, I think, let's say last year.

And then I think this year what happened as a result were possibly that one of the biggest analytics databases companies in the world acquired what was one of the most promising companies in this space. So that was, I actually, yeah, I had that on my list to cover. I was thinking that's more community side of things. But I guess it's technical because it came about probably because of their progress on the analytics space.

Yeah. So obviously, Crunchy Data started to work with analytical side of postgast, which was always considered weak and achieved, had great achievements and got acquired for a quarter of billion and new on although it's they didn't play a lot with analytics way we did something with duck db as i saw like they they tried here and there things but still it was purely old tp thing right for for for with branching and super fast point in time recovery and serverless everything and got acquired by snowflake for one billion and data breaks oh data bricks yes the snowflake yeah crunchy data bricks

Neon, right. And they are, as we see, they both work to bring solutions which are combined, like analytics plus OTP and everything. We could consider this also like from different angle, but this is also a game to conquer like enterprise postgas topic, right? Just coming from analytical perspective first. And that's interesting. Like I, I like what's happening. And I also like that some people don't like to be not in open source environment and more talents are available. Oh, interesting. To be hired because of these acquisitions. Yeah, of course, it's natural because both Snowflake and Databricks, I don't consider

them as pro open source companies at all. And we know Neon, I haven't checked for a few weeks, but Neon stopped showing any commits on GitHub since July, right? Yeah, that's the tricky thing with acquisitions like this, because if you read the posts about what the plan is and what they're announcing is going to happen, and then watch for five years, quite often those things don't align. So it's really difficult to assess these things within, you know, six months of them happening as to why did it happen? Is this a good thing for the community? Is it a bad thing for the community? it's really hard to tell it could be the best thing ever or it could be awful and it's it's really hard to tell this close to it which of those is going to be the case yeah in this context i would like to mention also a couple of companies which i like what's happening as well like you you can you can see like some negative sides but you can see a lot of positive sides in everywhere for example plane scale came to postgres ecosystem yeah great

And they resurrected the old topic, which some people tried to bring life into it. Let's use local MVMe disks. That's great, like, absolutely great. And they also, like, I like what they do a lot in a lot areas. I don't like their position with open source because I don't see what open source they produce at all. They just use VTES, which was created before playing scale. And that's it. And maintain it, I think, yeah.

Well, yeah, yeah, that's of course, but what else? So anyway, but I like a lot of what they do and they brought absolutely different, I think, different kind of views at things which Postgres ecosystem somehow missed. So like it's kind of blood of my SQL ecosystem was merged to Postgres ecosystem and this is great. like different points of view and so on and this is this feels really great and this year achievement I think in terms of postgres ecosystem development and another is of course

SuperBase which is pure open source they bat heavily on open source and Multigres and Oriole DB and all things and this is their like I think strategy to do things open source and well and not just I would say not just open source but with permissive licenses.

Yeah. I think it's, I think that's incredible. I think it's something that people don't really fully appreciate of how important it was for PostgresQL to have a, not just an open source license, but a really permissive open source license. Yeah, like Apache, MIT. Exactly, exactly.

Postgres license. Yeah, all of them extremely permissive. And I mean, they're not copy left, they're not AGP. Like, they're actively. trying to encourage collaboration and allowing people to use it for commercial purposes is so low. You know, common misconception here. GPL and GPL, they are more open source than these permissive licenses, right? But somehow people avoid them because they cannot build commercial cloud things on top of them.

I'm not trying to get into an argument as to what's more or less open source. I'm saying that the fact that permissive, I think, is freedom. Yeah. And I think it's good for everybody. It's good for the rest of us. Unprotected freedom. This is how you can see. Because somebody can clone and create commercial software based on that, easy. Well, and I think it's about betting on the long term. Like, I think it's about saying commercial things will come and go, but this will still be here. It's off topic. Yes. I apologize. I wanted to credit them for it. I just wanted to mention that SuperBase growth is like absolutely. crazy and why because a lot of tools which are also growing crazy they basically bring a lot of development activities even from non-developers vibe coding right like many platforms grow grow grow and postgust became like it's obvious this year postgis is default database for wipe coding this is

100% like as of end of 2025, it's so. And Superbase growth and Neon mentioning that 80% or something of databases created are created because of pipe coding and AI agents and so on neon, yeah. What about Replit? I actually didn't finish reading the, did you see the post that Mike was responding to? Is that Postgres? Yeah, well, yeah, it's Postgres, yeah. So Bosniz everywhere.

Yeah, nice. I would say the thing about super base and planets go and people like that, they're also amazing at marketing. And I think that's underrated in the Postgres ecosystem in terms of being good for the project. They've kind of brought some of that energy of, you know, early MongoDB that people actually excited to use it. Developers want to use it. They think it's like an easy thing. You know what I mean?

It's that kind of like, it's cool all of a sudden. And I don't know, I don't know if I've been here long enough to remember the last time that it was actually cool. I don't know. Yeah, let's mention friend Pashogh who left Posgous world, but he says not fully left. We also had an episode, right? Yeah. Yeah, and joined MongoDB. So that sounds so interesting.

I'm, last time I used MongoDB was 12 years ago. I don't know. Last time I listened to them was 2018. in VLDB, Los Angeles. But if you go back, if you look at startups that are 12 years old, a lot of them will be on Mongo, like, or 11 years old, 10 years old. And I think we're going to see this, like startups that started now, like last year, this year, next year,

a lot of them are going to be on Postgres. And I think that's really healthy for the ecosystem. Yeah, yeah, yeah. And they're also challenging because people even don't realize what is it? Fair. But you mean the vibe code? is right so i think there are challenges in the area of explaining basics it's i think demand on understanding like simple basics like for us vacuum is basic but maybe it's not basics

relational things are basics like sometimes i see different platforms go at different levels there some people like super base they expose whole post goes you can play with tables and so some like gadget for example they expose concept of indexes but they don't let you to connect to PostGGS directly. So more like vibe side. So different levels here. It's so cool. Like you can choose how deep you can go.

But if you go and you don't understand, you need, I think demand for good education of relational databases and postgres is growing because of all these activities. And on one hand, on another hand, demand for good maintenance operational tools and practices and methodologies is also growing because imagine how many databases are created now every day. A year ago it was much, much less, right? Postgres, like,

number of databases is exploding this year, literally right now. But don't you think their shelf life is also reducing? Of course, most of them want to survive. Yeah. We're just experimenting, wipe coding, like, throwing out later. But some of them will survive.

Yeah, they need to path for good good health right that's why I think self-driving is also like new trend which is going to stay and it's great to have

examples of previous attempts as Oracle Autonomous we can learn from them and others yeah okay we'll definitely discuss this topic not once in future I'm quite sure

yeah well again like trend is obvious trends started here in 2025 okay well yeah I think that it'll be interesting to see how important it turns out to be in 2026 my opinion is actually that the ones that survive can then be given a bit more attention so like it's going to be not that I think it's still difficult to get a business up and running and to a huge scale the ones that do it are still incredible and they're still not that many I don't see that there's going to be tens of thousands more of the

those really successful huge companies, but they might get their quicker and with fewer technical resources in the beginning. So they'll need support for sure, but I don't see the argument that there's going to be an order of magnitude more of them. My team feels it really well. Imagine enterprises,

regular startups, they are different, right? And there is new breed AI startups. These guys move really fast. They like database expertise even more. they are very often very smart but they are different from regular startups and I feel it just from perspective how

work with databases organized so this trend will only grow in the future it started this year I think we noticed it this year but it will not disappear I think this is something new and you don't think they'll hire like you think they won't hire

for those like specialties once they grow I think they will but they move so fast you can hire but then what like it's too late like you mentioned this case about partitioning right with regular methods this new hire with absolutely great knowledge will come but it will be too late it's already should be done a year ago but it's not too late like it's not success generally brings like enough money to solve these problems like hire good consultancy to help out but you can like I'm not joking I heard let's migrate to different database system maybe okay so you think for postgres is survival it's a challenge yeah

yeah yeah so like if database cannot scale without like too much attention and and too much manual work it won't survive it's hyper growth it's we had this term hyper scalers yeah is going to bring new level of hyper scaling you know so we need to adjust thank you so much let's let's let's let's Let's say happy Christmas, happy new year to everyone. And let's continue a new year with all these trends and good post-gust health, good post-gust tools, good open-source. It's great to be in this ecosystem and this community in broader meaning. And I really enjoy making this podcast with you, Michael, and also happy new year and Merry Christmas. Absolutely. Likewise. Thank you, everybody. Thank you, Nick. I do too. And see you in 2026.