DEV Community: Trevor Ogina

Durable AI agents: LangGraph with Postgres checkpointing and a human approval gate

Trevor Ogina — Mon, 09 Nov 2026 12:23:27 +0000

Most agent demos keep their state in memory and act without asking anyone. That's fine for a notebook, but it isn't acceptable when the agent can send an email or submit something on a user's behalf.

When I built a multi-stage automation agent in Python, I needed two properties:

Durability: if the process restarts halfway through a run, the run picks up where it left off.
A human gate: before any step with an external side effect, the agent stops and waits for a person to approve.

LangGraph provides both, through checkpointers and interrupts. Here is the minimal version of the pattern.

The graph

Three nodes: draft something, wait for approval, then act on it.

from typing import TypedDict
from langgraph.graph import StateGraph, START, END
from langgraph.types import interrupt, Command


class State(TypedDict):
    task: str
    draft: str
    approved: bool


def draft_node(state: State) -> dict:
    # call your LLM here; validate its output with Pydantic before trusting it
    return {"draft": f"Proposed action for: {state['task']}"}


def approval_node(state: State) -> dict:
    # pauses the run and hands the draft back to the caller
    decision = interrupt({"draft": state["draft"], "question": "Approve?"})
    return {"approved": decision == "approve"}


def act_node(state: State) -> dict:
    if state["approved"]:
        ...  # the only place with external side effects
    return {}


builder = StateGraph(State)
builder.add_node("draft", draft_node)
builder.add_node("approval", approval_node)
builder.add_node("act", act_node)
builder.add_edge(START, "draft")
builder.add_edge("draft", "approval")
builder.add_edge("approval", "act")
builder.add_edge("act", END)

The rule that matters: side effects live in exactly one node, and that node is after the gate. Everything before the gate can safely run again.

Durable state with Postgres

Compile the graph with a Postgres checkpointer, and every step's state is saved under a thread_id:

from langgraph.checkpoint.postgres import PostgresSaver

DB_URI = "postgresql://user:pass@localhost:5432/agents"

with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()  # creates the checkpoint tables once
    graph = builder.compile(checkpointer=checkpointer)

    config = {"configurable": {"thread_id": "job-1234"}}
    result = graph.invoke({"task": "apply to job 1234"}, config)
    # the run stops at interrupt(); the result carries the interrupt payload

Now the process can die, and so can the whole machine. Calling the graph again with the same thread_id loads the latest checkpoint from Postgres.

Resuming after a human decides

The approval can come from anywhere: a web UI, a chat message, a CLI prompt. Resume the same thread with the decision:

graph.invoke(Command(resume="approve"), config)

The run continues from the interrupt() call. approval_node receives "approve" as the return value, and act_node runs.

What I learned running this for real

Use one thread_id per business object (a job, a ticket, an order), not per process. Resuming is then just a lookup.
Validate LLM output before it reaches state. A Pydantic model on each draft stops malformed output from spreading through the graph.
Add a verifier step for generated content. I score drafts against the source facts and reject anything unsupported before it ever reaches the human gate, so reviewers spend their time on judgement, not on catching invented details.
Track tokens per thread. Logging token usage against the thread_id makes the cost of each business object visible.
Keep nodes idempotent where you can. Checkpointing protects state, but a node that crashes partway can still re-run its side effects. Put the risky work after the gate and make it safe to repeat.

Why it matters

Durability and human gates turn an agent from a demo into something you can run in production. Postgres is usually already in the stack, so you get durable state with no new infrastructure, and the interrupt pattern means you decide where a human must sign off.

I'm Trevor Ogina, a senior backend and cloud engineer in Nairobi building Go, Spring Boot and Python systems, and the LLM agents on top of them. GitHub · LinkedIn

How EXPLAIN ANALYZE helped us cut PostgreSQL query time by 80% under peak load

Trevor Ogina — Mon, 09 Nov 2026 12:19:17 +0000

On an SME advisory platform I worked on, used by more than 1,000 business owners, the database CPU spiked every time traffic peaked. Real-time advisory sessions lagged, and the first instinct on the team was "we need a bigger database."

We didn't need one. Rebuilding the indexes around how the application actually queried data cut query time by 80% and removed the CPU spikes. This is the process I used, and it works on most slow-Postgres problems.

1. Find the queries that matter

Don't guess. Under load, find out which queries take up the database's time. The pg_stat_statements extension is the easiest way:

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

SELECT query,
       calls,
       round(total_exec_time::numeric, 1) AS total_ms,
       round(mean_exec_time::numeric, 2)  AS mean_ms
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

Sort by total time, not mean time. A 5 ms query called 200,000 times hurts more than one 2-second report.

2. Read the plan, not just the timing

Take the worst offender and run it with EXPLAIN (ANALYZE, BUFFERS) against realistic data:

EXPLAIN (ANALYZE, BUFFERS)
SELECT s.*
FROM sessions s
WHERE s.advisor_id = 42
  AND s.status = 'scheduled'
ORDER BY s.starts_at
LIMIT 20;

What to look for:

Seq Scan on a large table inside a hot path: Postgres is reading every row because no index fits the query.
Estimated rows far from actual rows: stale statistics, so the planner is choosing blind. Run ANALYZE.
Sort steps on large inputs: an index in the right order often removes them entirely.
High shared read buffers: you are going to disk on every request.

In our case, the hot paths were doing sequential scans. The indexes that existed had been designed around an earlier version of the product, and no longer matched how it filtered and sorted.

3. Design indexes from access patterns

Ask what each hot query filters on, then what it sorts by. For the query above, a composite index in that order does the job:

CREATE INDEX CONCURRENTLY idx_sessions_advisor_status_start
    ON sessions (advisor_id, status, starts_at);

Two rules worth remembering:

Equality columns first, range or sort columns last. (advisor_id, status, starts_at) serves WHERE advisor_id = ? AND status = ? ORDER BY starts_at without a separate sort.
Use CONCURRENTLY in production. It builds the index without blocking writes. It is slower, and it cannot run inside a transaction.

If most queries only touch a subset of rows, such as active records, a partial index is smaller and faster:

CREATE INDEX CONCURRENTLY idx_sessions_scheduled
    ON sessions (advisor_id, starts_at)
    WHERE status = 'scheduled';

4. Verify with the plan again

Re-run EXPLAIN (ANALYZE, BUFFERS). You want to see an Index Scan or Index Only Scan, far fewer buffers read, and the sort step gone. Then compare pg_stat_statements before and after under similar load.

Don't forget the other side of the trade: every index makes writes slower and takes disk space. Look for indexes nobody uses and drop them:

SELECT relname, indexrelname, idx_scan
FROM pg_stat_user_indexes
WHERE idx_scan = 0
ORDER BY relname;

5. Stop it coming back

Our last step mattered most over time: we added load testing to CI. Performance regressions now fail a build instead of surfacing in production. A query that is fine on a developer laptop can still fall over at peak, and this catches it.

Summary

Measure with pg_stat_statements and sort by total time.
Read plans with EXPLAIN (ANALYZE, BUFFERS).
Build composite or partial indexes from real filter and sort patterns, CONCURRENTLY.
Verify with the plan, and drop indexes nobody uses.
Put load testing in CI.

It's rarely the most exciting fix, but it often beats a bigger instance, and it costs nothing per month.

I'm Trevor Ogina, a senior backend and cloud engineer in Nairobi. I lead teams building Go and Spring Boot platforms on Azure, AWS and GCP. GitHub · LinkedIn

We were asked to migrate a production AWS estate. We transferred the account instead, with zero downtime

Trevor Ogina — Mon, 09 Nov 2026 12:18:25 +0000

A multi-country education non-profit asked us to move its data portal off a third-party provider's AWS account and onto infrastructure it controlled. The portal had 2,500+ users in more than 10 countries, and it was in the middle of a programme cycle. "Take it down for a weekend" was not an option.

The brief said migration. We ended up recommending something else, and the reason is the most useful lesson I took from the engagement: do read-only discovery before you choose the migration strategy, not after.

Step 1: read-only discovery

Before proposing anything, we got read-only access to the live account and mapped what was actually running:

compute, databases and storage, and how they were wired together;
IAM: who and what had access, and how;
networking and DNS: where traffic entered and who controlled the records;
backups, monitoring and alerting: what existed, and what we would lose if we moved things.

Read-only matters. Nobody can accidentally break production while you are still learning how it works, and the provider is far more comfortable granting it.

Step 2: the finding that changed the plan

The obvious plan was a classic lift-and-shift. Stand up a new account, replicate the databases, copy the storage, rebuild the services, then cut DNS over during a maintenance window.

Discovery showed that DNS control sat inside the source account itself. That changed everything. A data migration now meant:

a cutover window that every user would feel;
recreating every component, and its configuration drift, in a new account, with regression risk at each step;
coordinating a DNS change with the very provider we were moving away from.

We had another option. AWS lets you move an account from one organization to another, so the account itself, with everything already running in it, could change hands. Nothing moves and nothing gets rebuilt. What changes is who owns and controls it.

Step 3: weighing the trade-off

	Data migration	Account ownership transfer
Downtime	Cutover window	None
Regression risk	Every rebuilt component	Minimal (nothing rebuilt)
Clean greenfield setup	Yes	No: you inherit the existing setup
Effort	High	Low to medium

The cost of the transfer is real: you inherit whatever is already in the account, good and bad. We judged that a fair trade, because the inherited problems could be fixed after the client owned the account, on the client's own schedule, without any user-facing risk.

Step 4: plan it like a migration anyway

Choosing the low-risk path did not mean skipping the paperwork. We still wrote:

An architecture baseline: what exists today, documented, so the client knows what it is taking ownership of.
A migration strategy: why the transfer beat the alternatives, in plain language for non-technical stakeholders.
A week-by-week runbook, with an hour-by-hour plan for transfer day: who does what, in what order, with checkpoints.
A risk register: each risk, its likelihood and impact, the mitigation, and an owner.
A provider handover questionnaire: everything the outgoing provider knew that was not written down.
A target-account specification: how billing, IAM and access should look once the client owned it.

Step 5: sort security findings into "fix now" and "fix after"

Discovery always turns things up. We found security exposures that needed attention. Fixing all of them in the middle of an ownership change would have stacked risk on risk, so we sorted them:

fix now: anything dangerous enough that it could not wait for the transfer;
fix after: everything else, scheduled once the client was in control.

Because the client's users were in several countries, we also flagged the data-residency side, including the Kenyan and Nigerian data-protection laws.

The result

The transfer completed with zero downtime. Users noticed nothing, no data moved, and the client ended up with full control of billing, IAM and DNS. The remediation work then went ahead on a calm schedule.

Takeaways

Discovery picks the strategy. We only found the right plan because we looked before committing.
Ask "what if nothing has to move?" Moving ownership is often cheaper and safer than moving data.
Low risk still needs a runbook. The documents are what make a calm transfer day possible.
Split remediation by urgency so you don't add security work to a risky change.

I'm Trevor Ogina, a senior backend and cloud engineer in Nairobi. I lead teams building Go and Spring Boot platforms on Azure, AWS and GCP. You can find me on GitHub and LinkedIn.