August 2026 Summaries

DBOS announced summer updates to its Transact libraries and Conductor platform, including a reported tenfold throughput improvement for partitioned queues through indexing, batched dequeues, and query-planning optimizations that support fairer multi-tenant resource allocation. Migration tools in TypeScript, Python, and Go can now output raw SQL for review or controlled execution, while multiple applications and languages can share one DBOS system database with resource isolation and explicit cross-application workflow coordination. DBOS Go 1.0 introduces production-ready, stable APIs, database-backed queues and schedules, a simplified client model, and optional SQLite support. Conductor now offers a public OpenAPI 3.1-based HTTP API, the scriptable dbosctl command-line client for managing operational resources, and a UI metrics preview for Prometheus/OpenMetrics-compatible workflow and executor telemetry.

DBOS Conductor is a workflow control plane for applications built with DBOS Transact, an open-source library that provides durable workflows, queues, schedules, and recovery through state stored in PostgreSQL. While workflows execute within application workers, Conductor supports production operations by monitoring worker health, automatically recovering workflows from failed workers, enabling high availability and scaling, and providing centralized workflow and queue management. It offers dashboards and integrations for observability, alerting, auditing, troubleshooting, retention policies, and role-based access control, allowing teams to inspect workflow histories, manage executions, and export metrics to tools such as Datadog or Grafana. Conductor does not directly access PostgreSQL or permanently store workflow data, instead communicating with workers through secure outbound WebSocket connections; metadata-only mode and self-hosting are available for stricter privacy requirements. Although DBOS Transact can operate independently, the interview recommends Conductor for production deployments, particularly those using multiple workers.

DBOS describes a performance limitation in PostgreSQL’s `SELECT DISTINCT` when identifying active partitions in Postgres-backed queues. Although an index on queue name, workflow status, and partition key was expected to let the query retrieve one row per unique partition, PostgreSQL instead performed a full index scan across every matching enqueued workflow, causing latency to scale linearly with rows per partition rather than with the number of partitions. This was especially problematic for narrow, deep queues containing few partitions with many workflows, where a query expected to take under a millisecond could take seconds. The post attributes this behavior to PostgreSQL lacking a loose index scan operator comparable to MySQL’s, while noting that PostgreSQL 18’s skip-scan optimization does not address this particular `SELECT DISTINCT` case. As a workaround, DBOS used a recursive CTE that repeatedly finds the next smallest partition key through indexed `MIN()` queries, retrieving one value per iteration and achieving performance proportional to the number of unique partitions rather than the total number of rows.