Vercel's Workflow SDK and Polign's typed memory database both cut out stateful servers

Two engineering essays published within days of each other — a Vercel blog post on durable workflow orchestration and a Polign design note that reached Hacker News's front page — arrive at the same conclusion from opposite directions: durability belongs in libraries and plain storage, not in another stateful system you have to operate.

Workflows as ordinary async code

According to the Vercel blog, the author spent roughly six months on weekends forking Temporal to give it a serverless developer experience, then dropped the fork, joined Vercel, and built a new framework, Workflow SDK, with Nathan Rajlich. The core argument is that a workflow is a directed acyclic graph, and source code already is one: an abstract syntax tree encodes sequencing, branching and parallelism, so frameworks that make you hand-draw the graph, Apache Airflow being the canonical example, bury your logic inside the nodes.

The post is candid about what running Temporal actually entails: standing up frontend, history, matching and worker services on a Cassandra, Postgres or MySQL backend; operating your own polling worker fleet, in practice a Kubernetes cluster; configuring mutual TLS and payload encryption; and evolving code while runs are in flight via the patching API (patched() and GetVersion), a process the author found workable but corrosive as version flags accumulate. Signals, queries and updates — three separate primitives for interacting with a live run — were, by the author's own account, impossible to explain without a whiteboard.

Workflow SDK's answer is one file of ordinary TypeScript. A "use workflow" directive marks the orchestrator, "use step" marks a unit of side-effecting work with full Node.js access, and everything between is await, try/catch, Promise.all and loops. Uncaught errors in steps retry by default; FatalError stops a run, RetryableError customizes backoff, and a maxRetries setting tunes the count. The three Temporal primitives collapse into a single one, the hook: createHook() suspends the run until data arrives, and createWebhook() exposes that as a real callable URL — enough to pause an approval workflow for seconds or weeks with nothing extra to deploy.

Architecturally, the framework credits DBOS, an open-source durable-execution library whose only server-side dependency is Postgres, as the model. Workflow SDK is a library rather than a platform: the runtime talks to a single interface, the World, covering storage, queuing, auth and streaming, so Postgres, Redis, Kafka, SQS, Cloudflare Queues, Turso or Durable Objects can back different layers without touching workflow code. Even Vercel's own Workflow Server, the post says, is a stateless CRUD API that performs no orchestration and deploys like any other Vercel app.

A typed memory store that lives in object storage

The second piece, written by Anup Talwalkar of Polign and shared as a Show HN post, tackles agent memory from two angles: how it is represented and where it lives. Talwalkar, formerly of Google Cloud Storage, notes familiar failure modes — correct a fact and the agent quotes the stale version a week later; change a preference and retrieval returns both copies. Today the model resolves those conflicts by rereading old text, costing tokens and accuracy. His fix is to move the decision into the schema: a typed store where the model extracts a fact and the database determines, via supersession rules, what that fact means.

In the open-source CLI demo, which defaults to Claude models and also accepts OpenAI ones, asking whether a daily step goal exceeds 8,000 becomes a filtered recall that returns the stored value of 9,000. The comparison runs in the database; the model never parses a paragraph to compare numbers. Semantic recall over a local embedding model sits alongside the structured filters.

The location argument comes from watching the operational cost of hot, replicated vector indexes at cloud scale. polign_db is a typed database over a hybrid vector plus BM25 engine whose durable state lives entirely in an object store; the server holds nothing, so processes can die and restart with memory intact, and the author claims query costs do not grow with corpus size. A Wikipedia demo serves 12.5 million passages from S3 with the server idling at about 37 MiB RSS, fitting on a 2 GB ARM machine. One caveat for adopters: the demo is open source, but polign_db itself is closed source, free to download yet not inspectable.

Why it matters

Both pieces attack the same hidden tax: stateful middleware. Vercel's bet is that durable execution can be a compiler plus a library, with the substrate reduced to storage and queues teams already run — a meaningful simplification for anyone who found Temporal's operational envelope too heavy, though the framework is new and unproven at scale. Polign's bet is that agent memory can be deterministic, typed and cold-first, which matters as agents move toward edge hardware and as models demonstrably mishandle their own recall. Neither is validated yet, and half of the Polign stack is proprietary, but together they sketch a direction: fewer orchestrators to operate, and more intelligence pushed into boring, swappable storage.