We're heading into the harvest season with another productive month of releases and improvements at DBOS. Here's a summary of all things new:
New in DBOS Transact open source libraries
- Improved support for fair queueing
- DBOS Python v3.0 and TypeScript v5.0
- DBOS Golang v1.4 and Java v1.1
- A first look at DBOS for Rust
New in DBOS Conductor
- 10x faster data retention
- Autoscaling policies
- Configurable workflow columns on the dashboard
New DBOS integrations
- Improved Vercel AI SDK integration
- Supabase Edge Functions support
Read on for the details.
New Features in DBOS Transact
Improved Support for Fair Queueing
Previously, combining per-partition limits with queue-wide limits could require multiple queues. The new partitioned queue interface lets you configure both in a single queue, enforcing per-partition limits alongside global_concurrency, worker_concurrency, and limiter.
This is useful for multi-tenant applications: per-partition limits prevent one user's tasks from monopolizing execution capacity, while queue-wide limits protect your workers and downstream services from overload. You can control how much work each user runs and how much your worker or system handles overall, without coordinating multiple queues.
For example, this queue can run at most one task per user while allowing no more than 10 tasks to run concurrently on any one worker process:
Available today in TypeScript, Python, and Go. Java support is coming soon.
DBOS Python v3.0 and TypeScript v5.0
These major releases move workflow inputs and outputs into separate tables, substantially improving performance at scale. They also remove deprecated interfaces and, in TypeScript, several deprecated packages.
The new versions can process workflows created by older versions, but older versions cannot process workflows created by the new versions. When upgrading:
- Update your application version. Don't run old and new Transact versions concurrently under the same application version. If you set an application version yourself, change it during the upgrade. If you use patching, shut down all processes using the old version before launching processes using the new Transact version.
- Upgrade applications that use DBOSClient. Older clients cannot retrieve inputs or results from workflows created by the new versions.
If your application handles large workflow inputs or outputs, or stores a growing volume of workflow data, these major releases can help it scale more efficiently. Separating payloads from workflow metadata reduces the amount of data the database needs to work through for routine operations.
For migration instructions and a full list of changes:
- Python v3.0: Upgrade guide · Release notes
- TypeScript v5.0: Upgrade guide · Release notes
DBOS Golang v1.4 and Java v1.1
Since releasing v1.0 of our Go and Java SDKs, we've continued improving their performance and bringing their features in line with our other SDKs. Highlights include:
- 10x higher throughput for queues, while maintaining low latency even with large task backlogs.
- Separate tables for workflow inputs and outputs, bringing the same storage optimizations described above for Python and TypeScript to Go and Java.
When upgrading, update applications that use DBOSClient alongside your DBOS processes:
- Go v1.4: A v1.4 client can read inputs and outputs from v1.3 workflows, but a v1.3 client cannot read them from v1.4 workflows. Release notes.
- Java v1.1: A v1.1 client can read inputs and outputs from v1.0 workflows, but a v1.0 client cannot read them from v1.1+ workflows. Upgrade to v1.1 before moving to v1.2+ releases (v1.2 coming soon) - the schema migration requires this intermediate step. Release notes.
A First Look at DBOS for Rust
Growing demand from Rust developers inspired us to build a DBOS Rust SDK, opening the door to durable workflows in environments such as embedded systems and robotics.
Currently, DBOS Rust is under active development, with v0.5 now available. We would love to hear what you are building with it and your feedback on the interface.
For a closer look, watch DBOS engineer Harry Person walk through how the library works and how to use it to build durable workflows in Rust.
New Features in DBOS Conductor
10x Faster Data Retention
DBOS Conductor automatic data retention lets you choose how long to keep workflow history in your application’s system database, helping you manage disk usage as your workload grows.
Deleting old data sounds simple, but at scale, we found that deleting workflows could take longer than executing them. Postgres's multi-version concurrency control (MVCC) and the way deletions interacted with our schema made cleanup unexpectedly expensive.
By batching deletions and improving data locality, we increased data retention throughput by an order of magnitude. These improvements help data retention keep pace with high-volume workloads, so old workflow history doesn't become a growing storage burden.
Read our blog post for the debugging stories behind these optimizations and why we didn't simply use table partitioning.
Autoscaling Policies
You can now attach autoscaling policies to your Conductor applications to help match worker capacity to demand. Each policy calculates how many executors each application version needs to drain a specified queue, giving your infrastructure a signal to scale up as work accumulates and scale down as the backlog clears.
For example, you can configure a Kubernetes Event-driven Autoscaling (KEDA) ScaledObject to size your application deployments based on queue utilization.
To get started:
- Attach an autoscaling policy to your application and select the queue whose backlog will drive the executor count.
- Configure your autoscaler to poll Conductor for the desired executor count, either for a single application version or for all active versions.
You can view the policy in your application's Executors tab on the web UI:
DBOS Conductor's HTTP API also lets you set policies and retrieve desired executor counts programmatically, so you can integrate them into your existing infrastructure tooling.
Configurable Workflow Columns on the Dashboard
You can now customize the columns in Conductor's workflow view:
- Show or hide any column.
- Reorder and resize columns to suit your needs.
- Add columns from workflow attributes. For example, if your workflow attributes include a customer key, you can display it as a separate column on the dashboard.
Your column settings and layout are saved per application in your browser's local storage. Select "Reset to defaults" whenever you want to restore the default view.
This lets you tailor your Conductor dashboard to show the information that matters most to your application.
New DBOS integrations
Improved Vercel AI SDK Integration
The @dbos-inc/vercel-ai package makes Vercel AI SDK agents durable with DBOS. Wrap your model with durableCalls and run your generation inside a DBOS workflow to checkpoint model calls in Postgres. If your process crashes, DBOS restores completed calls from their checkpoints and resumes execution.
We've further improved the integration to make it easier to build agents with streaming output, configurable tools, and subagents:
- Durable streams: Stream agent or model output to a client or UI with readDurableStream, which emits AI SDK UIMessageChunk objects. You can read streams from a different process, so your UI can run independently of your agent. You can also write custom data into a stream. If a workflow is interrupted during a model call, DBOS restarts that call and streams its output again. Readers connecting afterward see the output once; live readers receive a transient data-dbos-superseded chunk indicating that the call has restarted.
- Durable tools: Use the new durableTools wrapper to configure timeouts and retries for tool calls. Set defaults across all tools or configure each individually, for example, to retry a tool that calls an unreliable external service. Retries are off by default.
- Durable subagents: Delegate complex tasks to subagents while preserving independent checkpoints for each call. Wrap a subagent in agentTool, then pass it to durableTools like any other tool. Each invocation runs as a child workflow, allowing multiple subagents to run safely in parallel.
These new features are especially useful for agents that make many model and tool calls, wait for human input, or run longer than a single request. If a deployment or crash interrupts the agent, it can recover completed work without repeating expensive model calls or completed tool actions. Durable streams also let your UI reconnect to the agent's output without keeping a connection open for the entire run.
Check it out on GitHub.
DBOS Supports Supabase Edge Functions
You can now add durable workflows, background jobs, and AI agents to your Supabase project using Edge Functions and your existing Postgres database. This lets you run work asynchronously and recover from interruptions without managing a dedicated worker server or orchestration server.
We recommend the following architecture:
- Enqueue work: Use the DBOS client in an Edge Function to submit workflows.
- Execute workflows: Run a DBOS worker in a second Edge Function to dequeue and execute them.
- Start workers as needed: Configure a pg_cron job to start your worker when work is available.
Both functions connect to your project's Postgres database, keeping workflow checkpoints alongside your application data.
Supabase Edge Functions terminate when they reach their CPU or wall-clock limits. Connect your worker to DBOS Conductor so it can detect disconnects and recover interrupted workflows on the next worker that starts. This allows workflows to make progress across multiple worker invocations.
Check out an example application on GitHub, or read the documentation to get started.
Learn More about Durable Workflow Orchestration
If you like making systems reliable, we'd love to hear from you. At DBOS, our goal is to make durable workflows as easy to work with as possible. Check it out:
- Quickstart: https://docs.dbos.dev/quickstart
- GitHub: https://github.com/dbos-inc
- Discord community: https://discord.gg/eMUHrvbu67