Postgres FM - DBOS

Episode Date: July 24, 2026

Nik and Michael are joined by Qian Li and Peter Kraft to talk about DBOS, an open source platform for durable workflows built on Postgres.  Here are some links to things they mentioned: Qian Li https://postgres.fm/people/qian-liPeter Kraft https://postgres.fm/people/peter-kraftDBOS https://www.dbos.devTemporal https://temporal.ioGadget's use of Postgres https://postgres.fm/episodes/gadgets-use-of-postgresPostgres LISTEN/NOTIFY blog post from Recall AI https://www.recall.ai/blog/postgres-listen-notify-does-not-scalePostgres 19 commit that improves LISTEN/NOTIFY, avoiding waking backends that have no need to process the notification messages https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=282b1cde9 PgQue https://github.com/NikolayS/pgquepg_durable https://github.com/microsoft/pg_durableAbsurd https://github.com/earendil-works/absurdLISTEN/NOTIFY performance considerations (docs patch submitted by Nik) https://www.postgresql.org/message-id/flat/CAM527d8oDVb2K%2BtTjpjLkd7g14HLDiwwnvv%3Drcn4BMEs%3DMatkQ%40mail.gmail.com#1b6fa752a96aad22bd8ef794fbaf3ea1~~~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 and welcome to Postgres FM. We can show about all things Postgres QR. I am Michael, founder of PG-Musted. I'm joined as always by Nick, founder of Postgres AI. Hey Nick. Hi, Michael. And we have two special guests with us today. We have Chan, who is CEO and co-founder of DeBos,

and Peter, CTO and co-founder of DeBos. Welcome both. Thank you. I wonder if one of you could give us a bit of the backstory of D-BOS. I think it's quite a cool story. Yeah, so we started D-Boss as a research project. I think it was started quite in the middle of pandemic in summer 2020 when Professor Mike Stoenbreaker heard a talk from Matey Zaharia,

the professor our advisors and also co-founder of Databricks, where they were talking about how Databricks was using Postgres to do some scheduling work work because distributors scheduling and cluster management was a mess. And they were talking about how to use a database to simplify that. And then I think during that summer, we talked and discuss how we can extend that idea to make database more helpful to build reliable systems, to even replace the operating system. So that's how we started the original research project called DBOS. And then Peter and I were the co-leads, PhD students working on that research project. We published several papers, did a bunch of work. And then what we found was that the most

interested thing was actually to use the database as a foundation for distributed systems, to build distributed systems. And that's why when we both graduated in 2003, we decided to do to commercialize this idea, to do a startup. And now we are working on DeBos, Inc., the company. That's cool. And I must admit, I observed cues in POSG for so long, like 20 plus years. And somehow when DBOS was announced, of course, it attracted my attention, but I didn't quite get it.

Because like workflow, like what is it, right? But then I started to realize, actually, to realize that in any business there are workflows and to keep the state and all the history and so on in database, it's very natural. So this is a very good idea. And I think it revives the idea that Q in that database is not only possible, but it's possible in a quite efficient way. But with FOSGIS you need to be very careful, right, because of the same. some things that might happen if you implement cues and workflows in a naive way.

But I don't quite get it still why operational system? I understand when Andrei Carpatti talks about like AI as CPU in the center, like memory, like peripheral devices, everything. I understand this analogy. But here I don't quite get the analogy why is there is some intent or idea to implement whole work operational system in the database. What's your view? Yeah.

So what we're doing as a company is using the database as a foundation for distributed workflows. And then for things around the distributed workflows like cues, like messaging, like notifications and so on. I think the core idea here is that as your program runs, you regularly checkpoint the state of that program in a Postgres data. database so that if the program ever fails, anything happens to it, if it crashes, if it's interrupted, it can reload those checkpoints to recover from exactly where it left off. And that durable workflows idea, backed by Postgres, is the core idea of Debuss, using

Postgres as an orchestrator to make durable workflows that run with high performance, and that are really simple because all they have is, all they have, all they rely on is your database. Yeah, this makes sense. I understand that. I'm just still processing the idea. It's like whole operational system. I think our goal is that when we think about operating system, we should not be limited to the operating system.

We're running on our laptop or desktop. Thinking like anything operational, like Kubernetes can be caught at a distributed operating system. Thinking about like anything that can run your application as like a METAF name for like, operating system. So I think nowadays, especially with AI operating system is like cool again. Everyone is calling themselves an AI operating system or like something AI powered operating system for engineers, for sales, for whatsoever. So I think operating system now, like the idea is more

about how to properly run your applications in any environment, like in a distributed environment in a highly available environment. It's about how to provide a guarantee and provide kind of an illusion that you are like normal, like modern developers no longer directly write or interact with low-level operating system primitives. They usually interact with something like Kubernetes or cloud resources. So like you can think up the cloud as an entire operating system. So like I think the name like DeBoss right now,

focuses on how to operate those applications at scale and reliably. So I would say eventually at a grand vision, we hope everything will be backed by a database. And then that will be

like a super operating system. Yeah, this makes sense. In broader moving operating system, yeah, not just like Linux or Windows or something. I get this and also like there are even broader systems like there are companies like which are building like an abating system for businesses

in broader meaning right I also remember when Anthropic released I think ultra code with workflows I remember on Hacker News stop both topics were present one was about their workflows another was about some blog post from your blog actually I remember it was like for me it was like these are two different things and I remember internal discovery in our team actually that we use these workflows in Cloud Code, but workflows which are like saving some state and database is something different. And then I remember an aha moment when we realized we actually have genetic workflows internally already working and we save state in Posgars. So I realized it's very close topics. I think you also use this resonating moment

when they released it and you like to discuss workflows in database right so i have one specific technical question though because peter you mentioned that if something crashes right and this checkpoint and database we have we have stayed safe i don't like fully understand why checkpoint is needed because we always can replay more after checkpoint there are walls and so on right but anyway we have different checkpoint oh okay a checkpoint there but what wonders me if for example we send an email, but we don't know the result of that yet. I'm like moving us slowly to the topic of two-face commit or something, right? How do you handle that?

Yeah. So if your step is taking an action external system and it fails the middle of the step, then we're going to have to re-try that step. And that's unavoidable in any kind of workflow or durability system. So our recommendation then is for individual steps that take, have side effects or structural systems to make those steps outpident. And we'll provide help for that. Every workflow has a unique ID that you can use as an idipotency key in systems that support that.

Many email systems do support idipotency keys. Some problems are fundamental distributed systems. If you're taking a side effect somewhere else and it fails, and you don't know whether it's succeeded, you're going to have to retry it. And so you should really try to make sure that that action is outeminent. And another thing I didn't fully appreciate until recently, I kept focusing on the word durable. I see durable workflows mentioned quite often. I'm thinking about reliability and retries,

and that will make sense. The thing I didn't really appreciate was actions that could be quite costly. If you've got a five-step workflow and you've spent a lot of tokens or a lot of money or you've sent physical goods or something like that in steps one, two and three and it fails at step four, you can avoid the cost of redoing steps one, two and three. Like, that hadn't really clicked for me that sometimes it's about other side effects, like it might just be cost or it might be safe to it or might be something else

that you don't have to risk replaying. Is that a big part of it at the moment in terms of it? Are there parts of it that might be helpful to explain? Yeah, definitely. I think especially nowadays, everyone's building AI agents. And those new models are becoming more and more expensive. So if you have already asked the model about something, you want to use that output as much as possible.

And if something crashes, you want to resume from where it left off. Say you already asked a model what to do next, then you should continue from that step instead of asking the models again. Because otherwise, you have to burn all the tokens. And this will quickly become too costly if you're having like processing thousands of documents and then you want to do it in the more efficient way. That's where debosses use a lot, like building agents, and building AI-powered pipelines. I think cost-saving is definitely, it's like becoming more and more, I'd say.

Yeah. Makes sense, interesting. And also compute resources, right? Even if you don't have to pay those, even for some people who will self-host their GPUs and self-host their model inference, then you don't want to burn all the compute resources again. It's all about efficiency.

I think, yeah, durability itself sounds like nothing. It doesn't sound like a very useful word, but it indicates a lot about cost savings and also it indicates about after you've done something, you don't repeat it again. So it indicates about correctness as well. I have a question about why should it be inside Postgres. We know there are systems which do the same outside. Temporal is one of the most popular systems. I even from my personal experience, I even had a moment when one of our clients, implemented our Postgreas major upgrade workflow in Temporal.

It was Gadget. They spoke about it on the episode. Yeah, we had an episode about that. And it was like, we always used Anseville and so on. Of course, it's very different, right? When you have workflow, you save everything, it's great. But you move further. Let's bring the whole thing inside Postgres.

What are pros and cons? And why do you think this is a winning strategy? Yeah, so what I'd ask is why not Postgres? The temporal model. is that you are taking, is that you're outsourcing the control flow of your program to an external orchestrator. And that's a lot of additional infrastructure. You can either self-host it, in which case, to run your workflows, you have to spin up a highly available temporal cluster, a database for it, which is Cassand, and then this database is Cassandra and Elastic

search. And now you're spinning up three new distributed systems to run your workflows. And all three of those systems are totally on your critical path. If anything happens to them, nothing will work. Your workflows will not function, your business grinds to a halt. So you're putting three complex distributed systems on your critical path. Or you use their cloud service, and now you're putting an external SaaS on your critical path. You don't need to do that. You just need a database.

And what we're trying to do in Dboss is totally replace all of those distributed systems, all those external orchestrators with your Postgres database, so that you can use your database as an orchestrator. It's already on, your critical path it's already something that you're making sure is highly available it's already critical for your application to work why not also use it as your workflow orchestrator so you have less infrastructure so that your operations are simpler so that there are fewer things that can break and bring down everything you have two things here one is who will like postgis doesn't have scheduler right you can use pgcron or something or you need to still need

external help to tick right to move forward and it Another thing is that it's all running on the primary and primary CPU, first of all, is not infinite. So you need to avoid heavy things and have them outside still, right? Yeah, and that's why we use the Postgres as the orchestrator. The actual business logic of your workflows is still running in your application. The scheduler is running in your application, for example. And then Postgres is the orchestrator. So your applications are running a scheduler, and your applications will in queue when the schedule, when the cron fires,

one of your application servers will link queue a scheduled workflow into Postgres. And then Postgres there does orchestration. It coordinates multiple servers to make sure that only one of those servers actually executes the scheduled workflow when it's Cromtech fires. So your applications, your regular servers are doing the work, and Postgres is orchestrating them to make sure that all the work is being done totally reliably, and everything happens exactly once. Makes sense.

So this is when you say critical path, you don't include things. that like sending email can be done from multiple servers and they are replaceable like state place and so on yeah i get that it feels feels slightly awkward for me to try to criticize the idea i'm a big fan of myself maybe michael should join and find some other questions i was actually going to ask a question that probably goes even more positive maybe not but i would expect there to be performance benefits to using your already use database for this rather than an external service? So I was only going to say what are the performance tradeoffs and what do you do to minimize the impact you're having on primary CPU and that kind of thing?

Yeah, absolutely. So latency in particular gets a lot better because now the latency of executing a step is just one right to your local Postgres as opposed to async dispatch from somebody else's cloud service. So definitely latency improves. Now, throughput then becomes database bounded. You can process as many workflows per second as your Postgres allows. And if you need to scale beyond that, you need to shard across multiple Postgres databases. The good news is that these operations are fairly light. So our rule of thumb is that four Postgres scores can handle 1,000 actions per second. So for a large database, that means you can vertically scale. For a large postcard database up to we've benchmarked around 40,000 actions per second on a single

postgres database. And then of course you need more than that you can shard or you can use multiple postgres databases. So your throughput does become bounded by your database but the good news is that your database can handle a lot of throughput. Yeah. And we're talking so let's say we've got a workflow with six steps. We've got one right at the beginning, one right per step and one right at the end. So we're still only talking eight rights total for a six. And this workflow is having to do things in the meantime. It's not going to be running through them instantly. So yeah, great.

Okay, cool. And you can handle 40,000 of those actions per second on one database. Yeah, I'm curious. I researched a little bit, and I noticed that you started with repeatable read isolation level and then reduced it to default, it committed, right? I'm very curious what was behind that. Is it this throughput question or anything else? So we use isolation levels.

There's a lot of different parts of our system. We use isolation levels for different reason. We've designed a system so that almost everything is a single statement. So it can just execute it recommitted. And that makes things far more efficient. As many things as possible, actually, it's a single post-gris statement. So they can just be atomic and you don't have to worry about isolation. You set it to default recommitted.

The one thing that we can't do that for is the main DQ query. This is probably the single most important query in the entire system. And it's the query that every worker runs periodically on every queue to decue the latest work off the queue. And that's a very complex query we've put a ton of outweb for optimizing. That query actually has a conditional isolation level, depending on how you've configured your queue. So if your queue uses global flow control parameters, if your queue, for example, is a global concurrency limit or a global rate limit, so you say, for example, that this queue can only execute one operation at a time across every worker, then that requires global coordination, which means

we have to use a high isolation level, like repeatable read. And that has coordination costs, but if you have those global coordination, you have those global limits, you're probably fine paying the cost because you're only executing one workflow at a time across all your servers. Your throughput was limited anyways. In practice, though, what we see is that high throughput cues usually only use local limits. They might say only execute 10 workflows at a time per worker. And those local limits don't require global coordination. And that means it it's perfectly safe to run the cues query at a very low isolation level at readcommitted. And that way you can have this query running across hundreds of servers at the same time or thousands of servers at the

same time without them conflicting because they're already recommitted and that lets you get this 30 40,000 DQs, you know, DQed workflows per second, actions per second throughput and it really caps out of 30,000 decues per second on a single postgres across thousands of workers because we've optimized this query and in the case of sharding solution repeat the repeatable read wouldn't be available anyway right so because like global limits it's Yeah. Yeah. But in fact,

just global limits tend to go with relatively low throughputs. And it's flexible now, right? So the user can control it and decide

that's great. And I also noticed LISNNTI5 was recently added, right? Or not recently, maybe I'm wrong. We've been having Listen,

Lodafi, but recently we've been optimizing it a lot. Yeah. Yeah. I think it was last year. Recall AI, they just covered

this awful global lock on commute for Netify. right? What's your deal with this right now? Listen Notify is really powerful, but has multiple performance issues. There was that issue that I forget. There was that issue that reached top of Hackerners last year. That was actually not the issue we ran into. That issue was solved in Postgres 19. That is not the issue we ran into. That issue is that Notify had terrible performance. Notifies broadcast

mode of terrible performance for large numbers of sparse readers. That's actually unrelated issue. We do not have that. We have dense readers. We don't have sparse readers. Can you explain, please, that Sparse Seaters versus dense readers? Sorry. The problem that Arabi was talking about last year was that if you're broadcasting to a huge number of readers, each of which is only reading a small fraction of all messages, that had terrible performance. So that's actually not the issue we ran into.

The way Deabasa set up, pretty much all workers are listening to all messages, and that performs fine. The issue we ran into was the global lock and notify. When you commit a transaction that performs a notify, it has to acquire a global lock for the entire duration of the commit, and that includes the F-Sync. And what that means is that these transactions can't be group-committed. They have to commit sequentially,

which essentially bounds the throughput of any operations that perform Notify. You can't perform more than a certain number of number of seconds. because you can't group commit. So you're stuck waiting out the entire duration of the f-sync. The optimization that we settled on there to make list notify, because we really want to use List and notify. It provides incredibly low latency and when it works, it provides incredibly low latency. So the opposition we settled on was Notify batching. So instead of setting a notify, originally we were sending Notifies in a trigger every single time you, for example, wrote to a stream. And the optimization

was instead it was removing the trigger and instead buffering stream rights in a background threat and then sending all the notifies in the batch and send that batch every 10 milliseconds or so. A huge batch notifies is actually very fast because you only have to hold the global lock for the duration of that commit. That's fast. And what this does is this allows us to use this to notify without worrying about the global lock because we're batching commits and the global lock's only required for commits and still getting the benefits of low latency because we can still emit these every few milliseconds. I think the overall observation is that we don't really need that global ordering.

When we're doing the application level streaming, streaming, for example, results to the client, then what we're leveraging the lesson notified to do is to notify like, hey, we have some results available. So we don't really need that strict ordering. And I think that was the main aha moment for us that, okay, we don't need to limit ourselves to that exclusive logs. We can do batching. Yeah. And yeah, and this is, okay, so and also the problem is happening, Jupiter mentioned that it was fixed in 19,

and it's happening when commit has a lot to write, right? So like it's, this has seen. Basically, transaction is significant in terms of how much it's writing. Right, so this increases the problem. But in your case, you have only like brief rights in transaction. not a lot, right? Not like a lot of jasons to be written in f-sync during commit. So the problem shouldn't be huge already, if I'm not mistaken. And you decided to group it. This is an interesting optimization.

I wanted to raise this question, of course. You use skip-locked updates and what's happening if we have some X-min horizon blockers? So long transactions or lagging logical slots, obviously a lot of data. apples should be accumulated, right? Is it a requirement if you use debos at like at high rates at a lot of events per second and so on? Is it a requirement I need to watch closely, what is my X-min horizon, don't allow long-running transactions, don't allow logical, lagging logical replication slots, long transactions all on standby with hots standby feedback on and so on. Is it a requirement or you solve this somehow? I don't know.

maybe mitigating blot with repacking, re-indexing, and so on. Got it. So just to be clear, we're only using skiplocked on our own workflow status table, and that's typically isolated within its own Postgres database. So our recommendation is don't take out ultra long-running transactions inside the DeBoss database, and you probably weren't doing that anyways, because Dboss certainly doesn't do that, and then the rest should be fine. The Dboss operations are isolated here.

So you don't use keep locked for like events tables, where events or workflow data is stored? It's only used for DQs off of the main workflow status table, and that's usually pretty isolated from user data. But still, you need a single update on every status change, right? Yes, and that does lead to DeadCube Tupelo. accumulation. But that's a separate issue that yes at massive at really high throughputs like we were doing these benchmarks at 30, 40,000 workflows per

second we saw a high CPU usage due to dead tubble clean up an auto vacuum because we're turning on these indexes and we've done a lot of work to optimize indexes so most almost every index is partial so most indexes are only being maintained either for a small subset of workflows or only for a small subset of workflow lifetime. But there's still a fair amount of index turn on the order of, and of course not as this is hot. A DQ is going to create a dead topple, is going to create a bunch of dead index. It's going to create two or three dead index entries that are going to have to be cleaned up. At really high throughputs, this can become the bottleneck.

but that sets in around 20 or 30,000 actions per second is when we start seeing the duplicate accumulation really becoming a problem because there really aren't that the duplication is becoming a problem because we have optimizes as much as we can. Yeah, I see it very differently. I see it like when you say 20, 30,000 per second,

it means for me it becomes to 3,000 or 200, 300 per second if we talk about really long transaction happening in parallel, because they block vacuum work. We cannot delete that doubles. And at very high throughput with shorter transactions, will be became the same if you have much lower throughput.

Yeah, which is why our recommendation is isolate the DeBos system database from the database we're using long-running transactions. These don't have to be in the same, these don't have to be in the same Post-Frest database. and they probably shouldn't be, especially for long-running transactions that could block out of vacuum. Yeah, this is exactly what I was asking.

It's not like requirement, but definitely if you have long-grang transactions or any other X-Men horizon blockers, performance of DWS will suffer eventually. Yeah, but these can be isolated from each other. They don't have to run in the same place, and they probably shouldn't run the same place, especially at scale.

This is interesting. We have a lot of common things. I agree with putting everything to PostGus. Open source. I really didn't mention that. The thing you're building is open source, which is great. This is super cool. And like we don't need extra things on critical path.

That's great. Also, I guess you have self-served option as well, right? If it's open source, you can self-host yourself. Freedom, right? It's great. And you run also, you can run the boss. on RDS, absolute freedom. But when you say, let's split it,

it's against the first principle. First principle, let's have it everything in one place. Because if we have this thing and we have other tables, we can organize code right inside database. Sometimes it's a bad idea if it's very long, CPU consuming. But if it's something simple, I want to update everything inside,

like using triggers, PLPG, scale code functions, and so on, I don't want to split. But once I have database, say, terabyte in size, and I start some analytical queries right there, because I'm not grown enough to have click house or something. I have only PostGos. Right. Those long-growing queries will take time, right? And in this case, updates and that type of MVCC in PostGOS actually is not a good thing to deal with, as we all know.

Right. This is, I'm asking because, like, you know that I'm trying to revive this PGQ from Skype, which is blood-free, almost no updates. For event table, there are no updates there. But I don't see clearly how it will be used to implement workflows yet, but for many tasks, it's great. And we don't have problems with blood there. And I'm trying to understand how operate properly.

In case of updates, we need to establish some rules. Like, for example, we should stop allowing long running transactions. I'm glad I participated in building transaction time out. So we said transaction time out, say like 10 minutes. That's it. And I'm very curious, like maybe there is a way to define some boundaries and rules when it's time to move away to like to split different post-gast cluster, right, to split these workloads.

And there are no good rules yet. Yeah. Why is that you don't have to split multiple Postgres clusters or surfers? You can, if I remember how automobico it works correctly, it is isolated across multiple databases on the same cluster. Logical databases, yeah. Yes. So like the X-Men Horizon is set per database.

So you don't have to split your physical infrastructure. You can share physical infrastructure. Yeah, that's a good point. I agree. Still, I feel like it would be great to have some benchmarks or something to define when it's time, when it's time to split, when it's fine, and which transactions should be disallowed. I think you're very right.

If you have 30,000 workforce per second, your requirements become much stricter in terms of what means long-running transaction, right? How much XMEC horizon is lagging? Anyway, thank you for diving into this topic. I'm also trying to learn this myself. Yeah. I think that's actually a good, really good point

because you were right that if you put, there are benefits of co-locating the workflow tables with your actual application data. One thing we were talking about in some of our blogposts is this transactional outbox pattern. If you say someone, like we updated a customer data, now we want to kickstart some of the workflows. Then by co-locating them in the same database,

you can do it in a trigger. Say whenever you update this customer data, automatically start or in queue, a deboss workflow in the same database. And that's really convenient, and that's a way that you can guarantee whenever there's a date in this table, you'll kickstart a workflow that is durable,

that deboss will guarantee you will finish. And that's a pattern that is really difficult to do with, say, like, external orchestrator because there will always be a gap. And by collocating in the same database, there's a way to close this gap. But everything has a trade-off, like you said, If you put in the same database, you have to be really careful about what core is you put in that database,

like how to avoid head-up line blocking, how to avoid loading in that database. So I think that's a topic we're continuously benchmarking and also by talking to users and see what kind of workflows and what kind of workloads they're running. And we are also trying to categorize like a more detailed guidelines for people as well. Yeah. Interesting. But anyway, I'm glad that this topic. is becoming more and more popular and other companies started to join like Microsoft recently, right, with PG durable. What do you think about that system? Yeah, so this is great. I think PG durable is mostly for pure sequels, right? It doesn't really work for if you want to send an email or interact with external systems. So we'll definitely take a look and see if there are any

ways to collaborate or borrow ideas from PG durable. But I think in general it's another validation the post-gris pass work like. Yeah, yeah, more and more people start looking in the same direction. I think, yeah, the topic is warming up. I agree with you here. Also, there was a system called Absurd,

which got my attention, single SQL file as well. I think it was released last November. And, yeah, I noticed in PG-Durable is that the tendency to have SQL PLPG-SQL code quite an infameral way. And this is, like,

you're just passing it. as a parameter like to lambda functions, right? And this concerns me because I want my code still to be in Git, right, to be versionable, fix, reviewable and so on, right? So this leads me to question, what are the best use cases, case studies you had already where you observed, I'm sorry, like I pronounce a DBOS for myself. I don't know why. What are the best case studies, use cases you have like where it shines in terms?

of how like it suits really well, right? Sending emails or like processing orders in e-commerce or something like this, what are the best cases? Yeah, the thing about workflows is that they're really powerful, they're really powerful for a lot of things. So of course, the really hype new use case we see is AI agents and operations around them. So people using workflows both to make their actual agents durable. This is particularly important for long-running interactive agents that might talk to a person or do multiple rounds of conversation with a person to require approvals for a person over the course of hours or days.

Similarly, data pipelines like document processing pipelines for agents often require durability. And workflows can really help there. So those are kind of the new use cases. And then there's this whole host of traditional business workflows that have always needed durability and we're supposed. Postgrespect durability just makes it easier to provide it. And that's things like logistics. It's things like lab automation. It's things like new user registration, making sure new users are properly updated in every single

one of your corporation's databases. So we see this really broad spectrum of use cases for workflows because really any important operation that touches customer data, touches important data, probably should. be a workflow if you're really operating at skill and you really care about reliability. I think at summer we really view Postgres as the central orchestrator to connect things together. You can connect external systems to your local database or you can do event processing to connect multiple systems like your other databases or your email server payment system, all sorts of things. So we really try to make sure your Postgres is the glue for

everything. Right. And speaking of Posgas, maybe last question from me. So now Posgis 19, beta 2 just released. Postgas 20 development has started already.

What do you think should be changed in Postgas or brought to PostGos to make the product you are building even better? I think we do have to go, I would like to go back to notify removing that global lock

is not easy. And I'm not sure if it's doable with the way Notify is currently implemented, but that area of the code hasn't really been worked on much since Postgres 9, and maybe there's something that could be done there to remove the footguns from Notify. And even if you don't remove them, I think Notify's really complicated performance characteristics should probably be actually documented, instead of having to figure this out like through by i mean i figured it's how basically everybody by reading the postgres source code that that's one

thing yeah i think another thing is about like how to help better even better support for a larger larger blobs or larger columns when you are using debaubes sometimes they want to checkpoints say a pdf or something as part of the output and still i know postcards had some good support for larger blobs right now but i think most of the time we still recommend people to say upload your large documents to S3, then store a pointer in the database, but that still leaves a little bit

gap in the durable checkpointing. Because there could be the case where you upload something, but you don't checkpoint, or vice versa. It'll be great if we can really put more, like, larger data into Postgres. There is a nice change,

I think, coming in 19 around that in that, in that the, I think the default toast compression is changing. from an older PGLZ, like a Postgres-specific compression algorithm to, I think it's LZ4, but yeah, only minor on the grand scheme of things. Nice one. Yeah. Yeah.

And speaking of Notify, I think, yes, global law is still there, not removed. I remember some work last year. There was work in 19 on improving the performance of broadcast, the note of the note of I broadcast when not all listeners are listening for all messages, which is great. It's a real performance improvement. The global lock is much harder to get rid of, and I'm not sure if it's possible. I remember work on removing that lock. I remember that work.

I also remember I just founded my email to document, as you said, the limitations. From July 10, 2025, nobody answered my email. So there is a patch proposal. Let's document it at least. Yeah. Certainly 19 doesn't include any work on the global lock. Maybe there's some in development for 20. I'm not sure.

Yeah, yeah. It's worth checking. And that documentation should be changed. I agree with you. So maybe someone listening to us will go and comment on that proposal and we will get documented at least. Great. Thank you so much.

I enjoyed it a lot. I wish you all the best with this wonderful product. I'm going to try it in a couple of places. And I encourage our listeners to try it out, especially it's open source. so it's so easy to start, right? Thank you. Nice one. Thanks very much, both you.

Yeah, thanks a lot. Yeah, have a great week. You too. Bye-bye.