September 2026 Summaries

DBOS announced a range of releases and platform improvements focused on scaling durable workflows, queue management, and integrations. Its Transact libraries now offer a partitioned queue interface for enforcing both per-user and global concurrency limits, while major Python 3.0 and TypeScript 5.0 releases separate workflow payloads from metadata to improve database performance at scale, with important upgrade compatibility considerations. Go 1.4 and Java 1.1 add similar storage optimizations and substantially higher queue throughput, and an early Rust SDK version 0.5 expands DBOS durable workflows to Rust-oriented environments such as robotics and embedded systems. DBOS Conductor adds data retention processing claimed to be 10 times faster, autoscaling policies that expose desired worker capacity based on queue backlogs, and customizable dashboard workflow columns. Updated integrations improve durability for Vercel AI SDK agents through resumable streams, configurable tool retries, and subagents, while new Supabase Edge Functions support enables asynchronous, recoverable workflows using existing Postgres databases and serverless functions.

A Postgres-backed durable workflow system found that deleting expired workflow data can become more expensive than executing workflows because MVCC turns deletions into dead tuples that remain until VACUUM reclaims them. Foreign-key cascades from workflow records to widely dispersed step-output records caused severe cache-locality problems, requiring many disk-page reads and writes. Removing the foreign keys and deleting each table independently in physical creation order substantially improved performance, while anti-joins prevented deletion of data belonging to active long-running workflows. A further issue arose when an indexed query for the next batch boundary scanned millions of dead tuples at the oldest end of the index, causing occasional 20-minute lookups; manual VACUUM runs before and after retention passes resolved this. Although time-based table partitioning could make retention faster by dropping entire files, it was rejected because long-running workflows and varied retention policies make partitions too inflexible.