DBOS

What if your AI agents were built on ACID transactions? Join Postgres creator Mike Stonebraker to learn why transactional databases are becoming the foundation for reliable AI agents and agentic workflows. We'll cover how to build AI infrastructure with better reliability, observability, and correctness. This is a joint webinar with @CockroachDB Thursday, July 16, 2 PM ET / 11 AM PT. Registration link below.

Cool new console feature: audit logging. Keep track of all actions taken by anyone in your organization, durably retained for as long as you need.

The algo seems to decide I should see people I actually know again. So... hi friends! I'm still organizing the South Bay Systems meetup, and we're looking for a venue for our July/August meetup. If your company has space for 60+ people in the South Bay (from San Mateo to San Jose) and would be interested in hosting, please DM me. Thanks in advance. Hope to stay in touch with more of you here.

A surprisingly hard problem when working with Kafka (or other event streaming systems) is processing events exactly-once. If you process each event before committing its offset, you risk timing out; if you process them after committing you risk losing events if there are failures. Durable workflows make exactly-once event processing easier! When consuming an event, enqueue a durable workflow that processes the event, then commit its offset. Because you’re just enqueueing the workflow, not processing it, you won’t time out, but because the workflow is durable, it will automatically recover and complete processing after failures. To guard against duplication, enqueue the workflow with an idempotency key derived from the message’s topic, partition, and offset. If steps in the workflow have side effects in external systems, you should also make them idempotent. To make this work better at scale, we recently released two major upgrades to the DBOS Kafka integration: - Durably consume messages and enqueue workflows in batches (per consumer), improving throughput by an order of magnitude - Add built-in support for in-order processing, allowing you to process messages in arrival order per partition or per topic. Under the hood, this is backed by a partitioned DBOS queue.

Check it out: github.com/SamuelXing/dur… Several DBOS demo apps here: github.com/SamuelXing/dbo…

Happy to see the first community-maintained Rust implementation of DBOS. Durare implements the same programming model, database schema, and execution semantics as the official DBOS Transact, with full compatibility with DBOS Conductor. Huge thanks to Samuel Xing for building and maintaining this. It's great to see the community expanding DBOS into new languages.

It's interesting to see more AI systems rediscover ideas that databases have been good at for decades: transactions, durability, and correctness. I'm looking forward to co-presenting with Michael Stonebraker, the creator of Postgres, this Thursday. We'll talk about why those properties matter for AI agents, and what we've learned building durable workflows on top of Postgres. Thanks to @CockroachDB for putting this together. Thursday, July 16, 2 PM ET / 11 AM PT. Registration link in the comments.

We just released Version 1.0 of DBOS Java! This brings many new features to Java, including: - Dynamic workflow queues - Workflow attributes - Transactional steps - Support for Kotlin, Scala, and Clojure - A native Spring Boot integration …and much more!

We just released DBOS Golang 0.19.0 This release introduces transactional data sources to the SDK. You can now execute your database queries and DBOS durability operations in the same transaction, enabling exactly-once execution. Full release notes: github.com/dbos-inc/dbos-…

Loving this refresh of the DBOS starter app! It now lets you experiment for yourself with all the core features of durable workflows, including workflow recovery, queues, and durable messaging. No matter what you do, you can’t make this little app fail or lose progress.

Postgres is a superpower.

We just released a high availability mode for self-hosted Conductor! You can now deploy multiple Conductor nodes in different failure domains, all behind a load balancer and connected to the same highly available Postgres. Your executors (DBOS processes) can connect to any node, and seamlessly fail over to another if one goes down. Requests can also be sent to any node; if the node cannot serve the request locally, it dispatches to one that can. Under the hood, Postgres-backed leader election coordinates processes that need to be globally consistent, like recovery and retention period enforcement. Check it out: 👇

Register here: cockroachlabs.com/webinars/are-y…

What if your AI agents were built on ACID transactions? Join Postgres creator Mike Stonebraker to learn why transactional databases are becoming the foundation for reliable AI agents and agentic workflows. We'll cover how to build AI infrastructure with better reliability, observability, and correctness. This is a joint webinar with @CockroachDB Thursday, July 16, 2 PM ET / 11 AM PT. Registration link below.

@boristane Yup, just use DBOS :)

durable execution is the only sane way to do long running agents been in the trenches for months now adding heartbeats, fibers, llm checks, etc. migrating now

One tricky problem in workflows is providing real-time updates to a client (particularly an interactive frontend) on the workflow’s progress. This is especially important for agentic workflows because individual steps (like calling out to an LLM) can take a long time and users want to see progress as it’s happening instead of getting one big response at the end. One solution: durable streams. You can stream data from a workflow or its steps for clients to consume and display in real time. The streams are tied to the workflow and backed by Postgres, so they remain a durable record of the workflow’s progress even if it fails and restarts. For example, if a step is querying an LLM, you can stream response chunks to a frontend client to display the LLM’s output as it’s happening.

We reimplemented Temporal with Postgres..

I just wrote a new blog post about metrics! We’ve heard many users request integrations between DBOS and their favorite observability platforms, so we recently released OpenMetrics support to make it easier. Now, you can scrape observability data directly from DBOS into your APM. In this post, I go into detail about how this integration works and how to use it. 👇

One frequent request from users: a simple way to migrate from Temporal to Postgres-backed durable workflows. Today we're releasing DBOSify: a drop-in replacement for Temporal built on Postgres (using DBOS). To use it, just import dbosify instead of temporalio and connect your workers and clients to a Postgres database. This lets you run durable workflows, activities, signals, updates, retries, and recovery without needing any infrastructure except Postgres. Check it out on GitHub: 👇

Some of the DBOS highlights from the last month: - Bulk workflow forking - Role-Based Access Control (RBAC) - Multi-dimensional filtering and aggregate views - OpenMetrics export and integrations with observability platforms - Low-latency durable streams - Pluggable transactional data sources - Atomic bulk workflow messaging - Google ADK integration … and a lot more. The goal is to make it easier to build reliable applications and AI agents without adding more infrastructure. Would love your feedback on where we should invest next.

Cool new feature: Workflow attributes! You can now tag your workflows with queryable JSON metadata. This is useful categorizing workflows by customer, tenant, or however you like. Under the hood, it’s all powered by Postgres JSONB columns with GIN indexes.