Postgres FM - ClickHouse Managed Postgres

Episode Date: September 18, 2026

Nik and Michael are joined by Sai Srirampur to discuss ClickHouse's new managed Postgres service. Here are some links to things they mentioned: Sai Srirampur https://postgres.fm/people/sai-srirampurClickHouse Managed Postgres https://clickhouse.com/cloud/postgresClickPipes https://clickhouse.com/cloud/clickpipeswalshadow https://github.com/ClickHouse/walshadowpg_clickhouse https://github.com/clickHouse/pg_clickhouseClickHouse PostgreSQL powered by Ubicloud https://www.ubicloud.com/blog/clickhouse-postgresql-powered-by-ubicloudHacking Postgres logical decoding sessions https://hacking.postgres.tv/topics/logical-decoding/ wal-rus https://github.com/ClickHouse/wal-ruspg_createsubscriber https://www.postgresql.org/docs/current/app-pgcreatesubscriber.html~~~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

Hello, hello, this is Posgous FM. I'm Nick, PostGSI as usual. And as usual, with me, Michael, PGM Master. Hi, Michael. Hi, Nick. And we have a returning guest today. The same guest we had two years ago maybe, but with different companies, SIE, X-Situs, X Microsoft, X, PIRDB, and now Clickhouse.

Hi, SIE, thank you for returning. Hey, Nick, Michael, great to be here again. Great to have you back. It's always pleasure to talk to you. always like visionary talk, I expect this again. Let's talk about like what are you doing in Click House, why Click House is doing Postgres now and how it happened and so on. Amazing. Yeah, I think just for the audience who don't know me, I'm Sai and I lead the Postgres efforts at Click House and prior to leading Postgres efforts, I was leading Click Pipes, which is

our native ingestion service, which makes it very easy to ingest data from various sources like databases, object storage, streaming sources to Clickhouse. And prior to Clickhouse, I was the co-founder and CEO at a company called PIDB. And at PIDB, what we did was we were building a data movement and an ETL tool with laser focus on Postgres, basically, right? So we wanted to solve this problem of any problem that involves like ingesting data into Postgres and out of Postgres, we wanted to make it very easy for customers. We just started with one use case, which is Postgres to Data Warehouse,

replication because that was a real problem. We could make money out of it, right? Like, I think that was the goal of it. That's why we started solving the problem. We did. We had like various like warehouses as targets and click house was something that we added and it took off basically. Since the time we added it like there was overwhelming response in the community and even click house as a target right came through the community because there was an organic head hub issue that was created and from there we added the click house target right. And since then, house ups and since then, house ups and this and then they reached out and we went through an acquisition. And at the time of the acquisition, there were around like a handful of customers who were syncing data from Postgres to Clickhouse

using Pardb. There were other sources like there were other customers, but for Clickhouse, it was just like a handful of production customers, right? And now PRDB is fully integrated into click pipes and it supports the Postgres CDC connector. It also supports like MySQL and Mongo CDC connectors. And for Postgres, there are thousand plus customers who are replicating data from Postgres to Clickhouse, use Postgres for transactions, use Clickhouse for analytics, right? And that's my story where the post acquisition, it has been like hockeystick growth. And now we move, I think, roughly around 500 terabytes per month from Postgres to Clickhouse using ClickPipes and PADB. And that was actually one of the motivations to start managed Postgres offering within Clickhouse because we were seeing this pattern. and yeah.

Let's pause a little bit because I think what's interesting here is that we have a couple of OSGGS companies acquired last year by analytical database companies, right, Snowflake and Databricks. And in this case, Posgis and Clickhouse, I think it's a great, interesting combination of two very open-sourced projects originally. Like both are majority of things are open-source. And I see it in like our customers. It's often the case, PostGIS is for LTP and Clickhouse is for analytics. So I guess this is where you manage to be with your plumbing business, right?

With PRDB. I love the way you call it plumbing business. Yeah, yeah. This is where we're all in, but you literally called it peer DB because it's about pipes and so on. Click pipes also like it's plumbing, right? It is. It is plumbing. It is important.

It should not be leaking and so on, right? Yeah. Absolutely. So this is a great combination of two, I think, great open source projects. And you entered Click House with plumbing, as I said, and then I want to understand the idea that Click House needs their own PostGus better, because originally I know Melvedov chose my SQL protocol originally. I know now it's like partially supported PostGus protocol,

but somehow Click House was a good fit for those who use PostGres, but it was not completely relative to PostGus. It's not really, it was very far originally. No, I think that totally makes sense, Nick. So the reason why we started managed Postgres within ClickHouses, if you look at it, right, currently there are tens of thousands of companies who use Postgres and Clickhouse together. Postgres powers transactions, Clickhouse, powers analytics, and basically they are using the right for the right job. And this includes very large companies as well, like Instacart, Cloudflare, GitLab, right, who use these two databases together to solve most of their data problems.

And this one is obviously they're amazing databases. They are really good at what they do. Second is the ethos, right? I think both of them evolve from that open source ethos. They have large communities around them. If you think about it, this year marks like 30 year anniversary of Postgres since the time it was created. And it also marks the 10 year anniversary of of Clickhouse since the time it was open source. Because of these reasons, we saw over the past few years, a lot of customers converge on this stack, which is Postgres and Click House.

And this is also reflective of the growth that PRDB and ClickPipes saw, right? Like from five customers to 1,000 plus customers, moving terabytes from Postgres to Clickhouse. So what we thought was like, this is becoming the de facto, like default data stack for the world, right? A lot of companies.

Why not we now manage both sides of the stack, which is Postgres for OLTP and Clickhouse for analytics, and bring them closer to make developers life super easy, right? So what we're doing, I'll talk about the product specifically. At a high level, what we're doing is we are integrating these two technologies, right? Like, we are making all the workflows to integrate these two technologies very easy for developers. Let it be like moving data, querying data, right? Like, all of that will be now magical. That's the vision where like they get this unified data stack to build their applications, right? So that's the whole idea.

I'll get into the product on how we are making that integration magical. But yeah, that's the whole cases on why we started this. Maybe you have examples. What was hard before that and now it's easier. So the use case typically, you start with Postgres, right? As you grow, you quickly realize that PostRis doesn't scale that well for analytics, right? You see your dashboards becoming slow, which is when you adopt Clickhouse, which is suitable for analytics, like very purpose built for analytics, right?

And in that integration, you like probably move some data, the operational data to Clickhouse. And you also change your application to query these two systems, right? Like you have awareness in your application to say that, okay, transactions go to Postgres, right? Like the ingestion, et cetera, goes to Postgres. And I have Clickhouse powering like analytics. It's also the warehouse because it's suitable for the data warehousing use case as well, right? So this is the high level like these are the two things.

Like replicating data, keeping the systems in sync. and then you have querying data, which is like changing your application to make it, make it easy for developers to query these two databases. And our investment in the integration bit is tied to this, right? So on replication, we started with PRDB, which uses logical replication under the covers and two years, we just optimise the heck out of it. Every possible optimization, right? Like, it's really grinding. It's really like plumbing. I like the way you said, like just like thousands of optimizations, like thousands of bug fixes, etc.

right on the data movement side but however still there are issues because logical replication has its own issues like you have replication slot growth which can happen right and that was more often as there were more intensive workloads right second is with logical replication and pardb you're restricted by latency like you cannot it's single digit seconds of latency but now with agents and AI we are seeing customers who are like hey I do an update on my operational data I want to see my analytics right away. So there is a latency issue, there is like operational overhead of like logical replication. And then there's also logical replication is restrictive, right? It does not support like complex schema changes, et cetera. So what we want to do is now that we manage both sides of the stack

and we have like access to the physical right ahead log, we introduce this like open source engine called wall shadow, which takes this post-clos logical replication to the next level. It directly consumes the physical ahead ahead log, provides latencies that were like unheard of. It's in private preview, but like we're seeing, I just came out of a POC now, which is going on. We're seeing latencies of like hundreds of milliseconds, right? So that is on the plumbing side, PRDB and now Wall Shadow, right? And then on the querying side, we launched this extension called PG Clickhouse, which makes querying these two systems easy, right?

So you have this PG Clickhouse extension, Postgres extension, which lets you query Clickhouse from the Postgres interface. So the idea is you use like the Postgres interface for application development, right? So when you're transitioning, your analytics workload from Postgres to Clickhouse, you still use the Postgres layer, but under the covers, use the right tool for the right job, Postgres for transactions and Clickhouse for analytics, right? I'll dive into more what we're doing on PG Clickhouse, all the innovation there. We're investing very heavily, but this is the high level idea.

Examples are PRDB plus Walshap, PADB and or Wall Shadow for like this like seamless replication, keeping them in sync, and then you have PG Clickhouse to make the querying easy. Yeah, that's good. So I think it makes sense from a high level why you would want to go into it, because you can then offer that experience across it. It makes tons of sense. But it is also a tough thing to be. You've got the obvious team behind you to have a managed Clickhouse service.

It makes sense to go to the company Clickhouse for managed Clickhouse. But it doesn't make as much sense to go to the team behind Clickhouse for a managed Postgres, right? There is an argument that you should go to Postgres guys for that and Clickhouse guys for Clickhouse. But it is interesting that you've come to the Postgres. market with some in I feel like your managed postgres isn't the same as a lot of other managed postgres and there are some differences though some deliberate decisions you've made there I'd wonder if you wanted to talk about just without the managed click house part and without the connector about the postgres managed service on its own absolutely I think whatever I think integration

is like more like the vision where like unified data stack we see this the world going towards that vision to where everyone uses postgres and clickhousing we're seeing that happen but But the Postgres itself has to be world-class, Michael, right? So I come from like a Postgres managed service company, Citus Data, right? Work there for eight years, like four years at Citus, four years. Microsoft's like Azure Post-Gris team, understand how hard it is to offer world-class like Post-Cris service, right? Coming to your first point on, Clickhouse has a solid like Post-Cris team and we are partnering

with like world-class Post-Cris experts, right? This kind of comes from the PADB acquisition was very strategic with myself, Philip, even Kaushik, my co-founder, right? We also have Samay, like who works in the Clickhouse Core team. All of these folks like ran Postgres managed services at Citus at Microsoft, right? And also you guys might have heard like we are in a strategic partnership with Ubik Cloud. They're like creators of Citus data. Like we have Daniel Farina who actually built Heroku Postgres, right?

Like even Crunchy Bridge. Like he was like the main architect behind Crunchy Bridge, right? So we do have the postgres expertise within our team to pull off a work. world-class Postgres service, right? And what I mean by world class is like reliable, fast, basically, right? Like enterprise grade, we are not building toy postgres guys. I want to make that very clear. It will, it will work at scale. It's super fast. It's reliable. It's secure. So we do have the team. That is number one. Second is what we did, Michael, was like the approach that we took for Postgres is offer Postgres back by local and me and me storage, right? So we are

going back to basics. We are going back to basics, right? Where we believe that for O. LTP tail latencies matter a lot, right? Like every like millisecond or like even half a millisecond matters, right? Because you look at the concurrency and you look at the number of requests, say a Salesforce, like you open the dashboard, like it's millions of requests like that single dashboard can make, right? Like I'm not across like hundreds and thousands of users, right? So every millisecond matters, which is why we took the approach where for Postgres we have a architecture where storage is co-located with compute, which is NVME back storage, right? And now, Obviously, it has all the platform features like availability, backups, reliability, security,

which I'll touch upon. But it really gives best possible performance for customers. And very interesting insight I'll tell you is this is not be published like Postgres Bench, right? There are other like MVME back services also who talk about benchmarks, right? Those are very restricted to cruds and like DML operations, right? Like DML operations, crads or selects, right? What we are seeing in real world customer use cases is your vacuums are much better.

You're like checkpoints are much better. Your logical replication is much better. Even for CPU bound workloads, not even IO bound workloads. Even for CPU bound workloads, customers are coming and reporting that like my 50% CPU is now 5% CPU, 10% CPU, right? The reason is because in Postgres, every operation is an F sync like inserts, updates, DEMS, like vacuums, like logical replication, checkpoints. Everything there is disk, right? Everything there is F sync, right? And for F sync, you need CPU.

Whatever be it, you need some amount of CPU, right? Even though you're not bound on disk, you need CPC. you need CPU, right? So customers are coming and reporting that, hey, we are able to do much more with less, right? So they get a healthier and a much efficient Postgres, right? So that was our idea where like we go with NVMEBack Postgres, which is built for like OLTP, which is suitable for OLTP, right?

And this is also proven historically, right? If you look at companies like Datagog or Instacart, right, they run on NVMEB back postgres, right? But obviously self-managed, right? And what we are doing is we are bringing that in a. managed experience, right, with all the tooling. And obviously, like, the icing on the cake is you integrate that with Click House for analytics. Yeah, I can't. Just to add one thing quickly, I think it's proved historically far before that in the sense that this is how people ran Postgres

before cloud providers, right? And it's the decoupling of storage gun compute or like the, the cloud native kind of paradigm where a lot of providers went the other one, and started doing distributed storage and scale storage separately from compute type features that went away from this. So I think you've got a historic, maybe 30 years of history, rather than like, even only the last few years of those companies publishing that kind of information. So to me, this makes sense as a way to do it. The only question then is around the durability side, I guess,

but we can get to that with H.A. stuff. Yeah, I also wanted to help Sire and answer that. You cannot run wall shadow on Ardias. If you want to minimize the risks of using logical replication on production Posgas and replay CDC from wall, from archive or from somewhere, like this is what a wall shadow is, I understand, right? And in this case, it won't work on Ardias because they don't have, we don't provide access to wall. So it's better to own everything in this case.

right and manage to help your own manage postguess in this case you can build better planning right actually exactly yeah exactly i think i think totally right because we have access to the physical right ahead log and our vision is like to make click house as a physical analytics standby right and that's a very bold vision it's not like easy right like where streaming replication is like battle tested since 30 40 years right it's like the standard way for hs a read replicas etc right So that is the vision that we set for ourselves where click house is like a physical analytic standby. For this, obviously the wall shadow has to make sure where you're investing very heavily in it. Like for last six months, it's been like a project.

Now we are having clients like actively tested, etc. There could be some click house related items also, right? Like more click house core to make this happen. But the idea is like make it like a streaming replica. And then and that way the operational overhead is gone. Latency is milliseconds. and then it opens up a new set of use cases. Latency in the seconds, I would challenge this

because if we have long transaction and then the transaction was aborted, I still think there might be some challenges in terms of latency there. But as we also try to build the same thing, similar thing, in core Postgres itself and we have prototype working already. We spent like five hacking sessions plus a lot of AI stuff. I'm curious why Walshadow is AGPL, why other components you built are Apache 2.0. Oh my God, you ask all the hard questions, Nick. So I think...

Yeah, I helped you a little bit with answer, but now I'm in opposite direction. No, absolutely. I'll be very transparent here. Obviously, we consider Wall Shadow to be a very strategic project, right? And the main intention with which we went with AGPL is we didn't want our competitors to redistribute it and offer it, right, because it's one of a very big differentiators and we are spending a lot of time. But remember that it is fully open source, right? And users, customers can just use it, right? Like Citus data was a EGPL, right? PureDB, initially we started with ELB2 and then we changed it to EGP, AGPL, right? So it's fully open source, users, community can use it, right? But from a

competitor standpoint, like, we wanted to. to restrict it because it was a very big differentiator for us, right? Finally, everyone is doing business. We will have it in core sooner or later anyway. Right now, everyone is in trouble trying to help with PostGyS 19, bug fixing. It's literally a lot of findings all the time. But once PostGus 19 is out, I'm pretty sure, you know, our hacking sessions, we will return to that and let's see whose solution is better.

No, absolutely. And the thing is that I love it. And the thing is that I've already shared what you, the, the PG hackers thread and with the team internally. And we would love to contribute. There are many challenges. I mean, disaggregating logical replication from the post-cress process is not easy. One of the biggest problem is how do we get the consistent state of the catalog, right? And which is where we have this wall shadow, which is like a streamer pickup, it keeps catalog changes. So we'd love to contribute very closely. So yeah, yeah, we had this idea like it's simple. When we have a changing related to catalog coming which conflicts, we just wait and don't replay and then logical replica catches up and we can continue. So it's just basically, in our case we have a physical standby basically just runs to, I think PostGIS 18 enabled logical replication from standbys, right? This opened the door like we can just have a, small postgess which is needed as a proxy for logical replication, but it can be disaggregated and we don't need slots and we can consume walls from wall G backups or PG

Reckrest backups. It doesn't matter and that's great because the primary the main production cluster doesn't know anything about it and it's like zero risk but we need proper conflict resolution. So I think sooner or later this will become a core feature I hope. I love it. But you have some, like maybe one or two years. No, I love it, Nick. The reason is because whatever architecture you're talking is exactly what Wall Shadow follows. Like, it is actually, it has mechanisms where it directly reads from Volgi as well. The Volgi backups, right?

Like even not even like using the physical replication slot or the valve from the source, right? It has that mechanism. Base backups, we do that. So for initial loads from Postgres to Clickhouse, we read the base backups, right? And then there is a, there are two modes. either you read from the physical wall from the primary or from backups. So this is exactly how we are thinking and it validates. It's a big validation that the team followed the right architecture.

But one thing, this is a different thing, but this ties into like Michael's initial question is, one of the things that we also like philosophically, what we believe in is we don't want to fork postgres and click house. Like Michael, right, we don't want to fork postgres, right? So that is also one of the reasons like we stuck to this architecture where postgres and clickhouse are left alone. and we integrate with them as natively as possible, right? Whereas other solutions for Postgres and, yeah, anyways. Why don't you want Fork Postgres? With AI, forks are much easier to maintain.

It's not Green Plum era. It's easier now. AI makes fork maintenance super easy these days. Good question. I think this partly ties into the trust and in Postgres, right? like I think and also if you look at the evolution that Postgres has had over the past few years, it is more than proprietary forks. If you look at Async IO, big feature, right?

A logical replication. Evolution has been crazy. I know that like there is also some work going on active, active, etc. So overall, I think it's a combination of trust, right? Like it's battle tested because I think we need to be really careful about building databases with AI, right? By the way, like All Shadow, AI was involved, right? And AI helped a lot in like building Wall Shadow. But we are like, we embrace it because we also are experts.

Like Philip, right, eight years worked with like Postgres, right, knows Volgi from its cuts. So even though he uses AI, like, I think he has the expertise to make sure that like it's built in the right way. Right. So to answer your question, Nick, I think it's twofold. First is like the trust in the battle tested nature of Postgres. Second is I think Postgres has been growing fast itself. And third is we will also now, I'm actively looking, we are actively, okay, I'll share. We are actively hiring a post-cress, like, core committer and a contributor team.

So, like, we are planning to create that and there's active discussions on that. So we want to actively contribute as well. That's great. That's great. Definitely. We need more big companies who will support that and expand and so on with openness and so on. Yeah, that's great. Especially if big companies realize that right now it's a big challenge to fix a lot of bug findings,

which are brought by AI. I was sleeping in my AI found like 10 bucks or so in PostGus 19 and all of them looked like some refuted but around 10 remain and all of them look reasonable and verified and so on and it's terrible. I think it's great that we see we see more but it's super challenging for humans because verification is fully manual right because as you said you should be careful with AI and databases I agree with that. that. Although there are stories like Pigerust, right? Like we had the episode about that and it's like interesting experiment but still yeah. Yeah, so very ambitious project. Yeah. Yeah, yeah. But postgres itself verified fully manually. It's for good. Let me dig into into storage

question a little bit because you said in VMEs, but in VMEs have limitations. They are limited by size much more than EBS volumes. It's interesting that the best volumes are single volume is 64 terabytes and it's still many, many OZGIS managed platforms cannot go beyond 64 terabytes, which is weird, but okay. But in VMEs, they are limited very physically. If you take some instance, I think maximum is, I don't remember an 8 years, yes, but I think maybe it's more than 100 already, but maybe no. It's like the biggest, newest instances within VMEs. But you cannot grow, for example, to 500 terabytes, right? Unlike EBS volume, if you combine it with LVM,

you can have good stripe and go beyond two petabyte, maybe, on a single cluster. This is one limitation, but the main limitation, as everyone knows, they are ephemeral. If instance dies, this also, like the data dies with instance. it means that a H.A solution must be very solid, right? So what's the approach of Clickhouse PostGus managed platform? Great question.

So firstly, I think there are two questions that you ask here. First is around the limit, right? NBME has this cap of 100 plus terabytes, by the way. In EWS, you get that 100 plus terabytes now. And being in Clickhouse Manage Postgres, at least there is a soft limit of 60 terabytes. IAGE or I7i. these are the instances and in AWS and in GCPA I think we go up to like 50 terabytes or so basically we just launched it in private preview like last week there is enough storage over I've not

seen post-gress use cases that many over 50 terabytes but I expect we will get there there are customers who are asking for hey we are close to like 60 terabytes what's your answer for that like the answer is like twofold okay first is what we are seeing a very interesting type of use case where customers are using Postgres as a hot store for operational use cases and Clickhouse as an archival store for operational use cases, not analytical, which is very, very interesting. We have a customer who will be speaking at the meetup very soon on 24, right, 30 terabyte Aurora. We migrated them recently, right? And what they do is they keep six months of data or three months of data in Postgres and the rest of it goes to Clickhouse. And the use case is mostly like lookups,

like lookups and searching and stuff, right? And then Clickhouse works even for those use cases, right? That's the beauty of Clickhouse. If you look at any traditional warehouse. So, so, exactly. So Postgres is, so the thing is for this like B3 indexes and single digit milliseconds are very, very critical guys, right? Because this is a standard transactional application, right?

So 95% of the workload is still on Postgresnik, right? Because it's three months of data. That's where most of the workload is. And the rest of it goes to click. Clickhouse and Clickhouse is good enough even for these use cases where the latency is tens of milliseconds, but it's manageable because it's just five percent of the workload, right? This is different from analytics guys. Okay, I'm talking about pure operational use cases, right, which are divided between Postgres and

Clickhouse. Now, full analytics is running on Clickhouse itself. So one is this where you have this combination and they use Ball Shadow or PLD or ClickPipes for this continuous sync and we have logic in click pipes which does smart expire where you can actually say that, hey, three months, I want to keep it in Postgres, and any delete that happens before three months, don't replicate it to Clickhouse, because Clickhouse has to keep the whole data set, right? That is one where, like, using Postgres and Click House to manage, and the benefits of this architecture are like crazy, right, because you get this. Clickhouse is bottomless.

It gives compression, right? It gives storage, like you give you, it gives you like five to ten times, like lesser storage footprint and all of that, right? So this is one answer for that storage, where we're seeing customers use Postgres and Clickhouse to power their operational use cases as well, transactional operational use cases. Second, Nick, is stay tuned for something on sharding and stuff like that. And say tuned, I won't tell you what's going on, but like we are actively thinking about it and you might hear something in relation to that soon. It's easy to expect from Max Saito's guys. Like, it's easy to expect. Most secret here, I think. I have been thinking we need another sharded solution in the post-gris

space. That is definitely. I know, I know there are many like currently and I think the reason we are even taking this up is because we think we can do well. So I believe a lot in like playing games that we know basically. And I think like even taking a Post-Rest Manor service was aligned with that. Right. Like we did this multiple times over a decade and we feel that we could do it better, right? Plumbing integration with Clickhouse. We've done it at PODE,000 plus customers will do it.

Similar with Chartered Citus. So yeah, charted posters. Going back to Nick's other question because I think, I think, I think, the large data basis is interesting but only applies to the top 0.1%. But the AHA story does apply much more widely. Should we go back to that in terms of...

Yeah, and let's add nuance. Let's add nuance. Because when you have a BS volume or hyperdisc on Google Cloud, in this case, you can use cloud snapshots very naturally. And even if it's a single node, your RTO will be

just some minutes, not hours, because you can restore from snapshot. Yes, lazy load and so on. It will be slower, usually, but you will be up in minutes or dozens, like 10, 20 minutes. You will be up very quickly, replay some walls from backups and that's it, which is absolutely unavailable this approach with cloud snapshots, cloud disk snapshots, if you use a local MVME's. You lose that. That feature. And just in case, there is a full request in VoltG to make VolG natively working with cloud snapshots, which is great. This feature is like kind of a must have if you exceed, say, 10 terabytes. But now if it's local in VME, okay, forget about those snapshots.

And the only recovery path is fully fetched it from S3. And it will take hours. Yeah. Maybe 10 hours if it's 50 terabytes. Maybe even more. like a few terabytes per hour was a good speed. So I was maybe 20 hours, which gives you terrible RTO. Right.

Yeah. Great question. Right. So the thing is, which is where like we like give a lot of configurability. Okay. So first the service comes with up to two standbys, right? So you can actually configure how many standbys you want, right? Like it's two, zero one or two, right?

Two is with quorum-based replication and across availability zones, basically. Corom-based token stances. Coram-based replication, right? It's like standard post-dust, like any of, if you look at the synchronous standby, it'll be any of one and two. And then we have our own failover in our data plane, which is Ubik cloud, right, which does it. And that is one, you have up to two standbikes across availability zones, right? And the RTO there, the RPO, let's talk about RPA and RTO where there.

RPO is zero, because quorum-based replication, we act only if the commit goes to at least one of the standbys. You have RTO, right? RTO is a few seconds, right, like to a minute kind of, right? Like, the failover. Like, we detect and we propagate the second D to be the primary, right? With one standby, currently we support async replication, with which the RPO can be few milliseconds, right? But the RTO is like, again, a few seconds to a minute. And it's interesting that, like, for a lot of customers, they take this trade off, right? Like tier three, tier four applications or tier two applications, they are like, hey, we are okay with synchronous replication, right? That was a surprised to me. So we make it very clear

in our dogs that it's async replication for single standby and they're okay with it, right? We have this backed up somewhere that milliseconds of like PO is okay for us. That's a very interesting observation. Now one thing that we are doing is we are working on giving zero RPO with single standby. I'll tell you how

we do that separately. That's a very interesting architecture again, like and similar to Wall Shadow. We'll talk about that separately. But we are working on how do we give single standby H.A. with RPO zero. So we have an entire platform team which works on these problems, right? And there you save on cost, that single standby, you get RPO zero, you save on cost because you don't need three like standpies,

two standpies basically, right? The third is zero where whatever Nick said makes sense, right, to some extent, right, where their RPO is 60 seconds or 16 MB, whichever comes first, right, because that's the well timeout and that's the 16 mb is like the postcode, like hard coded thing that we ship to ball, right? And RPO is that. RPO obviously is order of But now we spent a lot of time in making Walji faster. You'll expect a blog from us very soon and a 10 terabyte database recovery was tens of minutes. Yeah, they're not in rust, right? Yeah, I understand that.

So, that's the story. So to optimize like RPO and R2, you have options is what I'm trying to say, basically, with this single standby and two standbys. And with no standbys, you take that trade off, basically, right? And one thing I want to say here, guys, right, because the large enterprises run on NBME backpostgres. And you have data org, like Instacart powering their use cases, like very similar setup as what we offer, right? Like Volgi or like this streaming replication with rep manager or whatever, right? So it's, it's already very proven there, right?

One is theory, other is practice, right? We need to be real, guys. I know backing up like 10 times like in the cloud, like theoretically on paper gives you like 15-9s of like SLA, right? But with NVME, it's already battle tested. It's real. Like, there are, like, already a lot of safeguards in place, right? I'll even share some metrics. Like, we keep track of, like, our availability, like, SLAs.

It's over 7-9s already. And there was never an unplanned outage in the past six months. So I'm very wrong saying that no consensus means trouble, right? It is. Let's let me friendly scrutinize your statements. First of all, I'm old school. so I got used to differentiate HA and DR. When you say RPO zero means like a couple of replicas and so on,

this blows my mind. Because for me DR, it's when we lost, for example, whole region and we need to recover. Or some stupid mistake happened. E.I. executed something which was replicated to all replicas and we need to recover. In this case, we cannot use replicas. this disaster for me.

Replicas are for H.A. Yes, you can use them for some kind of disasters, but not all of them, right? That's why I cannot understand using RPO in the context of HAA. It's very, I think, discussable statement.

Oh, absolutely. Yeah, yeah. There are different positions, but for me, being old school, like, D.R. is just a disaster. We lost everything. Let's recover. And also, I see, I love in VMEES, but I also see cases when people are okay with single node and they rely on recovery with using snapshots very fast, like relatively fast. They say we don't want, like the cost of H.A.

Replicas are not justified for us. We better be down 15 minutes for our 10 terabyte database. And we will recover from and we will deal with lazy load, but we save so much money, not paying those money, not only for disks, but also for memory. Memory is expensive these days. These days memory is super expensive. Now then, this is one thing. Second thing, I hear quorum but not consensus. I'm worried about this H.A. solution. I'm very, say, extremist. I'm extremist. I'm radical. I have radical position. You know this. I do. I do. Cloud native PG, brutally, I can exercise it. I say, this is dead. And it's like replication manager. We had split brains. Unfortunately, we have good cloud infrastructure, not like 15 years ago. So,

So network pickups happen less often, so probability of split brands decreases, but theoretically, split brains are possible with quorum based on this approach. And also, RPO zero, I'm very curious, is it remote right or like, what's remote for it? It's not remote apply, of course, right? It's remote right. Let me actually look up. I'm not sure about that.

Because it applies terrible in terms of rights. Yeah, I think it's remote. It is configurable as well. Right. Oh, configurable. That's cool. It is configurable. We exposed as much configurability as possible.

There's a stance we took right. That's the reason we even support zero one or two stat buys. We had this discussion on Twitter. And you exposed super user, no? We do. We do. That is again an intention. That's an intentional call.

Forget forget everything I said. I can reconfigure as I want, you know. That's an again intentional call, and that's a separate debate. there are other manner services who do this by the way i think um ub cloud does it i mean it probably cruncheridge there was it one i know cruncheridge as well right so we we do the same thing we give a lot of like flexibility for the user right and and then i think you're spot on nick right like where i think you bring up like a point of rpo on hey you're talking about h a but without h a like if the whole region goes down like you need to pull from backups like what about rpo there right i think there

first is i think if you just have backups it will take some time and we are investing in making that better like we are contributors to like Volgi as well etc we like have this walrus but still it is order of data i agree with that second is there are creative mechanisms which we are actively evaluating to solve this think about it right like a read replica with bs back storage basically right sure or high risk available yes right so we are thinking about those things you'll hear more about it this is a top of mind thing enterprise grade reliability security is a p zero for us basically right so yeah yeah Well, RDS also supports NVME nodes, but those NVMEs are just to speed up reads, right?

So they are like secondary in front of EBS volume. Right. So it speeds up reads, but doesn't speed up rights. And yeah, there are several interesting architectures possible here. But I love great speed, but I also love snapshots for 10 plus databases because it makes operations so much easier. That's the problem here. Yeah. No, I get it.

I think the thing is it's basically like there are creative ways with read replicas or using like Walrus and Valji. This also ties into being more real because NVME or on-prem deployments have been, have been since like decades, basically. So I think it's validated and now with the cloud, it's only getting better. Right. So being realistic is very, very important. And then this is with enterprises, guys.

These examples that I call out are not like some, like, not smaller, like toy apps, right? It's real enterprises. Yeah, that's all interesting. And definitely there are several paths here and so on. Yeah. Yeah. I'd love to hear your take on major version upgrades. Only because you talked about developer experience, I think it's one of the toughest things at the moment to do with Postgres with zero downtime and without, unless you're using logical replication.

Obviously, your background in logical replication probably is super interesting here too. What are your thoughts on offering that as a managed service? Exactly. I think currently we use physical replication. We use PG upgrade for major version upgrades and we have maintenance windows also. So you can schedule a specific time. It comes with all these platform features like maintenance windows like Open API Terraform, Prometheus, all the platform features.

Anyways, that's a separate topic. But in future, we... we will probably support blue-green kind of online major version upgrades, right? And this is our territory, guys. We, like, already we have a fully managed migration product, which is through click pipes, click pipes with Postgres as the target, right? And it's one of the most fond features for customers. This 30 terabyte Arora database, we migrated in eight hours, basically, right?

And then this uses PADDB. Out of time, right? Yeah. With the, obviously, maintenance, a minute of cut over time, but it was all online. It does schema dump also. So under the covers it like we have. And it's very like interactive. During the cutover, we check data validation.

We do like we check counts. We reset sequences. You click a button and we reset the sequence. Right. So we made it very, very easy. But TLDR, right? That's planned for the future. Also because that's in our territory.

Currently for one of our customers who we propose this as an option. They spin up a new Postgres 19 like like machine and then they do click pipe from postcard to from Postgres 18 to it's like blue green but it's not it might not be as ux friendly but yeah what about reversibility because RDS blue green as we discussed many times on this podcast they are not truly blue green you lose blue when you switch to green which makes yeah whole concept is broken basically like what I think reversibility I think reversibility is possible actually I mean it is possible not with like bi-directional replication I wouldn't no no no no

Just unidirectional. Yeah. Unidirectional, I think the way you do that is like in click pipe is you basically do the cutover. You're always writing writing to one, not two. You're always writing to one. Then you start a click pipe in CDC only mode. Right? You have one more and then you cut over and then right away.

Exactly. This is how it should be done. I'm just encouraging you not to forget about this. This is super important. No, no. We were. Yeah. Because I have no idea why RDS doesn't do this.

It's definitely, it works well. So yeah, yeah. Good. And there is also now PG create subscriber. So I haven't seen any managed provider exposing it through API. It would be great to start seeing that. PG create subscriber. Because it's starting post-gust 18, I think, or 17 exists already.

Which creates logical replica out of physical replica. So it's now official. Oh, I see. I saw some bug fixes recently. So it's maybe not so. maybe not super mature, but it's definitely in core. That's great. That's interesting. I will take a look at it. That's very interesting. Yeah, I'm excited to have this major player in post-gous ecosystem innovating a lot. That's especially great that you ship new stuff all the time. I know AI is involved where you mentioned it, right? Yeah, but it's great to see. Yeah, even though AI is involved,

I think I'm very, like, very diligent about it. As I said, like, AI, and databases are both, I think, have to be very carefully treated, right? I think we will, so, yeah, I think that's also one of our strength. I think thanks, you called it out, Nick, we, like, execute. We, we, like, teachers pass. That's cool, that's cool. That was great discussion. Thank you specifically for my attacks.

No, I love it. I love it. For handling my attacks. And I hope a couple of things are helpful to hear as well. Yeah, thank you so much for joining it. It's great to see you again.