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: DeepSQL – A self-hostable DBA agent for Postgres and MySQL
DeepSQL is a self-hostable AI DBA agent that monitors, optimizes, and manages Postgres and MySQL databases, promising cost reduction and performance improvements.
Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents
EterDB is a Postgres fork that allows transaction-level undo and dependency-aware recovery, enabling easy reversal of mistakes in production databases without full restores.
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.
Open Source Durable Objects for Postgres
Solid Objects is an open-source library that implements a durable objects model for PostgreSQL, SQLite, and MySQL, providing stateful, ordered processing without vendor lock-in or additional infrastructure.