InfoQ writes up an agent that writes SQL and lets DuckDB count

A reader who asks a chatbot about a spreadsheet quickly learns the model gets the arithmetic wrong. Peihao Yuan writes on InfoQ about a workflow that avoids this. The agent writes the SQL. A real query engine does the counting.

InfoQ published the article by Peihao Yuan on 22 October 2026. The piece is a case study from a real disaster-recovery islanding exercise, not a general argument. The data set carried about 1.1 million metric rows, 1,523 services and 3.8 megabytes of compressed Parquet. All counts in this item are from the article as InfoQ reports them.

The split the piece names

The workflow has two sides. On one side, an AI agent reads the question and decides which direction to investigate. It writes a constrained SQL query. On the other side, DuckDB runs that query over Parquet files in S3-compatible storage. The agent never does the arithmetic.

The piece names the division: exact computation goes to the query engine, contextual reasoning goes to the agent. Traffic absorption metrics, SLO violations and latency changes are calculated by DuckDB. The agent then classifies the outcome, using those facts as the evidence.

Why a replay bundle matters

The piece names a durable record. Every run keeps a bundle of five things: the input, the generated SQL, the execution metadata, the output and the agent's reasoning. The bundle is kept so a later team can replay the run offline. It is also the record that lets a reviewer check whether the agent read the same number as the engine.

This step is the hard one for a reader to adopt. The query engine is standard. DuckDB and Parquet are well known. The agent part is standard too. The new work is naming the five fields and storing them under one key for every run. Without the bundle, the facts and the reasoning drift apart and the next person cannot tell what happened.

When the pattern stops being enough

The piece lists four signals that the small shape must grow. Independent consumers reading the same data on their own. A data set that crosses one terabyte. Joins with shared data sets that the current engine does not hold. Concurrent writes.

Any one of those turns the DuckDB plus Parquet layout into a real distributed system question. The author's point is that this is a different problem, not a bigger version of the same one. Teams reaching those signals should move the engine, not patch it.

The reader action

The piece gives a shape to copy. Pin the arithmetic to a fixed engine. Give the agent one job: write constrained SQL and read the result. Store every run as a replay bundle. The pattern is the same across engines. It works with DuckDB on Parquet, Postgres on a warm cache, or BigQuery on a scheduled slot.

The piece does not quote a dollar saving or a correctness number. It is one engagement, written as a case study. One engagement is what it is. The clearest reader is a team with a disaster-recovery or site-reliability workflow of the same shape.

Source

Peihao Yuan, AI Changes the Data Interface, Not the Query Engine, on InfoQ.