Show HN: DBOSify – Drop-in Temporal replacement built on Postgres
Summary
DBOSify is a drop-in replacement for Temporal Python that uses Postgres instead of a Temporal server, enabling durable workflows without additional infrastructure.
View Cached Full Text
Cached at: 06/27/26, 03:48 AM
dbos-inc/dbosify-py
Source: https://github.com/dbos-inc/dbosify-py
DBOSify
DBOSify is a drop-in replacement for Temporal Python that uses 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 this library, import dbosify instead of temporalio and connect your workers and clients to a Postgres database:
Usage
To install:
pip install dbosify
This is a drop-in replacement: simply import dbosify instead of temporalio and connect your clients and workers to a Postgres database instead of a Temporal server.
Further documentation here.
import asyncio
import os
from datetime import timedelta
from dbosify import activity, workflow
from dbosify.client import Client
from dbosify.worker import Worker
# Set this to a connection string to your Postgres database
DB_URL = os.environ.get("DBOS_SYSTEM_DATABASE_URL")
@activity.defn
async def compose_greeting(name: str) -> str:
return f"Hello, {name}!"
@workflow.defn
class GreetingWorkflow:
@workflow.run
async def run(self, name: str) -> str:
return await workflow.execute_activity(
compose_greeting, name, start_to_close_timeout=timedelta(seconds=10)
)
async def main() -> None:
worker = Worker(
DB_URL,
task_queue="greetings",
workflows=[GreetingWorkflow],
activities=[compose_greeting],
)
async with worker:
async with await Client.connect(DB_URL) as client:
result = await client.execute_workflow(
GreetingWorkflow.run, "World", id="greeting-1", task_queue="greetings"
)
print(result) # Hello, World!
if __name__ == "__main__":
asyncio.run(main())
How It Works
DBOSify runs each Temporal workflow as a Postgres-backed DBOS workflow. A deterministic interpreter runs the workflow (both its main coroutine and its signal, update, and query handlers) on a virtual event loop that only advances when an event arrives. Using DBOS steps and workflow communication primitives, all nondeterministic actions are checkpointed in Postgres before the workflow observes them.
- Activities and timers become DBOS steps and durable sleeps, each checkpointed on completion.
- Signals, updates, and cancellations are durable messages delivered through Postgres using LISTEN/NOTIFY.
- Recovery re-runs the workflow on a new worker: the interpreter replays the same sequence of operations against the recorded checkpoints, so execution resumes where it left off and completes exactly once.
- Namespaces each map to their own Postgres schema; a
Clientwraps a DBOS client and aWorkerwraps the DBOS runtime.
How It’s Tested
As DBOSify is a drop-in replacement for Temporal, its tests cover both correctness and conformance with Temporal using the following strategies:
- Ports of all relevant Temporal Python unit and integration tests
- Ports of relevant Temporal Python sample applications, verifying DBOSify is a drop-in replacement
- New unit and integration tests, with an emphasis on kill-and-recover tests verifying deterministic failure recovery
- Signature parity tests mechanically asserting the public APIs of these libraries are identical (with documented exceptions)
What This Is Not
- No wire protocol compatibility. There is no gRPC wire compatibility. Temporal SDKs in other languages cannot connect. This replaces the Temporal server and Python SDK altogether for Python-only applications.
- No Temporal Web UI,
temporalCLI, or tctl. You operate workflows with DBOS’s workflow-management APIs and DBOS Conductor instead.
See this documentation for information on architectural differences and feature compatibility.
Similar Articles
Looking Forward to Postgres 19: It's About Time
PostgreSQL 19 is finally introducing native temporal table support following the SQL:2011 standard, replacing the old manual approach with exclusion constraints. The article explains the limitations of the current method and the long-awaited benefits of the new feature.
Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite
Honker is a SQLite extension that adds PostgreSQL-style NOTIFY/LISTEN semantics, enabling durable pub/sub and task queues without external brokers or polling.
pg_durable: Microsoft open sources in-database durable execution
Microsoft open sourced pg_durable, a PostgreSQL extension that enables durable execution of long-running SQL functions with automatic checkpointing and fault-tolerant resumption.
@ycombinator: Ardent (@ArdentAI) let's you clone any Postgres DB <6s at TB scale so coding agents can test their code and engineering…
Ardent is a Y Combinator-backed tool that clones any PostgreSQL database in under 6 seconds at TB scale, enabling coding agents and developers to test code on production-like clones without risking downtime. The tool is already being used by companies like Supermemory and Surface Labs.
Show HN: Streambed – Stream Postgres to Iceberg on S3, Supports Postgres Wire
Streambed is an open-source CDC engine that streams Postgres WAL changes to Iceberg tables on S3, with a built-in query server using DuckDB that speaks the Postgres wire protocol.