[00:00:00] Nikolay: Hello. Hello, this is episode number 60. My name is Nikolai and, to give it with me today is Michael, as usual. Hi Michael.

[00:00:09] Michael: Hello, Nikolai.

[00:00:10] Nikolay: And we are going to talk about what, serverless or separation of storage from compute, or how do you name it?

[00:00:19] Michael: Well, we had a, I think we had a really good request, and they used the wording, decouples compute from storage. So maybe, even though I do like the short titles for the, uh, for the images for this podcast, uh, I think that probably is more accurate to what we want to talk about.

[00:00:34] Nikolay: Not serverless.

[00:00:36] Michael: I mean, I think serverless is part of this, but some of the other providers, I'm not sure they, I think there are pe, there are providers decoupling compute from storage that you probably wouldn't class as serverless.

[00:00:48] Nikolay: Okay. I am lost in this, new, beautiful world. I'm an old schooler and I have my skepticism, but I also try to keep my mind open. So I'm trying to understand, uh, what's the hype about and what is it? Why do we need it? And so on. So where should we start?

[00:01:12] Michael: Great. Let me, can I read out the question we got, because I

[00:01:15] Nikolay: Yeah, good idea.

[00:01:16] Michael: it quite, quite in quite practical terms and says, what do you guys think about all these products that take Postgres and transform it to something that decouples compute from storage? For example, r d s Aurora. Google Cloud, alloy, DB Neon, et cetera, and then the follow up.

So that was, do you see something like this landing upstream in the medium term?

[00:01:36] Nikolay: To itself.

[00:01:37] Michael: Yeah, exactly. I'm not a hundred percent sure what they mean by that, what, like how that would, exists, but I think they're quite interesting questions and they've basically asked for our opinions, I think on those providers.

and anything else we class in a similar. category. I think that's like we've each had customers on at least one of those. I know Aurora DB's the oldest, so that's the one I've seen in the wild. But yeah, I've definitely read the marketing materials of the others and seen people playing around with them.

Seen some people excited by various aspects of some of them. So I think there are some compelling, at least marketing arguments and it's an interesting future ahead. And then there's also the question of which parts of this, if any, could be upstreamed is, for example, I know the Neon folks are working to make neon as little of, uh, fork as possible.

You know, trying to get some of the code upstream so that what they do is less custom.

[00:02:35] Nikolay: Same as a reality db,

[00:02:38] Michael: Yeah, exactly. So I think that that's how, that's how I interpreted this question. So, yeah. How does that sound?

[00:02:45] Nikolay: Yeah, that sounds great. But let's discuss, like what is it,

[00:02:48] Michael: So

let's talk about what some of these. Providers offer or at least claim. And there's a, there's a few things that, I'm not sure about all of them, but the, the things I keep seeing come up are around performance, around scalability. I. And they're around things that aren't necessarily always that easy to do in Postgres, like for example, major version upgrades.

So things that you can do potentially without, the same consequences, uh, or the same downsides. So yeah, again, I'm not, I've seen some good arguments that maybe the performance claims are slightly overstated by some of these providers, potentially not even. Case once things are tuned differently, um, there's a really good blog post, for example, by the team at MOPS that I found interesting, comparing

Aurora,

[00:03:39] Nikolay: let's

discuss like, yeah, what is separation? So if I keep P data on e C two on e b s volume, which is network attached to cloud disk and have e c two instance, I can. Upgrade to instance, just, uh, very quickly, well, not maybe very quickly, but I can do it if I, uh, run containers on that instance.

Or maybe if I, have a layer or something. And for example, I get metal and I touch should be s volume. And on metal I have multiple, you know, I, I attach many volumes. And then I have using firecracker like micro VMs, which uh, It can be provisioned very quickly, and then I distribute load of my huge instance among these small, smaller guys.

I can change this microwave very quickly. Is this separation? Why do I need to think about any post changes at all? I have a network attached. Volume storage is already separated. What else? Like. Why, why, why? Like, what are we talking about? What kind of separation This is the pro, this is the question. What, what do your, materials, tell you?

What do they tell you? What, what

do they tell you? Yeah.

[00:05:00] Michael: A lot of them gloss over this quite quickly, so I'm not quite sure like what would count and, and maybe that would count by strict definition. But I think a lot of these providers, like let's say Amazon with Aurora, Google Cloud with Spanner and Alloy db, those two, for example, have invested a lot in their cloud, infrastructure and specifically storage. So they've got very good at replicating storage across regions with redundancy, with, with being able to, you know, put data close to users. Um, and that part of what they've invested in is at the disc level. You know, that's the storage layer now. They've had interfaces to those things that aren't Postgres in the past.

Like Aurora for example, started, well, I dunno if it started, but it definitely had my SQL compatibility before Postgres compatibility. So it's added Postgres compatibility later. So that for me is like a, is one way of looking at it. So they already had this, this storage infrastructure that they had invested in and they wanted to put a different interface on top so that they could support people's applications that already had.

[00:06:12] Nikolay: right. But what I understand about this approach, they store my data directory in object storage. So SS three,

right? And then we have, we need to, but it's, if you just attach, there are some, there are some projects like that can. Uh, if you, you take your S three bucket and then you attach it as like, it looks like a disc in your Linux.

It's possible to do like, refuse or something like it's possible, but it'll be slow and bad and so on. Of course, in this case, if we want to, uh, to keep our data directory in SS three and we need to work with it, with good performance, we need also to cash it. So we need, uh, to cache it in on regular BS volume, um, and, and so on.

And I, as I understand this is what, uh, Aurora and Neon do. Like, I'm maybe might be mistaken here, like architecture. Like we, I'm not an expert here at all, but I. Let's discuss about features for users. Of course. Definitely. Like if, like bottomless, serverless autoscaling, what, what kind of features we have branching as well, right?

So we separated and, , Postgres, I remember Aurora claimed one of the biggest benefits they achieved is lack of, the need to. Care about checkpoints. So checkpoints are fully detached from our compute node. They, they're done in background. We don't care about them. So we don't have penalty from checkpoints anymore.

We still have vacuum, unfortunately in Postgres, uh, Aurora Postgres, but we don't have checkpoints. And this is good in, in terms of if you have, uh, uh, right heavy workloads, it's much better. So performance Doesn't drops when checkpoint happens. latency doesn't spike. Right.

this is the benefit. What else?

[00:08:06] Michael: Well, interesting. I actually didn't see that in, in the, at least on the front page, so that's super interesting.

[00:08:12] Nikolay: Aurora. Well, it was the original presentation on all Postgres conferences from, uh, grant McAllister, engineer from Aurora r d s team. And he explained it very well, like I, I commend it for, even for those who don't, , use Aurora, because he explains problems with checkpoints and full page rights and details, and then how they solved.

And not all technical details are clear there, but it's good for understanding of Postgres. This, these talks are good for understanding Postgres as well. And it was like five years ago or so. And yeah, so they don't have checkpoints. They eliminate it. They don't fully eliminate them because they need to replay walls for, and so like, they need to take care of checkpointing still.

But it, it's hap as I understand, but it's happening fully behind the curtain. So our compute no, doesn't see any, overhead of

checkpoints, I think by this moment, experienced engineers already understood that we are not experts in this

at all, but we're trying to understand this. Again, I'm, I'm quite skeptical. I see that, it adds complexity a lot, this approach we definitely can discuss further and we will, but we have the question in the end.

do you see it'll go to up upstream to publish? Let me explain my opinion. Right, right now, I think yes, it can, it has chances, but only after auto, however, Pooler and other such things. Which are waiting to be included to Postgres engine itself. Because, for example, a auto filler, it's all about, uh, multiple node, uh, cluster.

So you have primary, you have a replicas, and all auto fill is essential there. Postgres, has improvements. For example, we discussed recently in lip pq, uh, fresh improvements in posts 15, I keep forgetting. Or 14, even this, uh, load balance feature. when you connect, you can specify how to load balance so these features exist, but it's kind of like, making sock better working for. Other tools like for Pat, for pati, we, instead of including, uh, whole feature into the engine, the engine can be adjusted. So this feature which is implemented externally using additional tool engine can, can be adjusted to work better. same as with backup tools. Uh, there are improvements if there is a p i for backups now and so on.

Maybe it means that PG Brest and w g will be in core and future somehow. Maybe not, still not clear to me, but what I'm trying to say, this separation might be seen as some adjustments, slight adjustments of things in Postgres, but I don't see how it can come as a whole thing into Postgres in nearest years.

Uh,

[00:11:11] Michael: I, I think I understand. Are you saying you don't think it should be included before those things, or you don't think it's possible? It makes any sense before

[00:11:21] Nikolay: Some adjustments can be made to separate storage from compute. For example, we know that, E B SS volume can be attached to multiple VMs. If you use special file system, some Amazon file system, in this case, you can attach a BS volume to. Multiple is two instances, and this is, this thing feels already less separation.

You can have, I think they have snapshots. I'm not sure about full fledged branching and so on. yeah, maybe if you have snapshot and you create a new E SS volume, you, you already pay for two BS volumes and this is not as Aurora or Neon. Have, they have ability to have think loan. And, uh, you don't pay. It doesn't, in increase the storage bill twice when you do it in this case, probably it does.

I mean, in the case of this elastic, file system, Amazon, I don't remember if this, this file system which supports, attaching. A base volume to multiple instances. So money is very important aspect here for sure. But how come Postgres can support any of these things? I, I don't see in the nearest years, I don't see it at all.

[00:12:31] Michael: The only way I see it happening they even said in the medium term. So I, I guess it depends what you mean by that. The only way I see it happening is if some of these providers, like your neons, get a lot of support for contributing what they want to do, maybe as hooks or maybe maybe making things extensible rather than it being in court.

So it might be, I don't know if that's the same thing kind of in practice. I. But that's the only way I could see some things happening. I can't see the current Postgres core devs prioritizing this as a feature. Partly as you said, 'cause there's so many other things competing for attention, and actually it's not that many people in the grand scheme of things that contributing to core, it's they've got relatively limited bandwidth and lots of good, important things to be working on already.

[00:13:16] Nikolay: All right. so this, this answers the last question, but let's talk about, again, let's, let's talk about, this.

[00:13:22] Michael: So what do we think about those products? I can tell you what some of my friends, fellow founders, other people while they're picking Aurora, for example. I'm not sure it's always the wisest decision for smaller, businesses, but they like the appeal of auto scale up without downtime, without a lot of

[00:13:40] Nikolay: Is it really without downtime? Because yesterday I tried neon and I, I wrote them. So like I had the pitch bench running on Autoscaling Neon instance, and every time it scales, uh, I see errors. So maybe it's not polished yet, but this is hard, right? But I also, I don't understand why we need to separate total scale again.

Like if this is, breaks my mind, like again, like I am old schooler. What if, well, like, it's, it's funny but, uh, considering the best volume and the instance in the cloud, it's already old school approach, right? like 10 years ago it was quite new thing compared to on premises stops. So I have a set instance, I have a best volume and I can quickly provision.

In other instance, imagine if I have pitch bouncer, all connections go through pitch bouncer. I have a certain instance, what if I, issue pause to connections and quickly reattach my base volume to a new instance and then resume and it has already more C P U and M.

[00:14:50] Michael: Yeah, but I think you're skipping over, like having the operational confidence to do that and the experience to know that you, you can even do that, but that's not typically how people are self-managing Postgres. And it's

[00:15:03] Nikolay: Of course. No, but I'm trying to ask why do we need to, to cut, Postgres, guts, I mean to replace legs and so on. I mean to it, it's, this is a common saying, like, uh, Aurora Neon, they replace the bottom half of Postgres storage related Half they rero rewrite it. Why do we need to rewrite it?

[00:15:24] Michael: Good question. So there's a, I think there's a few things. I think you mentioned cost, and there's an interesting argument for, I think people see Aurora, at least I'm not, and May and Neon, actually, this is one of their main selling points. There's a bit more pay as you go, so the cost increases slowly as you grow.

Instead of, if you're on, let's say r d s, you go up in, in jumps, right? You go from a smaller instance to a medium one to a larger one. Those are, those aren't necessarily, well, I

[00:15:53] Nikolay: Then I, I, again, I can build, uh, managed service. For example, support base might go this route. I don't know. we can run, , it on, uh, larger. Like metal instances in, in a w Ss, and then we can use firecracker to provision micro VMs and then fi find. We have fine control about, how much we can run.

We can even run single VM in multiple containers and, uh, use quotas for containers in terms of, uh, C P U and ram. It may even in

[00:16:25] Michael: So, so you are, you're saying these things are possible, but that's not what people are choosing between, they're choosing between. Amazon, R d Ss regular Postgres and Amazon, Aurora Postgres. And when you're looking at that,

[00:16:39] Nikolay: r d s users can choose right.

[00:16:41] Michael: yeah, So this is the, the choice in front of people that want a managed service.

And I think you could argue, I think with, with some merit that Aurora is even more managed, so they'll do even more, even more things are possible for you, maybe with a few more limitations.

[00:16:57] Nikolay: Aurora is definitely, uh, has Aurora has definitely has some good things that could go to r d s as well. They could go to open source. Area, for example, um, plan management extension and, but obviously a W Ss decided to keep it only for Aurora for competitive reasons. So this is clear to me. So, so this extension doesn't deal with Aurora special features. It deals with regular, you know it very well, right?

[00:17:27] Michael: Yeah, the query

[00:17:28] Nikolay: the name. Right. Right. This is good thing. Uh, and, uh, I, I wish it was open source,

[00:17:35] Michael: so for anybody that doesn't know, that's like, I think it's a feature that's come from, enterprise databases, like your Oracles of this world. And if you've ever, ever had a plan flip a query, plan flip, for example, data's grown in size and it's flipped from quite an efficient plan to one that's no longer efficient because it thought.

Well, 'cause that plan now has a lower cost. Basically Aurora has a feature that allows you to avoid those flips with certain rules around how much lower the cost needs to be before you change from an approved plan, that kind of thing. So it's a very, very interesting feature.

[00:18:09] Nikolay: Which doesn't require, separation of compute and storage at all because it's only about the planner behavior.

[00:18:16] Michael: Yeah. But, but my point is that people aren't choosing. Com separate computer storage, they're choosing the product.

[00:18:25] Nikolay: Just , because of decisions of, uh, Amazon business guys.

[00:18:28] Michael: yeah. Right. So let's, but, but let's say Neon for example. I think that is much more clear cut. People are excited Bec I think, because you can start by paying zero. There's a free tier and you can start by paying very little.

[00:18:42] Nikolay: First of all, I think new on example, shows how, open source can get all benefits that non open source guys like you, by the way, try to hide from us. You understand the, the thought, right?

[00:18:58] Michael: go.

[00:18:59] Nikolay: So,

[00:18:59] Michael: Go on.

[00:19:00] Nikolay: so I mean, Aurora is like, it's positioned like as a replacement. Like it's for those who migrate from Oracle.

This is alternative. And, uh, we know, , Amazon itself migrated from Oracle to, as I understand, Aurora Postgres. And it's good, like great, and this is like serious Postgres position. But, , now noon is making open source. Version of the same thing. And my general thought those managed services guys who like are just, first of all they say, okay, we automate backups, ui, everything. Wait a few years open source versions of, it'll be maybe even better. And we already saw, like for example, good UI and so on. And it's open nature, so you can, we discussed it in previous episodes, self-managed and what I'm trying to say, like you can, if you don't go open, it's a mistake.

[00:20:03] Michael: Well, yeah, this is really interesting like as a commercial discussion. But I think there's also an interesting thing for, as a customer, if you choose Aurora Postgres for example, and start relying on the query plan feature, what are your options for migrating? You're, you're kind of stuck there until, there is an open

[00:20:20] Nikolay: a feature's, one of the features and I like eventually, uh, community will have this feature as well. Somebody will implement, uh, this, plan manager, In open fashion.

I'm, I'm quite,

[00:20:32] Michael: I think you're a hundred percent right, but, and I think Oracle, for example, are losing market share to Postgres, but Oracle still makes so much money per year. It's not like they've, they're going to zero really quickly. So it's, it's an interesting discussion. I think there's a lot of ethics and morality at play.

Like there's, there's a question of doing, you can, you can be open and have bad morals. You can be closed source and have good morals. I think we know where we both think Oracle are and where we think, think some of these newer providers are.

[00:21:00] Nikolay: It's not fully clear yet for new providers because they're super young yet, and for database like a couple of years is nothing.

[00:21:08] Michael: Yeah. And, and I think it is a bit different if you are a platform versus if you are a, like a gooey tool.

So, I've mentioned this to you previously, but the, the reason my tools closed source is because I don't see another business model for it. I can't, there's not much support for it, and the UI is most of the value. It's not, there's no service that adds a lot of value. It's, it just, it's just a ui. So if we made it open source, anyone could host it for free and there'd be no need to

[00:21:36] Nikolay: great. It'll give, uh, it'll give warranty that it won't, , die. For example, if you or new company, or if my company is closed, uh, our tools, like if we don't open source them fully. It'll be hard for people to continue using any of them. And, uh, this applies to you. This applies to me as well. By the way, I promised last time I'm going fully open. Everything will be open. I'm still thinking like, yes, we will do it. We just released 3.4 database lab engine data, DBL App Engine, now it's called, and uh, 3.5 will be fully Apache 2.0, including everything we. Try to keep only for paid customers.

No, we will have everything open and I suggest neon to, to think about this approach as well because they keep some pieces not open, you know, and this is for sure strategic move and so on. So control plane automation, not fully open. And uh, this is very difficult decision if you have. A lot of money raised.

Right.

[00:22:43] Michael: Yeah. Well, even if you, even if you don't have a lot of money raised, if, if your ambition is to build a business around it versus your ambition is to build, you know, if there, there were people in the past that have been in, but there were people in the past that have built. Databases because it's academically interesting to them.

And if that's your goal, making it as open source as possible makes a lot of sense. But if your goal is to build a business, it also makes sense to prioritize commercials like I do on like, it's interesting

[00:23:12] Nikolay: Uh, in this, in this area, I, I recommend listening Michael Stone Breakers speech when he received tour reward, right. So, yeah, he compared, riding a bicycle, uh, uphill, downhill, and he has a lot of experience in both purely academic products and like academic research projects and also building companies , for profit companies.

So this is interesting area. But if you want your thing to live longer, , you need to make it open. I think we moved away from the main topic.

[00:23:48] Michael: Very much so. Let, let me quickly go through a few other things that I think people might want to read up on or watch. You did, you did a good interview, I thought, with, somebody from Neon. It was,

yep. On Postgres tv. I'll link that up in the show notes. And another one with somebody from Cloud Spanner about their, Postgres

[00:24:09] Nikolay: Partial support of Postgre syntax. Mm-hmm.

[00:24:12] Michael: which is actually something I did want to cover here.

That a lot of these systems are Postgres compatible, which I mean, it makes sense, right? Because it's not, they've literally taken out the storage layer. You probably can't say any of them are Postgres.

[00:24:27] Nikolay: None of them are posts.

[00:24:29] Michael: Well, yeah, , but if you read Neon's landing page, you'd be very forgiven for thinking it was right. Like it says serverless Postgres, everything is Postgres, Postgres Postgres. So what I meant is if you are, if you're looking into these systems and considering using them, check what they mean by Postgres. Compatibility will what you want to use work? Are the extensions you want to use available? Is the syntax you want to use available?

[00:24:52] Nikolay: What kind of weight events they provide because Aurora has their own, uh, its own specific weight events. By the way, I still consider weight event documentation of r d s and Aurora r d s is the as the best. But have you seen for. For post 17, probably already, the dictionary of weight events will be provided as a system view, like select start from pg,

[00:25:16] Michael: Oh, great.

[00:25:17] Nikolay: pg weight events or something, and you see with explanation list of events with explanation. So it's good not only in documentation, but right in your posts.

[00:25:29] Michael: Well, hopefully in the documentation too, but if not,

[00:25:32] Nikolay: The documentation has it, but it doesn't, it's not as, uh, well explained as, as a r d s documentation because it, it's all, it's, it's very like a short, like this, wait event and wait event type, and just one sentence and that's it. But r d s has whole page with practical pieces of advice.

[00:25:52] Michael: Yeah, I remember now and I remember not realizing that the first time I saw the page, because I didn't realize you could click on each,

[00:25:58] Nikolay: Yeah. Yeah. Well, it's a UI issue. UX issue in, uh, r d s docs. But, , I mean it, if it has different weight events, it means for advanced users, it means, uh, it's managing will be different, right? Slightly different. So it's already not positives, it's deviation.

[00:26:16] Michael: And this is what I mean by do your research. Check that what you want, like just don't assume that if you're using Postgres already or if, you've used it in the past and you want to use certain features, don't assume they'll be available on these providers. Check. and then the last thing I did wanna bring up, which is in this area, Was the feature timescale announced?

So timescale I'd argue is

Postgres. But, but yes. But that on Timescale Cloud specifically, not, I mean, it kind of makes sense that it would only be available in the cloud option. They allow you to transparently, or, sorry, without, without changing how you query the data, move certain. Chunks, which is so well partitions, but they call them chunks, to object storage on

SS

three.

And the arguments they give for it are reducing cost. So that's an interesting, maybe that's like the, the true root, uh, argument is that

[00:27:14] Nikolay: Here I see

potential. Yeah. Here. Well, of course if you first, first of all, if you SS three is like virtually infinite, e b s volume is always limited. Even it's like, I dunno, I don't remember last, new limits, 64 terabytes, or maybe already more than a hundred. I I, I don't manage, uh, databases more than, a few dozens of terabytes.

So I'm not that experienced. I don't have a hundred terabyte

Postgres instance yet.

[00:27:47] Michael: but yeah.

[00:27:48] Nikolay: I think it'll happen in the next few years actually, but not yet. So, offloading data to S three is very good. Actually, at the SS project had an issue in their o o opens at the S for Linux. They had an issue discussing this feature to transparently move data to S three.

And they developed it. I mean, Delphix developed it, but they decided not to open source it yet, unfortunately. But I think this is exactly where there is some potential for Postgres. Maybe to support something, to move some partitions to object storage. This is interesting idea.

Or to upload them to different machine. You need to think about consistency checks here, right? And so on. This is opportunity for Postgres itself to to develop some universal solution, which will work with various clouds and maybe even on premise, and will help you to have this bottomless feature. This is, this is a good example because it does, it's doesn't require to redesign half of Postgres,

[00:28:51] Michael: Mm-hmm.

[00:28:52] Nikolay: but it requires some redesign at least because if you moved it and then suddenly you, we know S three, if you don't mark some check boxes, it's very reliable in terms of, it doesn't lose data, but it's not very highly available as, uh, a B Ss volumes, especially like regional.

And so on are so you. They might be not available and you will see like some corruption errors, like I Postgres cannot read some partitions and so on. And this should be handled properly. Properly if you move data to a three because.

[00:29:25] Michael: Yeah, I, I agree. I just am struggling to understand how Postgres could cont like, bear in mind that's quite, quite provider specific,

[00:29:33] Nikolay: I just see it's easier problem to solve and, and beneficial for wider audience, not only a w s users.

[00:29:40] Michael: Yeah.

[00:29:41] Nikolay: you, you can install S three as mini project. You can install it yourself, I mean, to build some data center and so on. Cloud REITs, right? So those who migrated back from clouds to like, like we know like base camp, right?

[00:29:56] Michael: Yep. I'm not, by the way, I'm not sure they moved the S three back. I think that

[00:30:00] Nikolay: Who knows, like, but I think this wave is obviously starting to grow for those who want to optimize, budgets.

And in this case, if you know, you in Postgres, you can mark some old partitions to be stored out of your hot disc, which is limited and quite expensive and so on. Maybe even to disc. Well, you not, yeah. Now already, now you can move partitions to, colder disc if it's on the same server. It's all a very old approach.

Uh, and you can automate it probably, and so on. This is some opportunity here and you can achieve this bottomless feature. I want to petabyte database. Maybe I don't want to raise data.

[00:30:41] Michael: I mean the on timescale, you've got the double benefit of it, supporting compression as well,

[00:30:46] Nikolay: No, that is different

[00:30:48] Michael: just, yeah, but just for completeness, I, I, I guess the, the main trade off then is read performance. So you've, you've moved it to co uh, to SS three for cheaper storage, but if you do read it in future, presumably your, your queries are gonna be quite a lot slower.

[00:31:05] Nikolay: Of course. Right. It's, it's quite a lot of slower. And in case of, again, if to remember Zetas, if, this feature someday lands into Zetas, uh, zes has, different types of cache. One is regular arc, a r c. It's like file cache, , locally on machine, but there is also a R C two ARC two, which allows you to, for example, hip analytics.

They had very good article like five years ago, so, so they. Wanted very good performance. , they wanted to use, uh, local ephemeral and VME disc. I think it was time when the BSS volumes were not in VME based, not nitro, architecture. Now they are, but that time and actually local discs will be always faster.

Definitely. But they are humeral. If you restart, you may lose data. So what they did, they used the best large BS volume slower. But large and reliable. So they, if, , restart happens, you don't lose data. And using EAFs ARC two, they put, , cache. On local, ephemeral in the i, smaller, very fast and also ephemeral, meaning that you can lose them, but you can rebuild this cache, , transparently automatically the device will do it for you.

And this also sounds for me, like separation of cloud and compute. Imagine if this happens, like if the festival start working in the same way with object storage, like SS three infinite storage and SS three and local caches using ARC two. A very good feature and you don't need to rebuild Postgres to you to benefit from it because Postgres relies on underlying file cache as well.

So like it's working up on upper level. Very interesting. So let's maybe try to wrap it up and what are the main benefits for users which this separation claims to provide? First is, Like serverless or faster change of auto, you serverless auto-scaling or no?

[00:33:13] Michael: So, I struggle with definitions, to be honest with you. My understanding is there's a couple of features that serverless that people love. One is scale to zero, so if you're not using it, you pay nothing

[00:33:25] Nikolay: This, this is, this is, this doesn't require any changes. You just need the proxy, like maybe smarter p bouncer, which will, , start your node and fi. You need probably firecracker to start node faster. So that's it. Why?

[00:33:42] Michael: I don't, I don't mean serverless Postgres, by the way. I meant serverless anything. That's my understanding. And

[00:33:47] Nikolay: but scale to zero doesn't require separation. I mean, a best volume already separated. Again, like I don't understand, sorry, like I don't understand scale to zero part. Okay.

[00:33:57] Michael: regardless. I think it's clear if we want to go into any more detail in any of these, we're gonna need to invite somebody else on to talk to or learn a lot more about it ourselves. And I hope that's answered the question for the person who requested this somewhat. That's, that's what we know. And, and I also think if you are a general user of Postgres and you don't have any problems, you don't need to worry about any of this.

Like there's, I don't see any, reasons why we can't work on. Like regular post. The reason we don't know that much about this is 'cause most people aren't, most people don't need this.

[00:34:30] Nikolay: let's list all the things. So on the scale to zero, good. Understood. I, I, I am not convinced, uh, we need to rebuild half of Postgres. I think it's achievable with regular Postgres. It's just a matter of how fast you can shut, shut down is not important, but how fast you can start. I. Your compute part and that's it.

This is the main part. Postgres does need changes. I maybe I'm missing something again, like my skepticism is not final. Like I, I keep mind open. I'm trying to understand. Second, is this bottomless feature we just discussed, right? So like limits are much higher. You are not limited by single e s volume anymore.

Because you use S three, like a lot of stuff there. Good. And again, I just described maybe there are chances to achieve this as timescale did actually, uh, already you with, you don't need to, uh, again, to rewrite a lot of posts. Maybe we will have it, for more cases, but it's a good feature. I think sec and third is probably database branching, which, both.

Well, new one has branching. Aurora has, they have only think cloning because what was different difference is simple. Think cloning plus ability to commit or like to make a snapshot and then to claim. Now you can start new clones from, from that point, this is already branching. At and Aurora, they, they has only as understand, uh, neon has full fledged branching.

K P I, not, , really close to gi gi, but very like full fledged. So my big concern about their implementation, that they provide budget benefits only for storage parts. So if I run 10 clones, I pay for 10 compute compute instances, and this means that they close doors for good CI testing. Both products.

I want

same bill. I mean we discussed it. I want same bill for my C I C D pipelines. If I run many of them. I don't want to have big O O of N bill. Where n is number of pipelines, I, I won big O of one constant price. And this is what we achieve here at the first wave we've developed. So again, like maybe, and we don't replace Postgres. Postgres is the same. We just replace file system.

[00:36:52] Michael: I think if you want a constant bill, serverless is not for you. think that's fair to say.

[00:36:58] Nikolay: right? But what sounds appealing is scale two zero. And I'm exploring this, uh, to add this to database lab. I see how to do it. It so we, we probably will do it because if somebody is not working, especially for physical, approach, I just learned that unlike well Grest has, incremental delta restore. So you can sleep for many days when wake up and restore physically only delta or physical pitch data changes.

This is great. So you don't need to replay walls. It's very slow. If you accumulate three days of walls, replay will take some time for heavy loaded system. If we talk about to apply delta physical backup, that's great. So I mean, we, we can achieve very good behavior here. Of course new and are very good, but again, system is quite new.

So, and maybe fourth and final one of, of scaling. To both directions. Not to just zero, but between, like, by the way, do you know why neon compute unions are limited by seven only?

[00:38:05] Michael: No, I don't know.

[00:38:06] Nikolay: Yeah, that's interesting. Question seven doesn't seem big enough for me,

[00:38:12] Michael: Think they've started. I think with new systems, it's really sensible to start aimed at startups because if you like, the difficulty with databases is a lot of people choose it based on reliability, based on, you know, if, if we're talking about the storage layer of Postgres, that's arguably it's best feature.

You know, we, we choose our database 'cause we want it to be reliable and battle test it and it's got decades of, track record there. So if you're a new system with a different. Uh, underlying storage mechanism, you're probably best off aiming your service at people who can take a bit of a risk because they've got nothing to lose.

They, they're a new startup. They, they're enticed by, oh, it's gonna be free at first, or it's gonna be really cheap as we scale. So I, I think. It's a really smart strategy to go small first. I think super base have, have done the same, but as they get more serious, as those startups grow, they can move, they can gradually appeal to larger companies.

I think

[00:39:09] Nikolay: makes sense. Mm-hmm.

[00:39:10] Michael: Yeah. But equally, I dunno, seven's an odd number, right? Like what is I, I would've expected it to be a multiple two. I have no, I, they're very smart people running it, so I imagine there's a very good reason. I have no idea.

[00:39:22] Nikolay: Okay. But I want to ask about this auto-scaling. Uh, you as a specialist in, uh, query planning, what happens if. First of all, I, I hope they will fix it. I, I'm sure they will fix it. , I never tried it for, uh, Aurora Serverless. When autoscale happens, my PG bench shouldn't be disconnected, shouldn't experience errors.

And the same with my application, right? So it should be seamless. I think, , this. Can be achieved. And that's great. I, I mean, consider this is solved, but I wonder what's happening with query planner and the, uh, it's, settings because if we jump from one, uh, for example from one C P U and some Ram two, much bigger instance, plenty settings should be adjusted.

We have bigger cash rate, but at least I don't understand. But I think Neon is special and I'm sure they think about it. I just don't understand how I can manage my performance settings, uh, database configuration when it's quite unpredictable in terms of how big instance is that? Any given point of time or they think about this problem.

[00:40:26] Michael: Yeah, I guess it's stored alongside the I, I guess it knows when you're connecting to it. Like what it has available and therefore what its settings are. I have no idea if they control that for you or if it's, if it's configurable on a, like, can you set various limits as to what? Can you set your, let's say work mem.

Uh, can you say, when I, when I'm, when I'm down, when I'm provisioned to a small instance, set it to this and when I'm in a medium instance, set it to that, uh, high number and set. When I'm in large, can I set it to an even high number? My guess is they haven't got to it yet, but I actually have no idea.

[00:41:01] Nikolay: I would like to have more control and predictability than the unpredictable changes. And I actually know what maybe Aurora implemented this plan management feature exactly because with autoscaling and serverless approach, we need, , to freeze plants maybe. knows?

[00:41:22] Michael: Are we guessing? I have no idea. But if, you know, if you've been involved in that, that'd be really interesting to hear from you.

[00:41:28] Nikolay: Yeah. You, you mean me or listeners?

[00:41:29] Michael: Uh, anybody listening?

[00:41:32] Nikolay: I'm joking. So maybe it's time to wrap up. I think we just started this discussion. It's very interesting. I'm , far from understanding it fully, so I appreciate if people share their thoughts and we can continue another time.

But it's very interesting. I'm just an old schooler and I, I rely on, , things, I know how they work. Though I don't know how they work fully, always. So, yeah, I mean, Postgres itself, it's still, it's so huge system. You never know how it works fully. But, , I do my best. So yeah, please share this episode with others as usual.

And we need support as usual to subscribe in YouTube on all podcast platforms. And, , likes, comments. We appreciate everything. It helps us grow and see also, signals that it's interesting to continue.

[00:42:23] Michael: Nice one and thanks for this suggestion. We've had a few more suggestions as well, so we appreciate those coming in.

[00:42:28] Nikolay: Thank you, till next time, bye Night.

[00:42:31] Michael: Bye.