It’s been a busy summer at DBOS so far! Over the past month, we introduced high availability and audit logs in DBOS Conductor, we improved performance of durable streams, debouncer, and Kafka integration in DBOS Transact. We released Java 1.0 and improved Go feature parity. We also have several new integrations.
Here’s a summary of what’s new:
New in DBOS Transact open source libraries
- Queryable workflow attributes
- 20x higher durable stream throughput
- Cooperative step timeouts
- Kafka integration improvements
- Debouncer performance improvements
- DBOS Golang v0.19 with transactional data sources
- DBOS Java v1.0 release
New in DBOS Conductor
- High availability deployment for self-hosted Conductor
- Audit logs
New DBOS integrations
- DBOSify: drop-in Temporal replacement
- Vercel AI SDK integration
- Parseable integration
Read on for the details.
New Features in DBOS Transact
Queryable Workflow Attributes
You can now attach arbitrary JSON metadata to workflow executions. This makes it easy to tag workflows with application-specific information such as customer IDs, tenants, regions, request IDs, or deployment environments.
Workflow attributes are stored as PostgreSQL JSONB with GIN indexes, making them efficiently queryable from SQL, the DBOS Console, or the DBOS APIs.
Available in TypeScript, Python, Java, and Go
20x Higher Throughput for Durable Streams
We've significantly increased durable streams throughput, up to 20x higher in many workloads.
The new implementation uses configurable batching to reduce database overhead while maintaining low latency, from end-to-end. This lets applications stream reliably at a much higher scale without sacrificing responsiveness.
Durable streams are useful for reliably delivering LLM tokens, tool results, or progress updates from long-running tasks. With this improvement, DBOS can support tens of thousands of concurrent streams while guaranteeing that clients can reconnect after interruptions without losing progress.
Cooperative Step Timeouts
You can now configure timeouts for individual workflow steps, not just entire workflows.
If a step exceeds its timeout, DBOS raises a DBOSStepTimeoutError. When retries are enabled, the step is retried automatically.
Step timeouts are cooperative rather than preemptive. DBOS signals the timeout via AbortSignal, allowing long-running operations to terminate cleanly. If the step ignores the signal, it continues running in the background, but its result is discarded.
Step timeouts prevent a single slow or unresponsive step from stalling an entire workflow. You can set limits appropriate to each step, recover automatically from transient delays, and keep workflow execution within your application's latency requirements.
Example usage with fetch() by passing in the DBOS timeout abort signal:
Available today in TypeScript. Go supports equivalent functionality through native context.Context; Python and Java support are coming soon.
Kafka Integration Improvements
We substantially optimized the Kafka integration in Python to increase throughput and flexibility while preserving ordering guarantees. New capabilities include:
- Batch event consumption and workflow creation, reducing per-message overhead and increasing throughput.
- Per-partition in-order processing backed by partitioned queues, enabling parallelism across partitions while guaranteeing ordering within each partition.
- Multiple consumer groups per topic, allowing independent applications or processing pipelines to consume the same events.
- Custom workflow queues for Kafka consumers, giving you greater control over concurrency, prioritization, and resource allocation.
Together, these improvements make it easier to build reliable, high-throughput Kafka pipelines that scale horizontally while maintaining the ordering and execution controls each workload requires.
Debouncer Optimizations
We've redesigned the debouncer implementation in Python and TypeScript by eliminating the internal _dbos_debouncer_workflow. This significantly reduces overhead while preserving behavior.
Debouncers consolidate repeated workflow requests within a short window, which is useful for workloads such as processing rapid user updates or responding to bursts of events. Instead of performing redundant work for every trigger, the application runs the workflow only when needed.
With this optimization, debouncers can handle more frequent triggers with lower database and execution overhead, making bursty applications more efficient and responsive.
After upgrading to Python 2.27 or TypeScript 4.24, users should cancel any remaining _dbos_debouncer_workflow instances. Existing application workflows are unaffected.
DBOS Golang v0.19 with Transactional Data Sources
The latest DBOS Transact for Go release continues to improve feature parity with other libraries. It marks another major step toward the v1.0 release.
The new features include:
- Dynamic queues: Queues can now be created, updated, and deleted at runtime via the database rather than only at startup via code. This lets you adjust concurrency and rate limits without redeploying applications.
- Transactional datasources: Enabling application database operations and DBOS durability operations to execute within the same transaction for exactly-once semantics.
- Faster durable streams: Read stream now uses LISTEN/NOTIFY to receive new stream messages as soon as they are available, with polling retained as a fallback mechanism.
DBOS Java v1.0 Release
DBOS Java 1.0 marks the DBOS Transact Java as production-ready, with feature parity across the core DBOS programming model and a stable public API.
The new features include:
- LISTEN/NOTIFY-backed durable streams
- Workflow attributes
- Workflow and step aggregate metrics
- Richer workflow filtering
- Improved Conductor integration
- Numerous stability and interoperability improvements
We expect the public API to remain backward-compatible across future minor releases, making upgrades more predictable and reducing ongoing maintenance.
New Features in DBOS Conductor
High Availability Deployment for Self-Hosted Conductor
DBOS Conductor now supports highly available self-hosted deployments.
Multiple Conductor nodes can run behind a load balancer while sharing the same highly available PostgreSQL database. Your executors (DBOS processes) can connect to any node, and seamlessly fail over to another if one goes down.
Under the hood, leader election is coordinated through Postgres, guaranteeing globally consistent operations such as workflow recovery and retention management.
This guarantees monitoring, alerts, metrics, and distributed workflow recovery remain available even if individual Conductor nodes fail, which helps self-hosting deployments meet production availability, operational visibility, and control.
Read the docs for deployment details.
Audit Logs
Conductor now records an append-only audit log of administrative operations, including:
- Application registration and deletion
- Workflow and schedule management
- API key creation and revocation
- Organization membership and role changes
- Organization configuration updates
Each audit log entry records who performed the action, when it occurred, where it originated, and whether it succeeded. It is available in both the Conductor UI and the Audit Logs API.
Audit logs provide a reliable record of security-sensitive changes, helping teams investigate incidents, troubleshoot operational issues, and demonstrate that required controls were followed. They also support internal governance and compliance efforts for frameworks such as CIS, SOC 2, and other security or regulatory standards.
Read the docs for more information.
New Integrations and Ecosystem
DBOSify: Drop-in Temporal Replacement
DBOSify is a drop-in replacement for Temporal Python that runs entirely on Postgres (through DBOS Transact) instead of a Temporal server. This lets you run durable workflows, activities, signals, updates, retries, and recovery without needing any infrastructure except Postgres.
To use it, just import dbosify instead of temporalio and connect your workers and clients to a Postgres database.
The architecture looks like this:
Check it out on GitHub: https://github.com/dbos-inc/dbosify-py
Vercel AI SDK Integration
The new @dbos-inc/vercel-ai package makes Vercel AI SDK agents durable via DBOS. All you have to do is wrap your model with durableCalls and run your generation inside a DBOS workflow. Then, this integration automatically checkpoints every action your agents take in Postgres. If your process crashes mid-agent, DBOS replays the completed steps from their checkpoints and the agent resumes exactly where it left off.
Because the integration is implemented as standard AI SDK middleware, existing providers, models, and APIs such as generateText, streamText, and ToolLoopAgent continue to work unchanged.
Check it out on GitHub: https://github.com/dbos-inc/dbos-vercel-ai
Parseable Integration for OpenTelemetry Logs & Traces
DBOS now integrates with Parseable for centralized observability.
Parseable can ingest OpenTelemetry logs and traces from DBOS application processes as well as Conductor Metrics:
- Logs and traces are exported directly from the DBOS application through OpenTelemetry OTLP HTTP.
- Metrics are scraped from DBOS Conductor's Prometheus/OpenMetrics endpoint and forwarded to Parseable.
This provides a unified view of application execution and workflow infrastructure.
Docs: https://www.parseable.com/docs/ingest-data/ai-agents/dbos
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