new year. Nikolay: Yeah, you too and to all our audience which yeah roughly
as we just counted across all the platforms, roughly 10,000
people.
So it's impressive.
Michael: Yeah, it's kind of wild, but yes, thank you everyone
for another good year.
Nikolay: Yeah.
So obviously we wanted to do some overview of this year 2023
for Postgres.
I think it's a great year for Postgres 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 it's astonishing
right Michael: yeah absolutely Feels like it's going from strength
to strength and yeah, as you say another good year
Nikolay: Yeah, so where to start let's maybe start with some
technical topics first.
Maybe Postgres 16 Obviously 1 of them and we had a whole episode
about that and what do you remember?
What are achievements of Postgres 16 which shine?
Michael: Yeah good question I guess 1 thing we didn't have when
Postgres 16 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 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?
Like 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 16
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.
Nikolay: Yeah, I also feel the pace of upgrades is improving
from year to year I think managed Postgres providers say polish
the procedure and make new Postgres available sooner than in
previous years.
So it's obviously being noticed, right?
So, but in terms of Postgres 18, I remember things like in any
overview somehow UUID version 7, native support of it made it
to the short list of always mentioned things.
And it's great because again, it started during Postgres TV hacking
sessions online.
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.
Postgres was very conservative compared to others.
It's great that this thing made it.
It's not a huge thing, but it's obviously very useful, helpful
for people.
Michael: Not a reason to upgrade though, right?
Nikolay: No, no.
Among reasons, I wanted to mention a specific one.
I know we have customers who are working on upgrades sooner and
already made a decision to upgrade much sooner than usually to
Postgres 18 just because LockManager, lightweight lock contention
is fully solved.
And I have a series of articles exploring this in detail, showing
benchmarks that you just raise, if you upgrade, you just raise
max_locks_per_transaction parameter, which requires a restart,
unfortunately, but it's easier than suffering, you know?
Suffering from lightweight LockManager contention.
And that's it, it's solved.
So this work also took a few years to make it into final release
and finally we have it and this is definitely one of the reasons
to upgrade.
Now if there are other reasons, I also noticed as we discussed
AIO.
That's a
Michael: 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 it could be that it is proving really good for performance
but 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.
Nikolay: Yeah I saw it not in upgrade, but I saw it in...
Well, it's actually my blog post...
Maxim's and mine blog post about pgBackRest.
And I suddenly noticed that before single-threaded pg_basebackup
only could do 300-400 megabytes per second, but in Postgres 18
it's gigabyte per second on fast disks so it was big surprise
to me and it's also like 1 of the reasons I think should should
be considered to upgrade sooner Oh, yeah, we can dive into technical
details for another episode, but yeah, let's move on.
What's next?
What's what is big in 2025 on your opinion in terms of technical
stuff
Michael: 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 1 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?
Nikolay: Well, it's less technical.
Technical, if you mentioned the word hackers, let's use this
word in a different meaning.
Remember US treasury hack?
Michael: Oh yeah.
Nikolay: This is quite technical.
There was a case when it was not so good, right?
And Postgres obviously used everywhere, so vulnerabilities happen
from time to time and it's obviously technical wise, Postgres
has great process to fix, to issue new minor, set of minor releases
which close vulnerability, but still due to very wide use of
Postgres.
I think this year Postgres made it to more technical media because
of that.
And it was mentioned in the context of, okay, There was like
hackers from China hacked the US infrastructure and Postgres
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 and 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 Postgres up
to date in terms of minor version Right, So this is what I just
remember this this thing.
Michael: Nice.
I have 1 more technical 1.
Yeah Feels like it was a big year for Announcements at least
in the sharding space.
We got at least 3 3 big new projects kicked off to try and shard
Postgres specifically for OLTP
Nikolay: Yes, exactly.
So we we had episodes with PgDog, Lev Kokotov, PgDog.
We have had episode with Sugu Multigres, which is developed
inside Supabase.
And yeah, these are 2 things which are purely open source, and
there is a non-open source product, PlanetScale is developing,
right?
So, yeah.
Michael: I think they've said they're gonna open source it, but
it's all private at the moment.
Nikolay: Yeah.
Yeah.
We have 2 open source things we can also, actually not we can,
my team is already, my team has already tested in terms of latency
overhead, almost all of them.
Michael: Is Multigres testable already?
Nikolay: I've heard kind of yes, I cannot say for sure.
There is something there already.
So I will let them announce all the things, but it's definitely
being developed quite rapidly.
You can go and check pull requests.
What I like about open source is it's very transparent, right?
So you know what's already happening in vector In which it's
being developed in both cases.
This is great power of open source Yeah, yeah
Michael: 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 3, 4 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
1 approach versus the other, Does the license matter?
I think PgDog and Multigres 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 PgDog was
first announced.
June that Multigres was first announced and August that Neki
was first announced.
So quite short, you know, if you consider how long it's been
since we had a new potential sharding solution and then 3 come
along in a few months, it feels like the timing was right for
that to happen now.
Nikolay: So yeah, there are companies which do need it.
And there is big demand, including companies who don't need it.
This is like, yeah, with sharding, more people think they need
it and actually need it.
But it always was a weak side of Postgres ecosystem, lack of
reliable and mature sharding solution.
We had Citus, we had PgCat, we had SPQR.
And none of them was publicly known to be used in big OLTP projects
like huge huge scale like you know like for Vitess.
Vitess 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's development.
Michael: 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
Nikolay: Oh, yeah, yeah, we had episode 100 terabyte of Postgres.
It was great.
And 2 or 3 guests, I think all the guests use basically application
side sharding.
Yeah.
But at least 1 of them have good articles about this.
I think Notion, right?
Notion.
Michael: And Figma did too.
Nikolay: Okay, great.
So, you can do sharding yourself, of course, right?
But it's good to have some system.
And obviously we are going to have multiple systems which will
be used in big companies soon.
Michael: I think the Vitess thing 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
startups 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 1 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 want, 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 PlanetScale
with Vitess or just Vitess in general, was you can start
small with us and then we, you know, you can have a sharded setup
when you're ready.
It was the same story with Mongo many years ago.
It was this kind of like, I'm going to grow for web scale.
Do you remember that phrase?
So it is really, yeah, it will be nice.
And I think that kind of transitions onto 2 things I had on my
list.
1 was, I think MySQL's loss is Postgres' gain this year.
I think there's been quite a few, like firstly PlanetScale 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 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 Vitess until, well, and maybe arguably
still don't, but it feels promising that 1, hopefully 1 of these
3, if not more than 1 of these 3, proved to be good.
Nikolay: Yeah, I agree with you.
And that's why I actually mentioned the stories matter.
So we have stories published about successful sharding of Postgres
to 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 hear
about successful use of new sharding solutions.
So it's going to be great.
This is a great foundation this year, basically answer that Postgres
won't be considered as very limited OLTP 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 I mentioned less technical stuff.
I think there is a big movement in terms of startups and Postgres
companies, pure Postgres companies and less pure, but also very
Postgres related companies.
For example, let's start from maybe like, there are bad news
and good news.
Bad news, I think, what do you think about Yugabyte?
I think Yugabyte is struggling.
It's not pure Postgres, but it showed some way to, also solid
solution, right?
But I think it's struggling.
I see people like, left, many people, and I also think, the topic
we just discussed, that's a native sharding solution will have
multiple OLTP to achieve great scale and automation.
They are going basically to say Yugabit is not needed anymore.
Michael: Yeah, I honestly don't know.
And I think when we said lots of people, more people want sharded
than want, 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 zones.
It feels like it's this kind of like, you pay the you pay the
tax on latency and for some it's 100% worth it.
But for a lot it's not that trade off isn't worth it.
And like 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 I'm a bit multi primary
Nikolay: not so much so is fine these days again I'm joking interesting
Michael: yeah but yes 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 have no idea how they're doing.
And also it's kind of Postgres compatible, right?
Do you consider it Postgres?
Nikolay: Well, yeah, yeah, you're right.
You're right.
It's more Postgres compatible than CockroachDB, but it's definitely
not pure Postgres.
Anyway, I think solutions we just discussed are going to meet
needs of people who start with just small 1 Postgres like more
naturally, you know, like then migrating to other systems.
Although at the same time, we must admit that, for example, AlloyDB
feels good.
I have customers who migrated to AlloyDB and actually I can mention
Gadget for example, we had an episode with Gadget CTO, right,
Harry, and we just found out that our monitoring system works
well with AlloyDB and like AlloyDB also has bloat and so on things
to take care of it's interesting so it feels like Postgres although
there is a lot of rewritten also this year I think It's important
to mention Amazon DSQL although it's not open source at all,
but it also plays in the same area for enterprises.
They 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 majority of in terms of choices.
Michael: Yeah and well like each of the each of the hyperscalers
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 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 hyperscalers actually contributing back to pure Postgres,
not just making their own proprietary forks.
So it's been quite, 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
Nikolay: pure Postgres.
Microsoft HorizonDB, this is fresh news.
I already, I lost track for this enterprise attempt, like enterprise
Postgres topic, right?
Like so many options.
I think Pure Postgres is a player in enterprise and it's going
to stay as a player in enterprise.
Although we have Aurora, AlloyDB, HorizonDB, DSQL, who else?
EDB, everything.
Michael: Yeah, but all of them also offer a separate product
that is much, much closer to pure Postgres.
Right.
So AWS have RDS, Google have Cloud SQL, you know, if every actually
always forget what Microsoft call theirs, but every single 1
of them have 1 that looks just like Postgres.
That acts just like Postgres.
Yeah, it's something like for PostgreSQL or something.
Nikolay: We have customers, but I don't even remember.
With Microsoft, I touch Microsoft much less than others.
Michael: Microsoft is good at a lot of things, but naming products
is not 1 of them.
Nikolay: Well, Google is a champion.
Michael: Yeah, fair.
Nikolay: So anyway, we have so many flavors of Postgres, right?
And obviously there is an interesting competition in the area
of Sharding and there is all this competition, which not started
this year, it started much earlier, but now it's becoming Definitely
like kind of red ocean in terms of enterprise policies topic,
right?
This is absolutely a red ocean every big company is playing there.
Every big cloud company is playing there
Michael: 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.
Like I still think they're charging quite a premium for it.
So 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.
—
Nikolay: Well, yeah, Maybe you're right.
I think there are segments there and in the segment of like big
Postgres, enterprise Postgres.
I think there are different methods to cut prices.
They all like normal cloud ways, you know, like, like savings
plans, saving plans and so on.
Yeah.
But they don't rush into going down in terms of prices for Postgres
for 1 machine.
Obviously, there is big premium.
In terms of technical things trends this year, not touching AI
yet, but maybe moving closer to it.
I think branching is becoming, like, slowly, very slowly, it
makes its way to being commodity.
It's not yet there at all, like I think.
And branching is still very rare.
It's not, like, not everyone has it.
— I feel
Michael: like there's 2 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, some platforms and some systems
offer, offer cloning.
Nikolay: Well, some
Michael: platforms, some platforms offer thin cloning some,
but mostly it's thick cloning, but that's still, that's still
valuable for some amounts of experimentation and test runs.
Nikolay: Yes, had always, since the very beginning.
Michael: And Heroku even, Heroku even offered it.
Nikolay: Right, But if it's thick, well, tooling is improving
there for sure.
But, I'm big fan of, you know, like I'm, I'm big fan of thin
cloning and we have our own product, DBLab for database branching
and thin cloning.
And, I think is if before this year, Neon was there, DBLab was
there and that's it.
Now we see Timescale, Tigris data playing there.
Michael: That happened this year.
Nikolay: Understanding its role for AI and experiments is great.
Like This is exactly how I see it for many years already.
And their 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 on write.
So this is the way you like basically you can have a lot of ideas
how to improve your database.
And not everything can be verified on thin cloning, but a lot
of ideas can be verified and in the isolated Postgres instances
and database branching is great.
For example, definitely everything related to query optimization
at macro level, we discussed it many times, working with plans,
verifying ideas, this is absolutely needed.
Think 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 Postgres for sure.
Automated experimentation and branching is essential part of
this vision.
And we have pieces already when companies start implementing
this.
So this works at GitLab, DBLab 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
So
Michael: did you see?
In this on this topic area of like branching, thin cloning, and
copy on write, did you see there was a recent post by Radim from
Boring SQL talking about a feature in Postgres 18 that I'd missed
that is like you can create database within Postgres and and
specify a strategy and that can use if your file system supports
Nikolay: yeah yeah yeah I actually I also missed I remember this
discussion on hackers mailing list, but I somehow overlooked it.
So it's already Postgres 18, are you sure?
Michael: Yeah.
Wow.
I haven't verified myself, but this blog post says so, yeah.
Nikolay: 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 1 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 the case of DBLab, you can perform major upgrade
of clone.
Sure.
And test.
Here, it will be not possible because it's a single instance.
Although, working with like ideas how to verify indexes, to tone
tuning, this will work for sure.
This is great.
Michael: Yeah.
Yeah.
And baked into Postgres already, that's super cool.
Nikolay: Yeah, well, that's cool.
That's cool.
I need to revisit this somehow, I overlooked as well.
Great, great.
I think what we like, what we see in the future, more tools which
will automate experimentation for optimization, performance optimization,
and instead of like throwing 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 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 close on thin clones, 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.
Michael: 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 Yeah,
Nikolay: and the pieces Some basically like building blocks we
have.
Yeah, the final like the whole solution is yet to be built.
I agree
Michael: Did you see much progress on the vector search side
of things this year?
Nikolay: Oh yeah, I remember I started here looking at turbopuffer.
We found that we also had an episode.
So it confirms it's a great successful year for Postgres, but
also for PostgresFM podcast, because we had great episodes covering
areas which are important for users, right?
So, turbopuffer were great, and this approach with vectors in S3,
and you know S3 also now has a vector type.
I revisited recently and it's outside of Postgres, but 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 know
there's turbopuffer.
So a combination of Postgres plus turbopuffer, it's kind of like
I saw trends 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 pgvector is going to stay.
I wish it was in core.
I don't see how it's possible now But
Michael: I've had conversations about it there I haven't I haven't
been looking closely, but I might have missed them.
Have there been conversations about doing something in core,
like, formally?
Nikolay: All beginnings of conversations were just interrupted.
Like, this index type is not normal because it's answering different
results, right?
Because it's due to its approximate nature.
Basically, it's not deterministic, right?
And this brings new challenges.
So to be considered as a core thing, but in my opinion, it must
be in core to be developed properly and be considered as something
like super standard.
Although, pgvector 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 1 billion
vectors problem yet.
All those who claim they solved it, I think they are lying.
Michael: It's like the spacing, right?
What do they call it?
Nikolay: They say, you know it's bad, but you need to basically
cluster, not cluster, partition it, right?
So it's not 1 index, it's multiple indexes.
Like key spaces, namespaces, you call it, use any word.
But what it means is that you don't have a single index which
supports good OLTP scale, OLTP latencies, meaning it's definitely
much faster than 1 second for a single query and has covering
1 billion vectors.
Nobody does it.
S3 including, right?
S3 also like has maximum, I don't remember, 50 million or how
many vectors in 1 index supports.
So anyway, this is unsolved problem and it's unsolved, I think,
everywhere, not inside Postgres 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.
PgDog also showed how to combine sharding and pgvector, right?
So you can have multiple Postgres instances and so on.
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 and
if you combine with sharding maybe you are fine but I haven't
seen a single 1 billion scale index which would work.
Michael: — Why does it matter?
Like, if I have a partition table, that's not, that doesn't have
a single index on it.
— Right.
— So why does it matter?
—
Nikolay: Complexity.
If you talk about regular indexes, having a few billion records
in a table is not a problem at all.
And latency will be amazing if you have index-only scan, or just
index scan.
If you don't have these rows filtered out, right?
But when it comes to vectors, if you have 1 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 OLTP.
It cannot be, it doesn't meet OLTP standards, which we know like
100, 200 milliseconds maximum because of human perception.
Michael: Yeah, but not for search.
Nikolay: For search including.
Search is
Michael: 1 of those use cases where people are willing to, okay
fine.
Nikolay: No, no, no.
Are you okay if you Google something and you need to wait 10
seconds?
You're not okay.
Michael: Yeah it's a good point actually.
I think Google is probably the proof that search is important
to be fast.
Nikolay: Of course.
Because That's what they've
Michael: always focused
Nikolay: on.
People need it everywhere.
Like you have mobile app, you type something, you want to move
it very fast.
If it's below 100 milliseconds, it doesn't feel slow.
That's great.
So we have human perception, which defines what multi-piece.
Michael: You don't need to convince me that performance matters
and it's good, but I was just thinking that might
Nikolay: be.
Search is considered part of application.
It's not like we have such system Okay, let's 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 are working on right
now They can wait a minute.
No problem Or if it's Like bi report this actually means we overlooked
1 trend as well Analytical thing right so yeah market iceberg
and and DuckDB and how to bring all this and Postgres couple
of a few companies played good game and And we are acquired
Michael: Yeah, I would say 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 1 of the biggest analytic databases companies in the world
acquired what was 1 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's it came about probably because of
their progress on the analytics space.
Nikolay: Yeah, so obviously Crunchy Data started to work with
analytical side of Postgres, which was always considered weak
and achieved had great achievements and got acquired for a quarter
of 1,000,000,000.
And Neon, although it's, they didn't play a lot with analytics.
They did something with DugDB, as I saw, like, they tried here
and there things, but still it was purely an OLTP thing, right?
For, with branching and super fast point-in-time recovery and
serverless, everything.
And got acquired by Snowflake for 1,000,000,000.
Michael: Databricks.
Nikolay: Oh, Databricks, yes.
Snowflake, Crunchy, Databricks, Neon, right.
And they are, as we see, they both work to bring solutions which
are combined, like analytics plus OLTP and everything.
We could consider this also from a different angle, but this
is also a game to conquer like enterprise Postgres topic, right?
Just coming from a political perspective first.
And it's interesting.
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.
Michael: Oh, interesting.
Nikolay: To be higher 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?
Michael: 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
5 years, quite often those things don't align.
So it's really difficult to assess these things within, you know,
6 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 really hard to tell this close to it, which of those
is gonna be the case.
Nikolay: Yeah, in this context, I would like to mention also
a couple of companies which I like what's happening as well.
Like you can see like some negative sides, but you can see a
lot of positive sides in everywhere.
For example, Planescale came to Postgres ecosystem.
And they resurrected the old topic, which some people tried to
bring life into.
It's let's use local NVMe disks.
That's great, like absolutely great.
And they also, like I like what they do a lot, in a lot of 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 Vitess, which was created before PlanetScale and
that's it.
Michael: And maintain it, I think, yeah.
Nikolay: Well, yeah, yeah, that's, that's, that's of course,
but what else?
So anyway, but I like a lot 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 MySQL ecosystem was merged
to Postgres ecosystem and this is great.
Like I've different points of view and so on and This feels really
great and this year achievement, I think, in terms of Postgres
ecosystem development.
And another is, of course, Supabase, which is pure open source.
They bet heavily on open source and Multi-model and OrioleDB
and all things.
And this is their, I think, strategy to do things open source.
And their growth is...
Well, and not just, I would
Michael: say not just open source, but with permissive licenses
Yeah, I think it's I think that's incredible is I think it's
something that people don't really fully appreciate of how important
it was for PostgreSQL to have a perm, not just an open source
license, but a really permissive open source license.
Nikolay: Yeah.
Like Apache, MIT.
Michael: Exactly.
Exactly.
And.
Nikolay: Postgres license.
Michael: Yeah.
All of them extremely permissive.
And, And I mean, they're not copy left.
They're not AGPL.
Like they're actively trying to encourage collaboration and allowing
people to use it for commercial purposes is is you
Nikolay: know, common misconception here at GPL and AGPL, 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.
Michael: 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,
Nikolay: is...
Freedom, yeah.
Michael: Yeah, and I think it's good for everybody, it's good
for the rest
Nikolay: of us.
Unprotected freedom, this is how you can see it.
Because somebody can clone and create commercial software based
on that, easy.
Michael: 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.
Nikolay: It's off topic,
Michael: yes.
I apologize.
Nikolay: I wanted to credit them for that.
Michael: To wrap it up,
Nikolay: I just wanted to mention that Supabase growth is 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?
Many platforms grow, grow, grow.
And Postgres became, it's obvious this year, Postgres is default
database for vibe coding.
This is 100% Like as of end of 2025 it's so and Supabase growth
and Neon mentioning that 80% or something of databases created
are created because of vibe coding and AI agents and so on.
Michael: On Neon yeah.
What about Replit?
I actually didn't finish reading the what did you see the post
that Mike was responding to?
Is that Postgres?
Nikolay: Yeah well yeah it's Postgres yeah so Postgres everywhere.
Michael: Yeah nice.
I would say the thing about Supabase and PlanetScale 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 early MongoDB
that people are actually excited to use it, developers want to
use it, they think it's an easy thing to do.
You know what I mean?
It's that kind of like, it's cool all of a sudden.
And I don't know if I've been here long enough that to remember
the last time that it was actually cool so
Nikolay: I don't know yeah let's mention friend Pashol who left
Postgres world but he says not fully left also had an episode right
yeah yeah and and joined MongoDB, so that's also interesting.
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.
Michael: 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
gonna be on Postgres, and I think that's really healthy for the
ecosystem.
Nikolay: Yeah, yeah, yeah.
And also challenging because people don't realize what is it.
Michael: Fair.
Nikolay: What do
Michael: you mean the vibe code is?
Nikolay: 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 Supabase they
expose whole Postgres you can play with tables and so on.
Some like Gadget, for example, they expose concept of indexes,
but they don't let you to connect to Postgres directly.
So more like vibe side.
So different levels here.
It's so cool.
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 1 hand, on another hand, demand for good maintenance,
operational tools and practices and Methodologies 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.
Do you think, but
Michael: don't you think their shelf life is also reducing?
Like,
Nikolay: of course, most of them won't survive.
Yeah.
We're just experimenting, wipe coding, like throwing out later,
but some of them will survive.
They need a path for good health.
That's why I think self-driving is also a 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.
Well, again, like trend is obvious trend started here in 2025
Michael: Okay Wait, well, but yeah I think that it would 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 gonna 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 gonna be tens of thousands more of those
really successful huge companies But they might get there 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 a board of magnitude more them.
Nikolay: My team feels it really well.
Regular, 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 we how like
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.
Michael: And you don't think they'll hire, like, you think they
won't hire for those, like, specialties once they grow?
Nikolay: 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 already should be done a year ago.
Michael: But it's not too late.
Success generally brings enough money to solve these problems.
Like hire a good consultancy to help out.
Nikolay: I'm not joking.
I heard let's migrate to a different database system maybe.
Michael: Okay, so you think for Postgres is survival?
Nikolay: It's a challenge.
Yeah, yeah.
So like, if database cannot scale without like, too much attention
and too much manual work, it won't survive its hyper growth.
We had this term hyper scalers.
AI is going to bring new level of hyper scaling.
So we need to adjust.
Thank you so much.
Let's keep, let's say happy Christmas, happy new year to everyone.
And let's continue new year with all these trends and good Postgres
health, good Postgres 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.
Michael: Absolutely, likewise.
Thank you everybody.
Thank you Nik.