Making Software as Durable as Data with Peter Kraft from DBOS

Most workflow and orchestration tools rely on external systems and fragile state management, making it hard for applications, especially AI agents to recover from failures or long running interruptions.

In this episode, David talks with Peter Kraft, co-founder of DBOS, about a new approach to durable execution. DBOS is a lightweight, database-backed library that checkpoints program state so applications can resume after crashes, upgrades, or API failures. Originating from Stanford research with Matei Zaharia and Michael Stonebraker, the idea is to make software as durable as data by storing application state in the database.

 eter walks through what makes DBOS unique: the ability to run in-process while still giving you the durability, distribution, and observability you'd expect from a dedicated orchestration layer. The two also explore how AI agents will create new reliability challenges and why CockroachDB is a natural fit. 

Learn more about DBOS: https://www.dbos.dev/

00:00:03.840 — 00:00:42.960 · Speaker 1

All right. Peter, how are you doing today? Hey, great to see you again, David. Yeah, it's been great. I know we had to move this recording a few times, but I'm glad we made it to this particular conversation. For everyone listening in today, I'm speaking with Peter Kraft. He's a co founder of this amazing, exciting company called Debus.

And you know in preparation for this I've been trying around the product. And obviously we are also working with DBus as partners. So there's some exciting stuff that we want to talk to you about. But before we get into all of that, Peter, tell us a little bit about yourself and where you're based out of and what made you do what you do today.

00:00:43.000 — 00:01:31.970 · Speaker 2

This all got started with, uh, back when me and my co-founder, uh, Chen were in grad school together at Stanford, and we were working on the idea that turned into dbus as as a research project for basically the last half of our time in grad school and the idea that we developed in grad school eventually turned into the company was, what happens if you take all the state of your application and store it in the database, right?

Can you make your application as as durable and reliable as a data? You already sort of databases. So we took that idea. We we explained it in the research side and then we realized it was it was a really powerful idea. And if you did it this way, you could build really, really reliable software very easily.

So the two of us took this idea and built a company from it, and we've been working on that for the past couple of years now.

00:01:31.970 — 00:02:00.700 · Speaker 1

And that's awesome. And and you're too humble in your introduction. I mean, you've been you've been you were at Stanford working on this for a bit, and you were also working alongside, you know, Michael Stonebridge, the legendary Michael Stone Baker who's behind ingress behind Postgres, and then obviously Matt Zaharia, who from the Apache Spark fame that turned into Databricks.

So you're you're working around and being around some really good heavy hitters. So yeah, That's also exciting.

00:02:00.740 — 00:02:17.740 · Speaker 2

Yeah. Matteo was my. Was my advisor in grad school. And then Mike at MIT was like the the lead on the on the overall research project. So he was the one who originally, you know, he'd been you've been looking at various this idea for maybe 20 or 30 years. And then we finally came together here and Matteo decided to actually go build with it.

And that's, that's that's what turned to us.

00:02:17.780 — 00:02:57.860 · Speaker 1

Yeah. I mean, it's super exciting. So for everyone listening in, I mean, obviously there is so much we wanted to talk about and especially in the context of, um, you know, why you're building. You know, I would say the right way to put it, a reliable workflow is backed by database infrastructure. Like, that's like a sweet spot.

And the world of AI agents is it's going to become so much more relevant. So we want to cover all of that. But for our listeners who probably are people who are like probably regular developers, architects who are from the try catch exceptions era of coding, you know, or which is what we typically do, um, to help people understand what makes D-Bus different, like what is dbus?

00:02:57.940 — 00:03:49.790 · Speaker 2

Yeah. So the core of it, The boss, is a really lightweight, database backed library for durable workflows. So that's a lot of work. So what I want to I want to break it down. What D-Bus does is that as you run a program and that program could be an AI agent, or it can just be a normal program. D-Bus regularly checkpoints your your program's progress in your database.

That's kind of like save points in a video game where, you know, in a game you're playing it. And every so often you save your progress. And if you die, you can reload from your last save. And, you know, dbus every so often at checkpoints, your program's progress to the database so that if your program fails in some way, if it crashes, if something goes wrong and it cuts out, you can go back and reload from the from the last checkpoint, save your database and resume your programs that the error didn't happen.

That's the core of it.

00:03:49.990 — 00:05:14.690 · Speaker 1

We'll put together. You know, I mean, this concept that you're talking is well understood in the database world, right? Like we know transactions. We want to make sure transactions are durable, acid consistent. But what you're doing with DBus is bringing that to the application level, right. And making sure that if it's AI agents or if it's like, you know, actual application code, you're giving users the ability to have durability.

And one of the best ways in which I started thinking about D-Bus. So here's a true story. I've been working with a partner recently. They have a 30 year old application. Okay. Insanely complex application. Really good application. Great teams, smart people. Uh, but the level at which they have written retries and scenarios where things can go wrong is excessively put into the application code.

So I was just joking with one of my teammates. Man, they need D-Bus because because if you can write just simple code and that code can have checkpoints, you don't have to write that application logic to like, you know, save the progress. Remember. Did the processing fail. Can we try that transaction again?

All these things you can have in the application code itself. So that's super exciting. So I'm really excited about a future where people can start coding, uh, you know, with D-Bus from the perspective of, you know, thinking about just code and not to worry about workflows.

00:05:14.810 — 00:05:30.090 · Speaker 2

Yeah, exactly. Like it lets you write normal code that you have workflows and steps, which and then it just works. And if there's a failure, it just recovers. You don't have to consider every single possible point in which things could go wrong in a right special casing forever. All of it. Right.

00:05:30.130 — 00:05:41.570 · Speaker 1

It's pretty cool. So tell me a little bit about, um, when you were at Stanford. Uh, was this the was this part of your actual project? And this is what turned into DevOps at Stanford.

00:05:41.610 — 00:06:34.740 · Speaker 2

We were looking at a more high at a more research level of what happens if you store application state in a database in general. And we looked at it from several angles. We looked at application state. We also looked at operating system state. And that's where the original dbus name came from. And you know, that led to some research papers.

And but the core idea that I think excited us the most was that you could build this really lightweight interface that stores specifically application state in a database, an interface look like we're durable workflows. And then that's the idea that kind of that's really what was written in our papers.

But that's the big idea we took away from our papers when the two of us graduated and went off to found the company. That was the idea that we that we started building this really lightweight, totally database backed workflows, workflow system that you could put into any library, you could just build a library and put into any application.

It would just work.

00:06:34.980 — 00:07:32.190 · Speaker 1

I've worked on other workflow orchestration systems, and I, I think you can if you can highlight how dbus is different from a workflow execution systems because there are existing workflow executions, orchestration systems, they also kind of do something similar or I would say they're trying to solve a similar problem, but what comes with that is the complexity of learning that workflow orchestration system.

Right. So you're not thinking about code. You're thinking about how can I fit my code to work with this orchestration system? What I started to appreciate more. And this I'm talking from just the last two months of my team working with your team and me trying to do some personal experiments is I actually think about the code and not about the orchestration, because I know that the boss can kind of handle that so that there is a big difference in the way the workflow orchestration system is trying to provide the same, you know, kind of feature or capability and the way how you guys are trying to solve it.

Um, can you elaborate on that a little bit?

00:07:32.230 — 00:09:01.580 · Speaker 2

Yeah, exactly. What we're trying to do is make it as simple and lightweight as possible. I think the classical model was an external orchestrator. That's the way workflow systems used to work, where you have, you know, you write your workflow maybe maybe as code, but more likely as an explicit Dag. And then you load it into a big orchestrator like like airflow or AWS step functions.

This explicit dag. And this thing goes out and this orchestrator calls out to whatever workers are running into your cluster and tells them to execute steps. And that's tricky, because you have to write everything in terms of like steps in an explicit Dag running on a cluster. That is that this orchestrator manages that works.

That's hard, and it requires you to rewrite your program. What we're trying to do in D-Bus is kind of like strip workflows down to the to the bare essentials. So it doesn't require all this infrastructure. All it needs is a library that runs in your process and checkpoints. Your workflows progress, right.

So there's all you really need for you don't workflow system doesn't need an orchestrator. It doesn't actually need to manage your programs execution. It just needs the checkpoint. The progress of your program to a database. And D-Bus does exactly that. And that's a really powerful idea that gives you all the benefits of workflows.

It gives you durability. It gives you cuz it gives you distribution. It gives you observability. It gives you workflow management, the ability to query everything your program has been doing, but it does set all without the footprint of a giant external or orchestrator or a big new cluster you have to manage.

00:09:01.900 — 00:10:08.750 · Speaker 1

Yeah, no, I agree. I mean, and then that's that's the piece that I would love. If you are a listener who is trying to think about what should I do? Go check out dbus. I mean, I'm plugging a chorus of shilling divas here, but I truly believe it's it's something different and exciting. And I like the simplicity of the code.

Right? Because I had an example where I had like this long code, and I completely replaced that in like eight lines, and I was like, oh, look at this work. I like the way this looks, you know? And it's cool. I'm not thinking about an external system. It's all part of the process. So it's cool. Um, so let's take a quick, uh, turn towards, uh, you know, the world that we are in today, I'm pretty sure every person you walk out, including my daughter, yesterday said, daddy, are you using AI to me?

Right. So pretty much it's like my daughter is seven years old. But the reality is, pretty much everyone is aware of AI and the impact of AI and what it's doing, and you have spent considerable amount of years, you know, researching, working on distributed system databases, cloud infrastructure, orchestration systems, workflows.

Why do you believe the next reliability crisis will be driven by agents?

00:10:09.070 — 00:10:10.670 · Speaker 2

Well, we use an agent.

00:10:12.030 — 00:10:13.190 · Speaker 1

Everybody uses it, right.

00:10:13.230 — 00:10:19.749 · Speaker 2

And you know exactly why. Next. Why the next reliability will be driven by agents. Because you use one for ten minutes. We'll do something reliable

00:10:21.110 — 00:10:21.550 · Speaker 2

for sure.

00:10:21.590 — 00:10:30.270 · Speaker 1

For sure. Yeah. But in the context of what you're doing with DBA is like, how do you think DBA fits in the story and can help our users out?

00:10:30.590 — 00:12:13.650 · Speaker 2

Yeah. So DevOps helps build ad reliability agents on two levels. So one of them is the more basic infrastructure level where if your agents are really long running and increasingly agents are, you know, DBAs, less set agent, you know, keep us less the agent run reliably and resume from failures and failures.

And if your agent is running for hours or days, failures are inevitable. Servers has to be upgraded, processes crash and internet cuts out there. The anthropic APIs fail every ten minutes. Like right. The sort of thing. So if you're running long running agents you need this infrastructure. All the infrastructure resilience and D-Bus provides that.

Then the other level at which GPUs provides reliability agents is reproducibility. This is I think, the more interesting and higher level. And this is that D-Bus is checkpointing. Your agents progress. And you can use that not only to recover an agent from a failure, but also to reproduce agent behavior to restart your agent from any, from any point in its execution history.

And this means that if your agent does something, it's not really a failure, but is unexpected. Then on a particular step, then if you're building it with DBus, you can debug it. You can reproduce that behavior. You can take that agent and and replay it from exactly the state where it was initiated, the unexpected behavior, and keep iterating on that.

Maybe maybe changing the underlying prompt until you reproduce the behavior, until you've root caused it, and until you fixed it. This is really powerful because it lets you take it, lets you go and find all the weird things for Asians, doesn't do in production, and then easily reproduce them exactly in reproduce conditions that led to them in dev and over time fix these unexpected behaviors.

00:12:13.970 — 00:12:29.370 · Speaker 1

Right. And for managing all of this state right now, it seems like dbus is also heavily coupled with the database. Right? And do you think that is by design. And you found that that is how it is should be.

00:12:29.410 — 00:12:49.170 · Speaker 2

This is what databases are built for. This sort of complex state management often where you want to do like elaborate queries over the state that you're trying to find, like how many times this particular failure occur. That's a complex score. It's exactly what SQL and databases were built for. So this is storing the state and querying the state.

That's what databases are great at that. And that's why they did exactly the right abstraction to use here.

00:12:49.210 — 00:13:18.020 · Speaker 1

Makes sense. Yeah. And I don't right now. uh, DBA supports Postgres and then we are also we have some uh, we have support with cockroach DB as well. Two different databases, kind of similar, similar ideas, but completely different scale and resilience offered between these two databases. Um, obviously you are working on durability.

You also have to provide resilience. So, um, what what are the what are the decisions and the choices you have to make to make sure that this can work at agent scale?

00:13:18.140 — 00:13:53.750 · Speaker 2

I think what it comes down to is that the main thing is that you have to checkpoint every single step the agent takes. And what's nice about agents is that their steps tend to be fairly large and complex, like an agent step is something like call out into an LLM or execute a tool call. Those are big, bulky, expensive steps.

By contrast, a single write to a cockroach DB cluster or to a Postgres database is not that big. So that means that, like you're adding, the overhead you're adding is actually minuscule because your agents are so expensive and so big that adding one database rate, your database rate is nothing compared to an alarm call.

Right. So you just it just works. You know,

00:13:54.910 — 00:14:00.590 · Speaker 2

your you know, this is compared to what else you do. You're probably already doing through. Should be closer. This is nothing, right?

00:14:00.590 — 00:15:19.840 · Speaker 1

Yeah I agree and I think what people are not anticipating is and this is a it's a thing that when you when you just mentioned like have you used agents I'm like yeah you used agents. I have like ten agents learning and working from me like so, so, so somebody like me who is like running ten different workflows, like even agents are sort of like basically playing out workflows from me.

Right? Like it would be a little bit high level use cases. What I'm coming to notice is that the world or the industry is still not understood at the scale at which a normal human being will start using agents, right? So if one human starts to run 10 or 15 different agents, they might be scheduled working at different times.

The impact on the infrastructure and the, the, the the perspective that you have to start considering durability, uh, reliability is going to become very critical. Like you don't want to come back after two hours and know that your agent failed, you know, and so we we at Cockroach Labs are also thinking about how can we make sure that the world that is going to look like agents running all the time?

Um, how can we make it reliable and durable from our perspective as well? So that's the focus that I see from our side. What do you see that people are not recognizing in this early stage as they start applying these agent systems? And where should they start considering it? Along with DBus.

00:15:19.880 — 00:16:01.650 · Speaker 2

First agents are getting longer running, and that means it's just the raw infrastructural concerns, like what happens if our agent runs for two hours and during that two hours I have to do a server upgrade? That's not a hypothetical. That is going to happen. If your agent runs for two hours, you're going to do a server upgrade at some point.

You have when you have when you have thousands of agents running. And that means that to be resilient to server upgrades, that means that they'll be resilient to that means and basically to make you make an agent resilient to server, where you have to do exactly what dbus does, you have to take the agent checkpoint state, Stored in is something persistent, like a database.

And then after you've refreshed your server's go, resume the agent on a new server. So just if your agents are long running, it's the basic infrastructural stuff requires a workflow engine like D-Bus.

00:16:01.890 — 00:16:27.850 · Speaker 1

It makes sense. Yeah. Um, shifting gears a little bit. Uh, if somebody wants to get started with D-Bus, um, is it great to use dbus for a particular a new application or, or do you think it's easy to start thinking about it in the context of, say, a traditional app and they're trying to modernize that and make sure they're adding these new paradigms to their system?

00:16:27.890 — 00:17:36.940 · Speaker 2

Both. Absolutely. Both. Like one thing we've designed dbus to do. Of course, you can use the build link from scratch. It's always easy to build link from scratch, but we've really, really, really focused on is making it easy to add to an existing system. And that's why being lightweight and simple is is so key to us.

That's why we built it as a library that you can install in any application. Uh, because they protect the most, most importantly, devices incrementally adoptable. You can take this library, install it into a big application, and then maybe only take one key workflow that really needs to succeed and annotate that with dbus, registering things, a workflow and annotated steps.

And then you can leave the entire rest of your application alone. But just this one workflow is now running on DBus and is reliable and will be automatically recovered. If your program fails, then if that works well, maybe you can take a second workflow in a third workflow, and then over a few months, maybe you've modernized your entire application, but the key is that you can add dbus non-intrusive, and you can add it incrementally so you can slowly, over time, add resilience to it, to a large application that already exists.

And you can do it using a fixed already exists. Like if you're on cockroach DB, you just connect your existing cockroach. You don't need to spin up anything new, right?

00:17:36.980 — 00:17:58.110 · Speaker 1

You completely make sense because all you're doing is making bringing dbus into the application layer. The database layer should work as it is based on that. You know we've been talking about AI agents, agent scale, all these different things. Um, do you think there is a need for human in the loop with the way things are still going with agents?

00:17:58.350 — 00:18:57.880 · Speaker 2

Yes, absolutely. I mean, that is over time, maybe we'll see less of it, but actually go in our direction. We might see less of it because agents are getting more or are getting smarter. We also might see more because agents are being asked to do more important things. And you know, those those more important things need a human loop.

And when you have a human in the loop that makes agents, that's something that makes agents longer running, because now agents are going to have to spend a lot, you know, have to spend human time. And, you know, the human might be the human isn't always at their computers. That human time might be hours or days to to wait for people to wait to get permissions or approvals.

And when you have these long running agents, you know, when you have maybe tens of thousands of agents, ten, most of which are currently blocked, waiting for a human approval, then, you know, now you really need infrastructure Support agents that can run for a long time, can be suspended, can wait for hours or days for human approval, and then the stuff like workflows and checkpoint just becomes critical, right?

00:18:57.920 — 00:19:35.840 · Speaker 1

And this is important because, you know, when you build systems like this, one of the common occurrence is like, so what I do sometimes is I'll have a bunch of agents running, and this agent is waiting for me to approve a slack message, and then I get on the call. I'm not available for an hour. He's still stuck there.

Sometimes I've noticed that the connection will fail, like it's basically waited for an hour, and then I have to ask the agent to do the same thing again. And this is a very real use case, and I'm sure what you just explained is what people are going to start observing is that when they run long running agents, they have to make sure that they do some sort of state management, exactly that they need to build into it.

00:19:35.880 — 00:20:01.810 · Speaker 2

When we talk to our customers, the ones who are running agents that run for hours or days, the biggest reason that agents agents run for a long time is because the agents have to wait for human approvals, and as soon as you introduce a human to the loop. Uh, you know that human like you said, the humans in meetings, the humanists use the bathroom.

The humans not always at their computer. As soon as you see them in the loop, you have to budget, like, at least a couple hours. And if it's not, or maybe a couple of days to get that human response duration has to be resilient to that.

00:20:02.130 — 00:20:14.090 · Speaker 1

Right? No, absolutely. It's a great point. Um, what are the customers that you're seeing? Uh, start to adopt D-Bus and, and really understand the power of what you guys are offering.

00:20:14.130 — 00:21:38.820 · Speaker 2

I'd say probably about half of our of our users are building agents. We're seeing D-Bus used for a lot of different parts of the of those agents. Uh, some, some of the users are like like we mentioned earlier, using dbus to make really long running agents, uh, resilient. So, you know, building agents that can wait for human approvals, that can wait for hours or days and and keep going.

Some users are build using DBus to build the data pipelines that power reagents like, you know, some using dbus for document processing where you have these data pipelines that are processing millions of documents, and those are big distributed jobs that have to run across dozens of machines and run for hours and are going to inevitably deal with a lot of failures.

You use D-Bus to make sure that you can process these 100,000 or million documents durably, and make sure they all actually process, no matter what failures happen. Some people are using dbus for agents that have really complex distributed tool calls. Like, like one of our biggest customers is doing deep research agents.

And those agents have really expensive web scrapers as tool calls that are resource intensive. So an individual agent has to run, distribute it over several servers and then dbus coordinates that and make sure that even when the agent fans out to, you know, 100 of these parallel web searches that each consume a lot of memory, that those all complete.

And maybe if a process looms, that process eventually gets recovered and the web search is all complete and the agent can go back to what it was doing, right.

00:21:38.980 — 00:21:51.190 · Speaker 1

Makes sense. Yeah. Is there an effect of using D-Bus with your existing code in terms of the application performance or, you know, or do you think it's going to get improved because the application doesn't have to do a ton of things?

00:21:51.190 — 00:22:34.390 · Speaker 2

Now, if your application was already doing something for reliability, if it was already related to failures, then D-Bus is heavily optimized. It's probably faster than what you were doing already. And if you're adding D-Bus and you know, overall, especially for your genetic application, where, you know, an individual step is something like an LLM call is going to take a few seconds or a tool call that might take a few seconds.

D-Bus is a dbus is all dbus does make. Its checkpoint is a single database, right? Which is a couple of milliseconds. And that's really nothing for most of these applications. So performance you know, performance overall is totally fine. Like most people are focused on the performance of their agent and not the performance of the of anything else because it's just a thousand times slower than anything else in your system.

00:22:34.430 — 00:23:04.850 · Speaker 1

Yeah. And I think agent systems have to kind of if there's a trade off also. Right. If you've noticed it that an agent has when it has to do something, it has to probably pull in a certain number of tokens input outputs and is trying to process them out. It's going through results, and then at some point it's also has to save these actions somewhere and then also has to manage the state.

So there's a ton of things happening. So if an agent stops after it's pulled in say half a million tokens. Yeah. Then you ask to go back and do the same thing again.

00:23:05.250 — 00:23:14.210 · Speaker 2

It's now if you can take one long running agent execution and resume it from the middle instead of resuming it from the from the beginning, I have saved you more time than every database checkpoint you've ever done.

00:23:14.370 — 00:23:47.420 · Speaker 1

Exactly. Yeah. And I think what you said is the is one of the best analogies that I'm going with to it. You you introduce D-Bus as how you're playing a game. And when you play a game, you want to checkpoint the game or save the game at different intervals. Because how much is it that we who gamed hated it, that you made certain progress and then you're like, shit, I haven't saved the game.

I need to replay the whole thing again. Yeah, I think that's like the easiest way to explain what DBus can help with with respect to agents because from my vantage point. Yeah. Go ahead.

00:23:47.500 — 00:23:53.220 · Speaker 2

Yeah. You're you're spending, you know, three seconds out of save three to make up for an hour of actual gameplay that you don't want to redo.

00:23:54.060 — 00:24:23.140 · Speaker 1

Exactly. Yeah. And I think one of the implications of this agent stuff, and I think we could dig into this as well, is the cost effect, right? The token cost is, you know, it's it's a considerable amount of money that is going to get used. And if you run agents that of failing to maintain state and are not saving where they need to start from, then you basically replay those tokens again.

And that can be considerable cost at scale, which is which is something that I don't think people are talking a lot about. But how do you feel about that?

00:24:23.180 — 00:24:50.230 · Speaker 2

Yeah, absolutely. Like this is especially for actually the document processing use case won't receive that a lot because of the document processing use case. You're that's where the cost can really balloon like because a single job can actually then be hundreds of thousands of documents, tens of millions of tokens.

That's something where the cost of a single job is so high that just durability on that one job is is not having to restart it from scratch is a meaningful time and money saver, right?

00:24:50.270 — 00:25:12.950 · Speaker 1

It makes sense. Yeah. And, you know, I think one of the things I've discovered while I was using D-Bus is that, uh, it's fun. It's pretty easy to start off with, like you already are providing like Python code. What else do you have for other users? Like, can you elaborate on what programing languages that you support?

Right now I was using Python. Uh, but can you elaborate on that? Because Python was really easy to get started with.

00:25:13.110 — 00:25:57.720 · Speaker 2

Languages right now are, uh, Python, uh, TypeScript slash JavaScript, uh, go and Java. So those languages are all at parity. So Go and Job are a bit newer, released uh, late last year. Python and TypeScript are original languages. Those languages are all parity. So features built in one all get ported to the others, and they all share a common uh, system database implementation, a common database schema.

They're all interoperable. So you can actually, you know, enqueue a workflow from TypeScript into Python or Java, which is actually something people want to do because you have a, you know, a TypeScript web server backend that you don't want exiting complex job. So you have it in a workflow in your Python or Java workers actually goes and execute those jobs.

So they're all the feature parity, they're all interoperable. And you can get started in any of them.

00:25:58.160 — 00:26:39.680 · Speaker 1

Yeah that's cool. So if you if you are somebody who's listening, who's thinking about building agents, that you've learned a few arguments from Peter Nye as to why you should be doing state management, uh, just obviously cost and as you can as you heard from Peter, you can start off by using it with Python or whatever programing language you're familiar with.

They kind of support everything. I feel like I'm plugging D-Bus here for everyone, but go try it out. It's pretty cool. Uh, Peter, let's shift a little bit. Um, uh, talking about so if somebody wants to get started with D-Bus. Right. Uh, are you offering this as an open source project right now? Do you have a managed, uh, solution?

How do how do they get started with that?

00:26:39.720 — 00:27:51.420 · Speaker 2

Yeah. So the core D-Bus libraries are our fully open source. You just go to docs dev, open the quickstart. It'll tell you how to get started with the open source libraries in your favorite language, and the only thing you need to get with the open source libraries is is a database. So a recipe database or a Postgres database.

For for getting started you can also use SQLite. But for production you use it use it use a real database. That's our core feat as open source. And then for production use, we also commercially offer a set of observability, a set of tooling. So observability dashboards automated recovery we call that conductor.

So that's our commercial product that we get that provides a tool that helps you run dbus workflows in production. And that can be totally self-hosted by you or that can be managed that can be managed by us. And that's an intrinsically privacy preserving architecture. So conductor stores absolutely no data about your application.

So you can. Yeah. So you can. So, you know, because all of your data remains resident in your database and your cork should be in your Postgres. And conductor only there to provide, provided, to provide tooling, to provide dashboards, and to help coordinate things like recovery and workflow retention.

Very useful in production.

00:27:51.780 — 00:28:02.340 · Speaker 1

Yeah. Very cool. So so the conductor capability is basically comes with, you know, oversight, monitoring, uh, for everything that they need to run it at enterprise scale.

00:28:02.380 — 00:28:26.460 · Speaker 2

Yeah. Yeah. Yeah. It's tooling. It's like here your dashboards here is your here's your automated alerting. Here is your your managed recovery. Here's your here's your configurable retention policies. The Tony that you want to operate things. But the core workflows library like the thing that the staff would actually the course that that goes into your application that all is included in the open source library.

And all the data from that is stored only in your database. So nothing is ever said to us.

00:28:26.540 — 00:28:55.910 · Speaker 1

Makes sense. Yeah. And so and going back to what you mentioned with databases, you basically bring your own database BYoD. Right. Uh, bring closed spring cockroach DB um, with respect to cockroach DB and you know, what have you like? Tell us a little bit about obviously, you know, Postgres. You've worked with Michael.

Uh, tell me, uh, now, after using cockroach of trying that with dbus, what do you like about the product and how do you feel it's going to add value to the customers who are going to use cockroach with D-Bus kind of option.

00:28:55.910 — 00:31:01.450 · Speaker 2

So Kafka is an incredibly cool system. And I mean, this is something I read the original papers back in grad school, right. Like this is something that's been around for a while that I, that I was researching back in the day, and now it's actually working with you guys. The thing Cocker DB brings to the table more than anything, there's a lot.

But the most important thing at scale cockroach is Postgres is a single node system. You have your one Postgres and if you want a bigger Postgres, you get a bigger machine. And if you want to scale past 96 cores, then you get two separate Postgres and figure out how to shard your data across those. You can do that.

It works well, but what's what's better than that, especially at massive scale, is like an actual distributed system, like a system where you can have any number of nodes and they all work together and give you the abstraction of a single database that's distributed across many nodes, potentially distributed across many regions internationally.

That's when you're really, really, really trying to run applications at massive, at global scale. Then this is invaluable. So I think the two things that Cocker should be where Cox should be is that Cox could do that. No other Postgres can do in a D-Bus context is first run applications at truly massive scale.

If you're processing, you know, tens or hundreds of thousands of workloads per second, and you need something like Hawker's to keep up with that level of transaction volume. And also like if you're dealing with data sovereignty issues. Cox DB is something I believe is also, you know, recently started to like added a lot of support for where you can specify that some of these workflows run in in Europe or in Germany.

And they handle and they keep all the data reside in Europe or in Germany and the workloads that data. Also the data lives in Germany and the world is attached to data. Only live in Germany. And that way your global database can remain compliant with data sovereignty regulation in each individual country which you operate.

So, so scale in terms of transaction volume and scale in terms of like global distribution. And the ability to comply with like increasingly complex regulation are places for Coquetry really excels.

00:31:01.610 — 00:31:37.810 · Speaker 1

No. That's awesome. Yeah. And for everyone listening in we are working with DBA as you know, as partners we are we're going to have more more stuff come out for you. If you're trying to use cockroach for D-Bus and it'll help you get started as well. Um, in this same context, Peter, I want to ask you, like, um, we were talking about domains and use cases.

Uh, what domains do you think? I mean, obviously this is, you know, workflow execution and durability is kind of kind of applies in pretty much every tech use case. But where have you seen the sweet spot in terms of, uh, you know, domains that can take benefit of dbus immediately?

00:31:38.010 — 00:32:34.780 · Speaker 2

Yeah. So we definitely see the fastest growth in agents. And I think that's because mostly because the the largest number of developers right now are building agents. So anything that's even remotely adjacent to agents is going to see a huge amount of growth. And DBS is really I think this is a core focus for action.

Specifically, D-Bus is like a really lightweight implementation of it is, I think, perfect for building really reliable production ready agents. Yeah. We also see D-Bus used for just a lot of small core business use cases. Actually, one interesting thing we're seeing is using dbus for, uh, like biotech lab automation use cases where infrastructure has to run on prem.

And what's nice about dbus is that because it just needs your database, you can run it fully on prem, maybe, maybe even in the air gap lab environment. So you can add workflow reliability to this on prem system that that can't really support a cloud hosted orchestrator or a, you know, a complex or complex cluster.

Does your problem not run Kubernetes on your lab? You can't run Postgres.

00:32:35.140 — 00:32:44.470 · Speaker 1

Got it. That's pretty cool actually. And I'm sure there are so many more use cases out there that people have not tried, but it's going to continue to grow, so that's exciting.

00:32:44.750 — 00:33:21.510 · Speaker 2

Yeah, like all sorts of business use cases, just data synchronization. Big one, like just keeping two databases in sync is really hard. And workflows workflows are great for that. Something like a like a log under registration flow setting. Often some of our customers start with this. It's often the first thing that customers builds on DBus because it's it's fundamentally a workflow.

And it's really important that it gets everything right, that when you're onboarding a new a new customer, onboarding a new employee, you actually register them in each of your systems. And that's the thing it needs to be reliable. That's a core business workflow that we've often seen as a as a first thing, a new customer builds in DBus if the customer is a more traditional enterprise.

00:33:21.670 — 00:33:40.960 · Speaker 1

Yeah, yeah. Makes sense. I mean that's awesome. Yeah. Um, I, I wanted to ask this question in the beginning, but, you know, we we started talking about tech and geeking out about it, so, uh, I kind of lost trail of it. Um, you've been doing dbus for a few years now. What? What makes you personally passionate about solving this problem for the world.

Like, tell me a little bit about that.

00:33:41.000 — 00:34:27.280 · Speaker 2

Like academically, intellectually, like I love databases and I love this idea of reliability, this question of how do we build something that's no matter what kind of weird failure happens, it's going to be robust to that. And that's a that's a really engaging problem. It's a really hard problem that most people don't want to solve themselves because there's the space potential, there's just too high.

And it's a really important problem. Like we need software to work. And yeah, especially with agents like we the specializations take on more and more higher responsibilities. We need that software to work and the software doesn't work well. That can be costly. And if the software is important, that can be that can be costly and real mature in material ways to real people.

And so making it to that software actually does what it's supposed to do. And it's easy to build software. It's supposed to be that that's a really cool thing.

00:34:27.360 — 00:34:35.679 · Speaker 1

That's cool. I think one of the things I was thinking about is they're like a D-Bus skill available that an agent can use to like, look at my existing code.

00:34:35.679 — 00:34:50.850 · Speaker 2

And we actually recently released agent skills for for dbus. So we have also a D-Bus MCP server. So this is a really cool tool if you're not familiar with it, unless you just with a single npm command install a skill on your computer so that.

00:34:50.889 — 00:35:26.130 · Speaker 1

The reason why I asked Peter, is because it'd be so cool for me to go look at my existing projects. So say I have a I have a nest JS backend or next, uh, JS backend or whatever. It's just JavaScript, right? Um, I would basically get an agent to download the skill and I say, look at my project and they tell me, where am I going to have my system break and uh, add a, you know, a dbus level skill and help me understand that.

Right. So that'll be that'll be cool for me to like, run, uh, some sort of, uh, I would say compliance check and then apply that. Do you think that's a good use case to start off with?

00:35:26.170 — 00:36:06.300 · Speaker 2

Absolutely. Like I think with these did these skills, did they work like with them, your favorite coding agent, a clod or codex or whatever can actually ad, you know, make dbus work in a non-trivial program. And these skills regularly update them so they they understand all the latest features and APIs.

There's also an MCP server which which is cool. And that lets you that lets your agent engage with your active workflows. So if you like your workflow, if you're if you're running a bunch of test stuff in dev and use some workflows, fail. The MCP server lets your agent query those workflow traces and maybe dig through them to figure out what went wrong, and then fix the underlying issue in your source code.

00:36:06.340 — 00:36:25.540 · Speaker 1

That's cool. Yeah, I mean, I'm just excited to go try it out. Thanks for telling me. It's exciting. Uh, I wanted to ask you a question, uh, related to, uh, you know, are you are you also a gamer? Because I'll see that headset, and I feel like you're a gamer. I don't know if it's true, but it looks like it gave us it.

Yeah, yeah, yeah. What do you play?

00:36:26.220 — 00:36:32.140 · Speaker 2

Uh, I play. I don't know if this is a gamer, but I play a lot of magic. Uh, magic together. I got this gamer, but I like it.

00:36:33.020 — 00:36:43.920 · Speaker 1

Yeah. That's cool, that's good. Yeah. So tell us what's exciting. What's coming? What should we be looking at with the boss? Like, what are you guys doing this year? That's exciting. Yeah. Something for us to look up to. Yeah.

00:36:43.960 — 00:38:18.130 · Speaker 2

Lots of big priorities. So one thing I think I mentioned earlier that we recently released is interoperability, the ability to take an application written in D-Bus in any language and have an interface with D-Bus written in the other language, like to, for example, in queue work to Python from from from a TypeScript backend.

So that's a that's one of the big exciting features that we just released. Some other things coming soon. One thing we're adding is the ability to, uh, enqueue work directly from Postgres. So if you do or for cockroach DB so if you have say, triggers on your cockroach database, you can now take those and use those to, uh, start workflows or to send messages to workflows so that like further integrates D-Bus into the cockroach or Postgres ecosystem.

So you can do work you can do work directly from, uh, directly from your database and have interactive debug System. Right. We're also like really focused on observability. One set of things that's going to come out is just a bunch of new tooling to make it easier for you to like, view and manage your workflows and production like.

So you can quickly triage workflow failures, and then you can open up your dashboard. And if there's an issue, immediately see the workload failures and dive in, see exactly where they came from, and do more sophisticated like triage and root cause analysis directly for dashboard. So observability is another big focus for us going forward, because one of the big benefits of workflows is that because, you know, because they're checkpointing all your your programs progress.

You can you can observe those checkpoints to see exactly what your program is doing and see why it fails. So it gives you a ton of observability for free. And we want to make our visualizations that much better.

00:38:18.450 — 00:38:33.540 · Speaker 1

That's cool. Yeah, man. That's exciting. I mean, it's very exciting. Uh, so what is your own go to programing AI assistant at this point? Are you a copilot guy, a code guy? Or are you a Codex.

00:38:33.900 — 00:38:35.300 · Speaker 2

Cloud code. Cloud code.

00:38:35.380 — 00:38:42.540 · Speaker 1

Cloud code. There you go. Okay, I'm gonna ask you a opinionated question. Why cloud code and not cursor with opus?

00:38:42.900 — 00:39:20.180 · Speaker 2

I tried cursor back in the day and I think I bounced off of autocomplete. I really don't like curses autocomplete I my understanding I haven't tried cursor in a while in a couple months, but I understand that cursor has moved away from autocomplete in more towards a fully agenda genetic system. You know, maybe if I tried I would like it more.

I really hate the autocomplete. One thing I really like about Claude is that you can, because I use it a lot. You can separate what your agent's doing from what you're from, what's in your ID so I can have what I usually have is on one monitor. I have Claude actively working away and then the other monitor, I have the ID where I'm watching Claude, and having those two be separate makes it much easier to understand what the agent is doing.

If the agent is doing something funny, I can correct it. That makes.

00:39:20.180 — 00:39:21.860 · Speaker 1

Sense. That makes sense, yeah.

00:39:21.900 — 00:39:22.380 · Speaker 2

Also, I like.

00:39:22.380 — 00:39:22.500 · Speaker 1

That.

00:39:22.620 — 00:39:26.020 · Speaker 2

Code is heavily subsidized. So, you know, get it in, get it, get it cheap.

00:39:26.660 — 00:39:46.390 · Speaker 1

That's a good idea. I'm also a big, uh, Claude coder. I don't use Claude code, though. I mean, I use opus, that's my go to model. Um, 4.6 uh, with the way these models are improving and opus 4.6 is, I'm sure you saw a massive jump in the quality in the last 2 or 3 months.

00:39:46.430 — 00:39:48.150 · Speaker 2

4 or 5 five is a big drop.

00:39:48.350 — 00:40:00.310 · Speaker 1

Four five was a big jump. Yes, four five is big. Do you anticipate? We would probably just not have to even look at a code at some point and just trust what the agent is producing. Do you think that it's gonna be the case?

00:40:00.350 — 00:41:04.480 · Speaker 2

It's not close. 4 or 5 is a big jump for sure. I think before 4 or 5, like I had to be. So before 4 or 5, you had to like, be really, really, really picky until the age of do things in like small 5 or 6 line chunks at a time. Right now, I can tell the agent to do larger refractors and let it work autonomously for, for for the order of minutes.

But when I come back, there's always something broken. Now, part of this is like, I, you know, what we're working on is complex, highly concurrent, complex or intricate reliability code where, like, a small mistake can completely break a program, like I told. Just to give you an example, like yesterday, I was telling Claude to refactor.

When I was telling Claude to refactor this to our messaging system, and Claude got it mostly right, but then it just kind of forgot to release a lock because it just probably, you know, it doesn't fully understand what these things are doing. And of course, that means everything is now. Everything's dead and everything's stuck forever.

So that code would be very, very, very broken. But that's like for basic stuff for for greenfield stuff, it works well. But for anything intricate or complex, you have to really know what your code is doing or you're going to be stuck forever debugging what turned out to be an AI for getting it supposed to release locks.

00:41:04.640 — 00:41:49.370 · Speaker 1

Yeah, yeah. No, I agree with you. I also experienced something similar. What I've seen is my like human in the loop effort has reduced. Yeah probably about 2,030%. Pretty 4.4 I'd say 4.5, 4.6. That's what I saw. Um, I, I also feel like one of the issues I'm having with cursor and, and I'm reason I'm probably going to try out cloud code more is once you start doing complex big agent stuff.

As we were talking about, at some point, cursor starts to slow down heavily. Like the whole laptop's, I have like 32 gigs of Ram, but my system starts to like jam as if it's breaking.

00:41:49.410 — 00:41:49.730 · Speaker 2

So the.

00:41:49.730 — 00:41:50.650 · Speaker 1

Separation grade.

00:41:50.690 — 00:41:52.850 · Speaker 2

Separation is really nice. Like, yeah.

00:41:52.850 — 00:41:53.450 · Speaker 1

Yeah.

00:41:53.530 — 00:42:04.810 · Speaker 2

Having it, having the agent in your terminal and then the, the, the, the ID is just an idea with nothing fancy in it. That makes it much easier to figure out what's happening. And it also avoids like, performance issues.

00:42:04.930 — 00:42:20.090 · Speaker 1

Definitely. I mean, that's awesome. That's great to know. Um, so Peter, once again, I mean, thank you so much for coming. Uh, for all the listeners, do you do you have anything that you want to leave them with? A place where they should go, uh. Get started. I know you already mentioned a few things before, but, uh, something that you want to plug.

00:42:20.130 — 00:42:35.500 · Speaker 2

Yeah, absolutely. So I think try it out. Take a look at our docs. Uh, docs at dbus. Dev says quickstart. That'll get you started in just a couple of minutes on any language. Just installed library connected to your database and go. I'll also definitely check us out on on GitHub GitHub.com.

00:42:36.940 — 00:42:44.900 · Speaker 2

That's where all of our open source code is. Come take a look at it. Start the repositories. It's everything's open source. Everything there is really cool.

00:42:45.100 — 00:43:16.980 · Speaker 1

Very cool. So yeah go check out all these things. We are going to link them on the description for on our LinkedIn as well as when the episode comes out. You can see it in the description as well. Peter, it's been an absolute pleasure having you here. Always glad meeting more gamers who are building cool companies, and I'm glad we match our t shirts today.

They've kind of worked out, but it's been an absolute pleasure. And also from from our partnership point, I'm excited about what we're going to do together from from our go to market. So it's going to be exciting. Uh, thank you so much for your time, I appreciate it.

00:43:17.020 — 00:43:20.100 · Speaker 2

Yeah. Thanks a lot, David. Excited to work together. This is really cool.

00:43:20.340 — 00:43:23.140 · Speaker 1

Awesome. All right. Catch you later. Thank you everyone.