Building durable workflows with Postgres / SQLite ── Hardening long-running processes in client development without Temporal in 2026

In late May 2026, SQLite is all you need for durable workflows and Building durable workflows on Postgres simultaneously reached the top ranks on Hacker News. Both articles share the central thesis that "teams do not need to adopt dedicated infrastructure like Temporal, AWS Step Functions, or Azure Logic Apps right from the start to make long-running processes robust." For many business workloads, simply persisting execution state in local PostgreSQL or SQLite enables safe resumption across restarts, failures, and deployments.

From the perspective of supporting enterprise business systems and SaaS backends for mid-sized enterprises through custom development, this offers a realistic option to harden long-running operations without adding excessive infrastructure—particularly for "long-running tasks that cannot afford to fail midway," such as "order processing, billing batches, external API integrations, and approval workflows." Connecting this with the backend orchestration addressed in our custom Cloudflare Workflows v2 development, the multi-tenant fault-tolerant workflows in our custom Cloudflare Dynamic Workflows development, and the state model design in our custom DB design to eliminate soft deletes development, we organize "lightweight durable workflow design" as a new custom development offering.

Why "RDB-based durable workflows" are a watershed moment

In other words, RDB-based durable workflows abandon the preconception that "robust long-running processing strictly requires heavyweight dedicated infrastructure," marking a pragmatic turning point demonstrating that "small to mid-sized custom projects can achieve sufficient robustness using the RDB already on hand."

Three structural changes beneficial to custom development projects

Structure 1: From "adopting dedicated platforms" to "leveraging existing RDBs"

Historically, the standard approach in custom development for hardening "long-running tasks that cannot afford to fail" was to propose Temporal clusters or Step Functions. However, many mid-sized enterprises "lack the personnel to operate dedicated platforms," posing the risk of siloing and abandonment after rollout. An RDB-based approach can be absorbed into existing PostgreSQL operational know-how, enabling clients to operate independently even after our team exits. This concept translates the orchestration covered in our custom Cloudflare Workflows v2 development for "clients at a scale that cannot sustain dedicated platforms."

Structure 2: From "black-box state" to "SQL-based visibility"

The biggest drawback of dedicated platforms is that "execution state is obscured inside a proprietary data store." In an RDB-based architecture, workflow state is visible in your own tables via SQL, allowing incident investigations, auditing, and data corrections to be handled entirely with standard operational tooling. This aligns directly with the philosophy of "making state explicit in tables" from our database design without soft deletes custom development, treating workflow state as first-class data.

Structure 3: From "best-effort retries" to "idempotency + checkpointing"

In the event of a failure, the operational habit of "simply starting over from the beginning" leads to accidents such as double billing, duplicate orders, and duplicate notifications. With RDB-based durable workflows, you can "safely resume from the point of failure" by designing each step to be idempotent and persisting checkpoints. This concept applies the event consistency addressed in our custom Kafka/Flink schema sprawl development to "consistency at the individual workflow level."

Architecture patterns for RDB-based durable workflows

Here is the minimal, reusable configuration we provide in client development.

Pattern 1: Step tables + state transitions

Represent workflows using two tables, workflow_runs (execution unit) and workflow_steps (individual steps), assigning status values like pending / running / completed / failed to each step. Workers poll and process the "oldest incomplete step."

CREATE TABLE workflow_runs (
  id            UUID PRIMARY KEY,
  workflow_type TEXT NOT NULL,
  status        TEXT NOT NULL DEFAULT 'running',
  payload       JSONB NOT NULL,
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE workflow_steps (
  id          BIGSERIAL PRIMARY KEY,
  run_id      UUID NOT NULL REFERENCES workflow_runs(id),
  step_name   TEXT NOT NULL,
  status      TEXT NOT NULL DEFAULT 'pending',
  attempts    INT NOT NULL DEFAULT 0,
  result      JSONB,
  run_after   TIMESTAMPTZ NOT NULL DEFAULT now(),
  UNIQUE (run_id, step_name)
);

Pattern 2: Concurrency control via row-level locking (Postgres)

To prevent multiple workers from concurrently processing the same step, workers safely claim jobs using SELECT ... FOR UPDATE SKIP LOCKED. This standard Postgres feature implements a worker pool without introducing a dedicated message queue.

SELECT * FROM workflow_steps
WHERE status = 'pending' AND run_after <= now()
ORDER BY id
FOR UPDATE SKIP LOCKED
LIMIT 1;

Pattern 3: Preventing duplicate execution with idempotency keys

External API calls (payments, orders, email delivery) must include an idempotency key to guarantee that "running the same step twice yields the result of a single execution." SQLite achieves identical protection using INSERT OR IGNORE + UNIQUE constraints.

Pattern 4: Retries and backoff

Increment attempts and defer run_after using exponential backoff. Once a threshold is reached, transition the status to failed and move the record to a dead-letter table equivalent for manual intervention or dedicated recovery flows.

Which projects are suited for RDB-based approaches (and which are not)

In client development, a phased approach—"starting with an RDB-based implementation and transitioning to a dedicated platform when throughput limits are reached"—offers the lowest risk.

The 5 phases of "lightweight durable workflows" delivered for clients

Phase 1: Workload inventory (1–2 weeks)

• Identifying mission-critical, long-running processes
• Auditing current implementations (cron / manual retries / dedicated platforms)
• Failure history + review of duplicate execution incidents
• Throughput / SLA requirements
• Baseline assessment of idempotency
• Priority mapping

Phase 2: Design (1–2 weeks)

• Step tables + state transition design
• Idempotency key design (per external API)
• Retry / backoff / dead-letter policies
• Observability (status monitoring SQL / dashboards)
• Impact assessment on existing DB
• Migration strategy (phased rollout)

Phase 3: Implementation (3–5 weeks)

• Workflow runtime implementation (polling / locking)
• Refactoring existing processes for idempotency
• Retry + dead-letter implementation
• State visualization dashboards (Metabase / Grafana)
• Integration testing + fault injection testing
• Runbook documentation

Phase 4: Phased migration (2–3 weeks)

• Incremental cutover starting with low-impact workloads
• Parallel execution with legacy implementations + validation
• Monitoring alert configuration
• Operational documentation
• Handover to client team

Phase 5: Monthly operations + continuous improvement (ongoing)

• Analysis of failed steps / retry patterns
• Periodic review of dead-letter queues
• Throughput monitoring (criteria for dedicated platform migration)
• Migrating new workloads to durable workflows
• Semi-annual architecture reviews

Standard technology stack set for custom development

Five clauses to include in custom development contracts

Client-side ROI projection (assuming mid-sized SaaS / 10 long-running processes)

Converted at an hourly rate of ¥8,000, this yields over ¥5,000,000 in annual labor savings plus the prevention of duplicate execution incidents. Even at standard investment levels, this pays for itself in just over a year, with recurring savings from avoiding dedicated platform operational overhead providing ongoing value.

Five common pitfalls

Pitfall 1: Postponing idempotency

Prioritizing "just making it work" and omitting idempotency keys results in duplicate charges and double orders during retries. Design for idempotency from the very beginning.

Pitfall 2: Holding locks with long-running transactions

Wrapping an entire step in a prolonged transaction causes lock contention and connection pool exhaustion. Decompose steps into small units and keep transactions brief.

Pitfall 3: Neglecting polling intervals and index design

Without proper indexes on status / run_after, latency spikes as step volume grows. Keep operations lightweight with partial indexes (WHERE status = 'pending').

Pitfall 4: Neglecting dead-letter queues

Simply setting failed steps to failed without active monitoring causes silent failures to accumulate. Build routine reviews and alert rules into operations.

Pitfall 5: Stagnating without measuring scale limits

RDB-based solutions are not a silver bullet. Failing to monitor throughput leads to sudden bottlenecks when limits are hit. Agree on thresholds for migration upfront.

Conclusion — From "heavyweight infrastructure" to "hardening with familiar RDBs"

The simultaneous buzz surrounding "SQLite is all you need" and "Building durable workflows on Postgres" illustrates that the dogma that "hardening long-running operations equates to adopting dedicated platforms" is breaking down in 2026. From the perspective of supporting mid-sized enterprise backends through custom development, "lightweight durable workflow design"—which delivers idempotency, checkpointing, and state observability as an integrated solution—becomes a compelling new flagship service that strongly resonates with "clients at a scale that cannot sustain dedicated platforms."

If your team is struggling with "having to manually recover failed batch jobs every time," "wanting to adopt Temporal but lacking operations talent," or "needing to eliminate duplicate order incidents," please reach out through our inquiry form.

Sources

• SQLite is all you need for durable workflows（Hacker News 2026-05-29）
• Building durable workflows on Postgres（Hacker News 2026-05-28）
• Cloudflare Workflows v2 Custom Development (GH Media)
• Cloudflare Dynamic Workflows Client Services (GH Media)
• Database design without soft deletes custom development (GH Media)
• Kafka / Flink schema sprawl custom development (GH Media)