DEV Community: Morgan Li

Shadow Replay or Read-Only Canary: Two Ways to Ship Agent-Written SQL

Morgan Li — Tue, 27 Oct 2026 13:04:22 +0000

A rewrite that passed every gate and still moved the number

Imagine a team approving an agent-drafted rewrite of a fourteen-table revenue query. The parser gate passed, the read-only guard passed, and the dashboard still drifted by three percent overnight. The defect was one LEFT JOIN that the draft had promoted into an inner join, which is invisible to syntax checks and obvious to anyone comparing rows.

That gap defines the real shipping problem. Getting an agent to produce syntactically valid SQL is a solved loop; proving the draft returns the same answers as the query it replaces is the part that still causes incidents. Two credible engineering positions exist for closing it, and they disagree about where equivalence should be measured.

Position A: shadow replay proves equivalence before any user sees it

The first camp argues that correctness is a property of results, so you should capture real queries, replay them against a disposable copy of the data, and diff the outputs offline. Nothing reaches production until the diff is clean, which makes the risk surface small and the review artifact auditable.

Capture a workload sample with normalized parameters instead of literal values.
Restore a snapshot or seed a disposable schema with representative data.
Execute the baseline query and the agent draft under identical session settings.
Normalize both result sets, then diff them with explicit tolerance rules.
Block the draft when the diff exceeds the threshold, and store the report as evidence.

The strength of this position is repeatability. A failing case becomes a regression test you can rerun on every prompt change, and reviewers can read the diff without touching production. The weakness is fidelity: a snapshot goes stale, and replay never exercises concurrency, lock contention, or the query plans your real data volume produces.

Position B: a read-only canary measures equivalence on live data

The second camp argues that snapshots lie, because correctness depends on data the snapshot does not have. Instead, route a sampled fraction of real read traffic to the agent draft on a replica, compare the paired results in flight, and alert on divergence.

Grant the drafting path a role with read-only transactions and a hard statement timeout.
Sample by query fingerprint, not by user, so the same query stays in or out consistently.
Run baseline and draft for the sampled requests and compare normalized rows.
Emit a divergence metric per fingerprint and trip a circuit breaker on threshold breach.
Promote the draft to full traffic only after a clean window you define in advance.

The strength here is realism, since skew, nulls, and timezone handling all show up exactly as production presents them. The weakness is noise: partial failures, transient replica lag, and nondeterministic ordering generate diffs that are not semantic bugs, and someone has to triage them.

The artifact: a replay harness you can build in an afternoon

The following sketch is a harness, not a finished tool. It assumes read-only queries, a disposable database, and a normalization policy you have already agreed on with the people who own the numbers.

# replay.py - sketch; normalize() must match your domain rules
import hashlib, json

NORMALIZE_DECIMALS = 6


def fingerprint(sql: str) -> str:
    return hashlib.sha256(" ".join(sql.split()).encode()).hexdigest()[:16]


def normalize(rows):
    out = []
    for row in rows:
        keys = [row[k] for k in row.keys()]
        norm = []
        for v in keys:
            if v is None:
                norm.append("\x00NULL")
            elif isinstance(v, float):
                norm.append(round(v, NORMALIZE_DECIMALS))
            else:
                norm.append(str(v))
        out.append(tuple(norm))
    return sorted(out)


def run(conn, sql, params, timeout_ms=5000):
    with conn.cursor() as cur:
        cur.execute("SET TRANSACTION READ ONLY")
        cur.execute(f"SET LOCAL statement_timeout = {timeout_ms}")
        cur.execute(sql, params)
        return normalize(cur.fetchall())


def replay(cases, baseline_conn, draft_conn, max_diff_rows=0):
    report = {"pass": [], "fail": [], "error": []}
    for case in cases:
        fid = fingerprint(case["baseline_sql"])
        try:
            base = run(baseline_conn, case["baseline_sql"], case["params"])
            draft = run(draft_conn, case["draft_sql"], case["params"])
        except Exception as exc:
            report["error"].append({"id": fid, "error": str(exc)[:200]})
            continue
        delta = len(set(base).symmetric_difference(set(draft)))
        bucket = "pass" if delta <= max_diff_rows else "fail"
        report[bucket].append({"id": fid, "row_delta": delta})
    return report


if __name__ == "__main__":
    cases = [json.loads(line) for line in open("cases.jsonl")]
    print(json.dumps(replay(cases, None, None), indent=2))

The harness is deliberately blunt, because a clever comparator hides the disagreements you most need to see. Pass real connections in place of None, keep cases.jsonl under version control, and treat every fail entry as a future test rather than a one-off investigation.

Normalization rules are the actual engineering decision

Most debate about replay versus canary is really a debate about what counts as equal. Row order without an ORDER BY is not a contract, so sort before comparing. Floating point sums need a decimal tolerance, and timestamps need an explicit timezone policy rather than a lucky server default.

Write those three rules down before you write the harness. Teams that skip this step spend weeks arguing about diffs that are artifacts of comparison, and the agent gets blamed for noise the harness created.

Where a free server and free model access change the math

Replay is cheap to describe and expensive to run, because it multiplies queries by two and adds a drafting call for every captured case. Running the drafting loop and the harness on the same free server keeps the captured cases, the draft outputs, and the diff report in one place, which is the difference between a ritual and a routine. MonkeyCode's free model access and free server option are the parts that make that loop affordable for a small team; check the project's current terms for limits, since free-tier quotas change and restating a number here would age badly.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The decision rule

Signal	Shadow replay first	Read-only canary first
Workload volume	High, repetitive fingerprints	Low volume, long tail of one-offs
Data volatility	Snapshot can be refreshed nightly	Business day changes the answer
Schema churn	Stable tables, few migrations	Frequent migrations and renames
On-call maturity	No one to triage live diffs	Team already triages alerts
Blast radius	Every draft costs a review	Only sampled requests are exposed

Use replay when you need an auditable artifact and cannot staff live triage. Use a canary when correctness is data-dependent and your alerting is mature enough to absorb noise. Most teams I would advise run replay as the gate and a small canary as the confirmation, in that order.

Limitations and who should skip this

Neither approach covers writes, so do not extend this pattern to UPDATE or DELETE without a separate rollback design. Replay cannot reproduce lock waits, and a canary cannot prove coverage of paths that receive no traffic during the window.

Skip both if you have no disposable environment or no agreed definition of equivalence. A harness built on an undefined contract produces confident reports that mean nothing, which is worse than shipping behind a manual review.

Start with the diff, not the demo

Pick twenty captured queries, normalize them honestly, and see what your current drafts actually return. If the diffs are clean, you have a regression suite; if they are not, you have found the incident before your users did.

Temperature 0 or Five Samples? A Debate Over Reproducible Agent SQL Drafts

Morgan Li — Tue, 20 Oct 2026 09:43:07 +0000

Temperature 0 or Five Samples? A Debate Over Reproducible Agent SQL Drafts

Consider a composite Tuesday that plays out in many teams: an agent re-drafts a query it produced the day before, a reviewer approves it a second time, and the execution plan quietly flips from an index seek to a full scan. Nobody edited the prompt, the schema diff came back empty, and the provider had announced no model change. Two engineers then lose an afternoon arguing about whether the drafting loop should be pinned to one deterministic output or deliberately sampled several times and filtered.

That argument deserves a decision rule instead of a taste preference, because the answer determines how you spend a free token allowance, what your CI can honestly assert, and what you are able to say at review time. Below are the two strongest positions I can defend, a reproducible harness for telling them apart on your own schema, and a rule for choosing between them. No provider benchmarks are claimed here; every number you act on should come from your own replay run.

1. Two credible positions, stated fairly

Position A — pin it. Send one call at temperature 0, store the exact SQL text plus a normalized fingerprint, and treat any later drift as a reviewable diff rather than as noise. The argument is economic and procedural: one call per draft keeps a free allowance stretched across far more scenarios, and a single artifact is easy to attach to a pull request, annotate, and re-check after a dialect migration.

The weakness is that temperature 0 is not a determinism guarantee. Provider-side batching, floating-point non-associativity in sampling, and silent model revisions all produce different outputs for identical inputs, so Position A still needs a fingerprint and a stored plan, not just a stored string.

Position B — sample it. Request k candidates, run static checks on each, and keep the survivor whose plan is cheapest under a stated cost model. The argument is coverage: dialect edge cases such as quoting rules, date arithmetic, and window frames show up as variance across samples, and a single greedy decode tends to hide them behind confident-looking syntax that parses but misbehaves.

The weakness is selection bias plus cost. Static checks cannot detect semantic wrongness, so filtering mostly re-ranks plausible candidates, and five samples against a free tier consume roughly five times the budget for one accepted draft.

What both sides already agree on. You need a normalized fingerprint, a captured plan, and an approval record. That agreement is the part worth implementing first, which is exactly what the harness below does.

2. A replayable draft harness in three steps

The goal is a script that takes a prompt, obtains candidates, records what the database actually does with them, and fails CI when behavior changes without approval. The examples below are illustrative and labeled as such: the code is runnable, but the pass criteria must be tuned to your schema.

Step 1 — Guard the budget before the next call

# draft_harness.py (illustrative)
from dataclasses import dataclass

@dataclass
class Budget:
    limit: int
    used: int = 0

    def charge(self, prompt: str, completion: str) -> None:
        # Rough guard only: approximate token count, not provider billing.
        estimate = (len(prompt) + len(completion)) // 4
        if self.used + estimate > self.limit:
            raise RuntimeError("draft budget exhausted; stop before the next call")
        self.used += estimate

Charge after every candidate, not after every prompt, otherwise a k=5 loop overshoots a free allowance by a factor of five on the first bad day. The guard is intentionally crude, and you should log the real reported usage alongside it.

Step 2 — Parse, restrict tables, and fingerprint

import hashlib, sqlglot

WRITE_NODES = (sqlglot.exp.Insert, sqlglot.exp.Update, sqlglot.exp.Delete)

def inspect(sql: str, dialect: str, allowed_tables: set[str]) -> dict:
    tree = sqlglot.parse_one(sql, read=dialect)
    tables = {t.name.lower() for t in tree.find_all(sqlglot.exp.Table)}
    return {
        "parses": True,
        "unknown_tables": sorted(tables - allowed_tables),
        "has_write": any(tree.find(node) for node in WRITE_NODES),
        "fingerprint": hashlib.sha256(tree.sql(dialect=dialect).encode()).hexdigest()[:12],
    }

Fingerprinting the normalized tree rather than the raw text absorbs whitespace and comment churn, so a changed fingerprint means a changed query shape. Reject any candidate with unknown tables before you ever execute it, and keep the dialect argument explicit so a Postgres draft is never silently validated as generic SQL.

Step 3 — Capture the plan and assert on change

import sqlite3

def plan(sql: str, db_path: str) -> list[str]:
    with sqlite3.connect(db_path) as conn:
        return [row[3] for row in conn.execute("EXPLAIN QUERY PLAN " + sql)]

Store (prompt_hash, fingerprint, plan, approved_by) in a small table checked into the repo. CI then replays every stored prompt, compares fingerprints first and plans second, and fails on any unapproved difference. Plans are engine-specific, so treat a SQLite plan as a smoke signal and re-capture on the target engine before you trust it.

The selection rule for Position B

def pick(candidates: list[dict]) -> dict:
    clean = [c for c in candidates if not c["unknown_tables"] and not c["has_write"]]
    if not clean:
        raise ValueError("no candidate passed static checks")
    return min(clean, key=lambda c: (len(c["plan"]), c["fingerprint"]))

Using plan length as a placeholder cost model is defensible only for small fixtures; swap in your engine's cost estimate or a row-count probe before this touches anything that matters.

3. What free compute changes, and what it does not

Free capacity moves the cost side of this debate and leaves correctness untouched. A k=5 loop that was previously unaffordable becomes affordable, while the need for fingerprints, plan capture, and human approval stays exactly where it was. The operator-supplied terms for this account describe MonkeyCode's free model access and a free server option, including a free tier of 10 million tokens; treat those as availability claims from the project's outreach rather than as measured throughput, and confirm current terms before you size a CI budget around them.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

A practical arrangement is to run the drafting and replay loop on the free server option so the harness has a stable place to live, and to spend the free model access on replayed prompts rather than on exploratory chat. Keep the harness provider-agnostic regardless: if the endpoint changes, your stored fingerprints and plans are still the source of truth.

4. Decision rule

Situation	Choose	Why
Regulated schema, monthly migrations, reviewer signs off	Position A: temperature 0 plus stored fingerprint	One artifact per prompt; drift becomes a visible diff
Schema changes weekly, multiple SQL dialects in play	Position B: k=5 with static filters	Variance surfaces quoting and date-arithmetic edge cases
Free allowance is the hard constraint	Position A, or k=3 with early exit	Candidate count is the dominant cost multiplier
Latency-sensitive interactive tooling	Position A	Five calls per keystroke-adjacent action is untenable
No staging replica and no approval process	Neither, yet	Without a replay target the harness asserts nothing

5. Limitations and who should skip this

This harness validates syntax, table access, and one engine's plan shape; it cannot tell you that a JOIN fans out rows or that a filter uses the wrong timezone. Teams without a staging replica, a fixture snapshot, or a reviewer who can approve a fingerprint should not build CI around fingerprints at all, because they will be freezing noise.

The approach also ages poorly against dialect churn: parsers lag real engines, so a query that fails to parse may still be correct, and your harness should record parse failures as warnings rather than hard blocks during upgrades. Finally, the budget guard is an estimate, and any team spending real money on drafts should log provider-reported usage next to it.

If you already run a replay suite, the cheapest next step is to take your five most-edited prompts, record fingerprints and plans today, and let CI tell you how often they actually drift before you commit to either position.

Schema-Only or Row Samples: A Debate Over What an Agent Sees Before Writing SQL

Morgan Li — Mon, 19 Oct 2026 08:25:29 +0000

Schema-Only or Row Samples: A Debate Over What an Agent Sees Before Writing SQL

A review queue where two reviewers disagree

The scenario repeats in most teams that let an agent draft SQL: a query passes review, runs in staging, and returns something plausible that is still wrong. One reviewer blames the prompt for hiding the data, while another blames the habit of pasting production rows into a model context. Both are describing the same defect from opposite ends of the pipeline, and neither has a measurement that settles the argument.

An illustrative example: the request is "active customers in the EU last quarter." Schema-only context produces WHERE status = 'active', but the column actually stores single characters such as A, I, and P, so the filter matches zero rows. Add five sample rows to the context and the model copies the encoding, but now a customer email and a partial address have also entered the prompt. The disagreement is real, and it is not resolved by intuition.

Position A: the schema is the contract

The first position holds that DDL, comments, and constraint definitions are the only context an agent should receive, because they are stable, versionable, and reviewable. A schema can be diffed in a pull request, pinned to a commit, and replayed later, which makes agent output reproducible in a way that a row dump never is. Proponents also argue that if the model needs literal values to answer correctly, the missing knowledge belongs in a governed lookup table rather than in a prompt.

The privacy argument is equally concrete. Sample rows are the easiest way to move regulated data into a third-party inference call, and most review processes have no record of which rows were sent. Under this view, schema-only grounding is not a limitation but a control, and any accuracy loss is a signal that documentation or reference data needs work.

Position B: distributions are part of the contract

The second position holds that many conventions live in values rather than in DDL, and no amount of column comments recovers them. Encoded status flags, soft-delete sentinels, negative quantities for refunds, amounts stored in minor units, timestamps in UTC with a local offset column, and trailing spaces from legacy imports are all invisible to a model reading PRAGMA table_info. Reviewers who have debugged these failures tend to stop trusting schema-only prompts quickly.

This camp usually accepts redaction rather than rejection. If samples are generated through a masking function that preserves shape and cardinality while replacing sensitive literals, the accuracy benefit survives and the exposure narrows. The counterargument, of course, is that a masking function is code, and code needs its own tests before anyone trusts it as a boundary.

Where the disagreement actually sits

Both positions agree that the model needs the information; they disagree about where that information should live and who owns it. Schema-only advocates want conventions promoted into documented reference data, while sample advocates want conventions observed empirically and masked. A team can hold both views at once by treating samples as a diagnostic tool and reference tables as the production fix.

A reproducible harness

The only way out of the argument is a small, boring measurement, so the workflow below scores both contexts against the same frozen evaluation set. Everything runs locally in SQLite, and the harness template is unexecuted here, so treat the numbers you get as yours rather than mine.

Step 1: freeze a 30-item evaluation set

Each item stores the question, a gold query, and the expected result, never the model output. Thirty items is deliberately small: it is enough to expose value-convention failures and cheap enough to re-run after every prompt change.

[
  {
    "id": "eu-active-01",
    "question": "Active customers in the EU last quarter",
    "gold_sql": "SELECT COUNT(*) FROM customers WHERE status='A' AND region='EU' AND last_order_at >= '2026-07-01'",
    "expected_hash": "<filled_by_harness>"
  }
]

Step 2: build two context builders

One builder emits DDL only; the other emits DDL plus a small, masked sample per table. Sample with an explicit seed so the context is reproducible across runs and reviewers.

# harness.py - template, not executed in this article
import sqlite3, hashlib, json

MASK = {"email": lambda v: v.split("@")[-1], "name": lambda v: "x" * len(v)}

def schema_context(conn, tables):
    return "\n".join(conn.execute(f"SELECT sql FROM sqlite_master WHERE name='{t}'").fetchone()[0]
                     for t in tables)

def sample_context(conn, tables, per_table=5):
    blocks = []
    for t in tables:
        cur = conn.execute(f"SELECT * FROM {t} ORDER BY rowid LIMIT {per_table}")
        cols = [d[0] for d in cur.description]
        rows = [[MASK.get(c, lambda v: v)(v) for c, v in zip(cols, r)] for r in cur.fetchall()]
        blocks.append(f"-- sample: {t}\n{cols}\n{rows}")
    return schema_context(conn, tables) + "\n" + "\n".join(blocks)

Step 3: score on result sets, not strings

String comparison punishes formatting and rewards nothing useful, so hash the sorted result rows instead. That single choice removes most reviewer disagreement about whether a query "looks right."

def result_hash(conn, sql):
    rows = conn.execute(sql).fetchall()
    return hashlib.sha256(json.dumps(sorted(map(str, rows))).encode()).hexdigest()

def score(items, draft_fn):
    passed = []
    for it in items:
        try:
            sql = draft_fn(it["question"])
            passed.append(result_hash(CONN, sql) == it["expected_hash"])
        except Exception:
            passed.append(False)
    return sum(passed) / len(items)

Step 4: run both arms at k=3 and log failures by cause

Run every item three times per context, because a single pass hides flakiness that reviewers will otherwise discover in staging. Label each failure as encoding, null_handling, unit_scale, or syntax, and keep the labels in the same repository as the eval set.

python harness.py --context schema --k 3 --out results/schema.jsonl
python harness.py --context samples --k 3 --out results/samples.jsonl
python report.py results/*.jsonl --group-by cause

Step 5: decide with a rule, not a preference

Read the failure labels first and the aggregate accuracy second, because a context that wins by two points on syntax while losing every encoding case is the wrong default for a reporting workload. Then apply the rule in the next section.

The decision table

Observed signal	Schema-only is the right default	Row samples are the right default
Failures concentrated in `encoding` or `unit_scale`	No	Yes
Failures concentrated in `syntax` or ambiguous joins	Yes	No
No masking pipeline, regulated data	Yes	No
Stable reference tables exist for coded columns	Yes	No
Legacy tables with undocumented sentinels	No	Yes

The decision rule

Start with schema-only and run the harness once; if the failure labels contain no value-convention causes, stop and spend the effort on documentation instead. If at least a third of failures are encoding or unit_scale, add masked samples for the affected tables only, then re-run the same eval set. Escalate per table and per failure cause, never per project, so the prompt stays as narrow as the evidence allows.

Running the comparison without a budget fight

This matrix multiplies calls: thirty items, three repetitions, two contexts, plus re-runs after each prompt edit. MonkeyCode's free model access removes the cost objection for the drafting side, and the free server option covers running the harness and SQLite fixtures next to the data. Confirm the current token allowance and server terms on the project page before you plan around them, since promotions change and this article does not treat them as permanent.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

I have not audited the MonkeyCode repository or its license independently, so check the license terms yourself before adopting it as a dependency, and treat the free tier as an evaluation path rather than a capacity guarantee. The harness itself is plain Python and runs anywhere, which keeps the measurement portable if your tooling changes.

Limitations and who should skip this

Thirty items is a smoke test, not a statistically sound benchmark, and it will miss rare conventions that appear once a quarter. Masking that preserves shape can still leak information through cardinality or timestamp patterns, and no sample context should be used where a proper data-processing agreement is absent. Teams without result-set comparison in their pipeline should build that first, because string-diff review will make the harness output unreadable.

If this eval-set format saves you a review cycle, the most useful thing to send back is the failure taxonomy you ended up with, since that is the part most teams rebuild from scratch.

Transpile or Re-Ask: Fixing Dialect Breaks in Agent-Written SQL

Morgan Li — Sat, 17 Oct 2026 06:10:25 +0000

A quarterly reporting job moved from Postgres to MySQL last spring, and every agent-drafted query in the pipeline kept parsing fine while returning the wrong rows. I have already described one loud failure on this account, an AI-generated query that locked a production table, but this quieter class of break costs more engineering hours. The model never sees the target engine, so it keeps writing date_trunc('month', ...) and ON CONFLICT long after those idioms stop meaning anything. Below is the debate I ran against my own fixture set, plus the decision rule I now apply before touching a prompt.

Where agent SQL actually breaks

Dialect drift looks like a syntax problem and usually is not one. The statements that break loudly are cheap to fix, because the parser refuses them and the loop simply retries with the error text. The expensive ones parse on both engines and disagree about results: ILIKE against a case-insensitive collation, LIMIT before OFFSET, integer division, and jsonb arrow operators with no direct MySQL equivalent. A query that runs cleanly on both engines and returns 41 rows instead of 44 will pass every check that only looks for exceptions.

That asymmetry is why the choice between deterministic transpilation and a model re-ask is not a tooling preference. The two approaches fail in different places, and the decision rule has to be driven by which failure you can detect cheaply.

Position A: transpile deterministically, then execute

The first position says dialect conversion is a parsing problem and should stay one. sqlglot reads the Postgres AST and writes MySQL, and the same input always produces the same output, which makes the whole step reviewable in a diff. It is also fast enough to run on every draft, so repair cost stays near zero for the common cases.

# dialect_probe.py — illustrative; adjust identifiers to your own schema
import sqlglot

SOURCE, TARGET = "postgres", "mysql"

def transpile(sql: str) -> str:
    """Deterministic: same input, same output, diffable in code review."""
    return sqlglot.transpile(sql, read=SOURCE, write=TARGET, pretty=True)[0]

if __name__ == "__main__":
    src = """
        SELECT user_id, date_trunc('month', created_at) AS m, count(*)
        FROM orders WHERE note ILIKE '%refund%' GROUP BY 1, 2
    """
    print(transpile(src))

The weakness is equally clear: transpilers preserve the semantics they can express and guess at the rest. Window frame defaults, string concatenation and null ordering under ORDER BY are all places where a translated statement is valid, executable, and quietly wrong. Position A therefore only holds up when it is paired with execution against the target engine.

Position B: re-ask the model with the target dialect in the prompt

The second position says the model already knows both dialects and only needs to be told which one matters. Free model access makes the extra call cheap enough to sit inside the repair loop, which is exactly where I use it: MonkeyCode's free model access covers the re-ask step, and the free server option gives me a disposable target engine to execute against. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The allowance and limits on that access change over time, so check the current account terms before you budget a loop that runs on every commit.

# reask.py — unexecuted example; swap the client if your endpoint differs
import os

PROMPT = """Rewrite this {src} query for {dst}.
Keep the output column names and their order identical.
Do not change filtering semantics. Return SQL only.

{sql}
"""

def reask(client, sql: str, src="postgres", dst="mysql") -> str:
    r = client.chat.completions.create(
        model=os.environ["LLM_MODEL"],
        temperature=0,
        messages=[{"role": "user", "content": PROMPT.format(src=src, dst=dst, sql=sql)}],
    )
    return r.choices[0].message.content.strip()

The re-ask handles the cases the transpiler guesses at, including collation-sensitive comparisons and ON DUPLICATE KEY UPDATE conversions that need a rewrite rather than a symbol swap. Its weakness is the inverse: it is non-deterministic, it can silently drop a WHERE clause, and a plausible rewrite is indistinguishable from a correct one until you execute it. Position B without execution is a confident guess with extra steps.

The decision rule I use

Neither position survives alone, and the split is not "simple queries versus complex queries". It is "can I detect the failure with a fixture run", and the fixture is the same artifact either way.

Observation after the step	Route	Reason
Transpile raises a parse error	re-ask, then execute	grammar-level gap; the model often knows the idiom
Transpile parses, target engine errors	re-ask, then execute	valid AST, unsupported function or syntax
Executes, column names or order differ	reject the draft	breaks downstream consumers silently
Executes, row count differs	re-ask, then execute	semantic difference; never merge on syntax alone
Executes, counts match, checksum differs	hand-write, add fixture	aggregate or rounding drift the model will not catch
Executes, counts and checksum match	accept and cache the rewrite	stop spending calls on a solved pair

The rule underneath the table is straightforward: transpile first because it is free and deterministic, and escalate to a re-ask only when execution on the target engine disagrees with the source. Cache accepted rewrites keyed by normalised SQL text, or the loop re-derives the same conversion on every run.

Building the harness in five steps

Capture the source result once, on the source engine, with a read-only role. Store column names, row count, and a checksum over an ordered numeric column.
Transpile the statement and record whether the parse succeeded before you run anything at all.
Execute the output against a disposable target engine — I load the free server option with a schema-only dump plus a small fixture, run the probe, then destroy the instance.
Escalate only the disagreements to the re-ask function, and cap the loop at two attempts so a bad prompt cannot burn a budget overnight.
Promote every query that needed a hand fix into the fixture set, so the regression is covered the next time the agent proposes that shape.

Limits and who should skip this

Row-count equality is necessary and not sufficient, and the checksum only protects the columns you chose to cover. Fixtures that omit NULLs, duplicate keys, timezone boundaries and unicode will pass a rewrite that fails on the first real month-end load. Temperatures above zero make the re-ask step non-reproducible, so keep the repair path at zero and treat accepted rewrites as code rather than as prompt state. Skip this workflow if you have no fixture data, no disposable environment, or a policy that forbids sending schema text to a hosted model — in those cases a deterministic transpiler plus human review is the honest option.

Keep the model out of the decision about whether the rewrite is correct, and let execution decide. If you want to try the loop without paying for a second engine or a model bill, start with one fixture query against the free server option and let the table above route it.

Hosted Free Models or a Free Server: Where an Agent's SQL Drafting Loop Should Run

Morgan Li — Fri, 16 Oct 2026 05:07:50 +0000

Last month I watched an agent spend forty-one attempts drafting one reporting query, and not one of those attempts was slow enough to notice on its own. The loop only looked expensive when I plotted attempts against wall time and prompt tokens per retry. What surprised me was that the placement of the drafting step, not the model quality, explained most of the variance. That observation turned into an argument I keep having with a colleague, so this article states both sides properly and then writes down a rule for choosing.

The scene, and why placement matters

The task was ordinary: an agent reads a schema summary, drafts SQL, runs it read-only, reads the error, and revises. Each revision resends the growing conversation, so attempt twelve carries far more prompt tokens than attempt one. When the drafting step runs behind a shared hosted endpoint, retry latency and quota pressure are somebody else's scheduling problem. When it runs on a machine you control, latency is your problem but the retry storm is yours to shape.

I am not going to pretend I have a benchmark that settles this for everyone, because I have not run one against MonkeyCode's endpoints myself. What I can give you is a reproducible harness, the four signals it collects, and a decision rule that a team can argue about using its own numbers.

Position A: borrow the hosted free model layer

The first position is that an agent's drafting loop should default to a hosted free tier, because the cost of getting started is minutes rather than days. You authenticate, point the loop at an endpoint, and the schema summarization, prompt assembly, and retry logic stay exactly where they were. For a solo developer validating whether an agent can even reach a usable query, this is the shortest path to evidence.

A second argument is operational: nobody has to patch, restart, or monitor anything. If the endpoint degrades, the retry logic you already wrote absorbs it, and you can rerun the same task suite tomorrow. The counterargument, which I happen to hold, is that a shared free tier gives you no control over the retry ceiling, so a runaway loop is invisible until it stops working.

MonkeyCode is relevant here because it advertises free model access and a free server option, which is exactly the fork this article is about. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I am describing it as a user of the free tier, not as a benchmark authority, and I have treated the free token grant (the operator states ten million tokens at signup) and the free server as current-at-writing claims. Verify both on the project's own pages before you build a plan around them, because free-tier terms change.

Position B: own the drafting step on a free server

The second position is that the drafting step belongs on a machine you control, even if that machine arrives free. Once the model runs next to the database, the schema summary never leaves your boundary, and you can cap concurrency, retries, and context growth yourself. For regulated schemas or for loops that touch production metadata, that boundary is often the whole argument.

Ownership also makes the failure mode legible. When a retry storm starts, you see memory, queue depth, and per-request latency on a dashboard you built, not in someone else's status page. The cost is real, though: someone must own the image, the model weights, the restart policy, and the capacity ceiling.

The artifact: a placement harness you can actually run

Here is a proposed harness, not a validated benchmark. It writes one JSONL row per drafting attempt so that placement decisions rest on your data rather than on my opinions. The token counter is a cheap proxy and the backend is a dry-run echo, so nothing here depends on invented provider numbers.

# bench_placement.py — proposed harness; I have not executed this against MonkeyCode.
import argparse, hashlib, json, statistics, time
from dataclasses import asdict, dataclass

@dataclass
class Attempt:
    task_id: str
    placement: str      # "hosted-free" | "free-server"
    attempt_no: int
    prompt_tokens: int
    completion_tokens: int
    wall_ms: int
    ok: bool
    error_class: str | None
    sql_sha256: str | None

def estimate_tokens(text: str) -> int:
    # Proxy only. Swap in the tokenizer of whichever model you actually call.
    return max(1, len(text) // 4)

def draft_sql(task: str, history: list[str], dry_run: bool) -> tuple[str, str | None]:
    if dry_run:
        return f"SELECT 1 /* {task} */", None
    raise SystemExit("Wire your real backend here; keep the return contract.")

def run(tasks: list[str], placements: list[str], max_attempts: int, out: str) -> None:
    rows: list[Attempt] = []
    for placement in placements:
        for task in tasks:
            history: list[str] = []
            for n in range(1, max_attempts + 1):
                prompt = "\n".join(history + [task])
                t0 = time.perf_counter()
                try:
                    sql, err = draft_sql(task, history, dry_run=True)
                except Exception as exc:  # classify, never swallow silently
                    sql, err = "", type(exc).__name__
                wall_ms = int((time.perf_counter() - t0) * 1000)
                rows.append(Attempt(
                    task_id=task[:24], placement=placement, attempt_no=n,
                    prompt_tokens=estimate_tokens(prompt), completion_tokens=estimate_tokens(sql),
                    wall_ms=wall_ms, ok=err is None, error_class=err,
                    sql_sha256=hashlib.sha256(sql.encode()).hexdigest()[:12] if sql else None,
                ))
                if err is None:
                    break
                history.append(f"attempt {n} failed: {err}")
    with open(out, "w") as fh:
        for row in rows:
            fh.write(json.dumps(asdict(row)) + "\n")
    for placement in placements:
        lat = sorted(r.wall_ms for r in rows if r.placement == placement)
        if lat:
            p95 = lat[min(len(lat) - 1, int(0.95 * len(lat)))]
            print(f"{placement}: n={len(lat)} p50={statistics.median(lat)}ms p95={p95}ms")

if __name__ == "__main__":
    ap = argparse.ArgumentParser()
    ap.add_argument("--tasks", default="tasks.txt")
    ap.add_argument("--placements", default="hosted-free,free-server")
    ap.add_argument("--max-attempts", type=int, default=12)
    ap.add_argument("--out", default="placement.jsonl")
    args = ap.parse_args()
    with open(args.tasks) as fh:
        tasks = [line.strip() for line in fh if line.strip()]
    run(tasks, args.placements.split(","), args.max_attempts, args.out)

Steps to run the comparison

Write twenty tasks into tasks.txt, mixing trivial lookups with two or three joins, and keep the same file for both placements.
Wire your backend into draft_sql, keeping the return contract so the JSONL schema does not change between runs.
Run python bench_placement.py --placements hosted-free --out hosted.jsonl, then repeat with --placements free-server.
Compare attempts per task and p95 wall time, not average latency, because retry storms hide in the tail.
Gate every generated statement before execution, regardless of placement, using a read-only transaction with a timeout.

-- Cheap guard: never let a draft touch data until it has been planned read-only.
BEGIN;
SET LOCAL transaction_read_only = on;
SET LOCAL statement_timeout = '3s';
EXPLAIN (FORMAT JSON) /* generated statement goes here */;
ROLLBACK;

The signals that actually decide it

Four signals from the JSONL file carry most of the decision weight. Attempts per task tells you how much context resending you are paying for. The ratio of prompt to completion tokens tells you whether your loop is dominated by conversation history rather than by generation. Tail latency tells you how badly a shared tier handles your retry pattern. Sensitivity class of the schema tells you whether the boundary argument overrides every number above.

Signal	Hosted free tier wins when	Free server wins when
Attempts per task	Under roughly four	Above eight, and you can cap concurrency
Schema sensitivity	Public, fixture, or synthetic only	Internal or regulated metadata
Tail latency (p95)	You can tolerate queueing	You need a stable ceiling you control
Ops capacity	Nobody available to own a box	Someone owns restarts and capacity

Failure analysis on both sides

On the hosted side, the failure I see most is silent quota exhaustion mid-loop: the agent keeps retrying, the endpoint keeps refusing, and the loop reports a schema error. Instrument error classes separately or you will misread a rate limit as a bad join. The second is context bloat, where attempt fifteen carries so much history that the useful instruction is a rounding error.

On the server side, the failure is usually resource exhaustion rather than refusal. A warm model plus three concurrent agents can exceed memory, and the process dies without a useful message. Cold starts also distort early latency, so discard the first task in each run or you will compare startup cost with steady state. Neither placement fixes an incorrect query, and that is the failure people most want placement to solve.

The decision rule I would defend

Start every new agent loop on the hosted free tier, with the harness running, because evidence beats architecture debate. Move the drafting step to a free server once attempts per task cross eight, or once the schema becomes sensitive, or once tail latency is the constraint users complain about. Keep the harness in version control either way, since the numbers that justified the move are the numbers that will justify moving back.

a decision like this is only as good as the alternatives you actually tried, so if you want to test both placements on the same task suite, MonkeyCode's free model access and free server option give you two runnable configurations without a procurement conversation.

Limitations and who should skip this

This harness measures placement, not correctness, and the token counter is a proxy rather than a real tokenizer, so treat the numbers as relative. The free token grant and the free server are operator-stated availability claims that I have not independently benchmarked, and self-hosting on a free server still requires someone to own the image. Skip the debate entirely if you need deterministic sub-second p99 latency or if your compliance rules forbid third-party inference, because in both cases the decision was made before the benchmark ran. Also skip it if your agent has never produced a query a reviewer approved, since placement will not rescue a loop that has not yet proven it can work.

Free Draft Volume or Paid First Passes: A Debate for Agent SQL Budgets

Morgan Li — Thu, 15 Oct 2026 11:22:56 +0000

A nightly analytics job in my lab reproduction turns plain-English questions into SQL, and every draft has to survive a rehearsal database before a human sees it. After three weeks of running that loop, the argument inside the team was never about prompt design. It was about where the budget should go: more drafts on a cheap tier, or fewer, better drafts on an expensive one.

The numbers below are not a product benchmark, because I cannot measure your schema or your tasks. Everything here is a harness you run yourself, and the only claims I make are about the method and the decision rule it produces.

Position A: draft breadth is the bottleneck

The first position says generation is cheap relative to review, so a loop should buy as many independent drafts as it can afford. If a task has a 12% chance of a correct first attempt, ten attempts give you roughly a 72% chance that at least one passes, and that arithmetic is the whole argument. Breadth turns a lucky single shot into an engineering process, but it only works when each attempt costs almost nothing.

This is where free model access and a free server option stop being a discount and become a technical argument. A free draft tier plus a free rehearsal host means the marginal cost of attempt eleven is zero, so your accept@k curve is bounded by wall-clock time rather than by an invoice. MonkeyCode, which its maintainers present as an open-source project, advertises that combination: free model access and a free server option, with a token allowance quoted to me as ten million tokens at the time of writing.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Treat any published quota as a snapshot rather than a contract, because quotas, model versions, and availability change without negotiation. Whatever free capacity you have, pin it in your logs by model identifier and response hash, so a silent model swap appears as a step change in your accept rate instead of as a mystery.

Position B: verification is the bottleneck, so cheap drafts create debt

The second position is less flattering. It says the real constraint is how many changes a human can verify per day, and that cheap drafts simply move cost from the invoice to the reviewer. A draft that fails execution is free to discard, but a draft that parses, executes, and returns the wrong answer is expensive, because only a person notices it.

Under this reading, cost per token is a vanity metric and cost per accepted draft is a distraction. The number that matters is the total cost of one merged change, including the minutes a reviewer spends rejecting plausible SQL. Breadth makes this worse in a specific way: it multiplies the number of semantically wrong queries that pass a structural verifier and reach a human queue.

The counter-evidence for Position A is easy to find in your own logs, and it looks like a distribution of failure reasons. If failures cluster at parse and execution, the verifier absorbs them and breadth is nearly free. If failures cluster at "valid SQL, wrong grain, wrong join, wrong filter", then breadth is multiplying review work rather than reducing it.

The artifact: a harness that measures both positions

The harness below is illustrative and was not executed for this article; run it against your own task set and your own endpoints. It needs Python with the sqlglot and requests packages, plus Docker for the rehearsal database.

Step 1 - freeze a task set with an oracle. Write 25 tasks and give each one a machine-checkable expectation, such as an exact row count or a checksum over the sorted result. Without an oracle you cannot separate execution failures from semantic failures, and the whole decision collapses back into opinion.

Step 2 - provision a disposable rehearsal database. Start a throwaway Postgres container, load schema and fixtures, and run every draft inside BEGIN ... ROLLBACK so one fixture serves all attempts.

docker run --rm -d --name rehearsal -p 55432:5432 -e POSTGRES_PASSWORD=postgres postgres:16-alpine
psql postgresql://postgres:postgres@127.0.0.1:55432/postgres -f schema.sql -f fixtures.sql
export REHEARSAL_DSN=postgresql://postgres:postgres@127.0.0.1:55432/postgres

Step 3 - describe your backends in one config file. A free tier and a paid endpoint usually speak the same chat-completions shape, so a single function can drive both. Replace the identifiers and prices with your own; the values below are placeholders, not product facts.

[
  {"name": "free-hosted", "url": "https://<host>/v1", "key_env": "FREE_KEY",
   "model": "<model-id>", "usd_per_mtok": 0.0},
  {"name": "paid-endpoint", "url": "https://<host>/v1", "key_env": "PAID_KEY",
   "model": "<model-id>", "usd_per_mtok": 0.0}
]

Set usd_per_mtok from your own invoice for the paid endpoint, and keep it at zero only after you have confirmed the free tier's terms and quota for your usage.

Step 4 - draft, verify, and log one JSONL row per attempt. The verifier does three checks in order: parse to a single statement, execute under a short statement timeout, then compare against the task oracle.

import json, os, subprocess, time, sqlglot, requests

def draft(backend, schema_card, prompt, attempt):
    t0 = time.time()
    r = requests.post(
        f"{backend['url']}/chat/completions",
        headers={"Authorization": f"Bearer {os.environ[backend['key_env']]}"},
        json={
            "model": backend["model"],
            "temperature": 0.2 + 0.15 * attempt,
            "messages": [
                {"role": "system", "content": schema_card},
                {"role": "user", "content": prompt},
            ],
        },
        timeout=120,
    )
    r.raise_for_status()
    body = r.json()
    return body["choices"][0]["message"]["content"].strip(), body.get("usage", {}), time.time() - t0

def verify(sql, task, dsn):
    tree = sqlglot.parse(sql, read="postgres")
    if len(tree) != 1:
        return False, "shape", None
    wrapped = "BEGIN; SET LOCAL statement_timeout='2s'; " + sql.rstrip(";") + "; ROLLBACK;"
    p = subprocess.run(
        ["psql", dsn, "-v", "ON_ERROR_STOP=1", "-Atc", wrapped],
        capture_output=True, text=True, timeout=30,
    )
    if p.returncode != 0:
        return False, "exec", p.stderr.strip()[:160]
    rows = [line for line in p.stdout.strip().splitlines() if line]
    ok = len(rows) == task["expected_rows"]
    return ok, "ok" if ok else "oracle", len(rows)

Step 5 - reduce attempts into one comparison table. Group by backend and compute accept rate, cost per accepted draft, and p95 latency, so both positions can be argued with numbers instead of adjectives.

def summarize(rows):
    stats = {}
    for row in rows:
        s = stats.setdefault(row["backend"], {"drafts": 0, "accepted": 0, "usd": 0.0, "lat": []})
        s["drafts"] += 1
        s["accepted"] += int(row["accepted"])
        s["usd"] += row["usd"]
        s["lat"].append(row["latency_s"])
    for s in stats.values():
        s["accept_rate"] = round(s["accepted"] / s["drafts"], 3)
        s["usd_per_accepted"] = round(s["usd"] / max(s["accepted"], 1), 4)
        s["p95_latency_s"] = round(sorted(s["lat"])[int(0.95 * len(s["lat"])) - 1], 1)
    return stats

The decision rule

Run both backends over the same 25 tasks and apply one rule, written as a formula you can defend in a review.

tco_per_merged_change =
    (draft_usd + verify_usd + review_minutes * review_usd_per_min) / accepted

review_minutes comes from your pull-request history rather than from a guess, and in most teams it is the largest term in the equation. Then apply the branches below to pick a configuration instead of an ideology.

Harness signal	Cheapest correct choice	Reason
Free tier's accept rate is within ~30% of paid, failures at parse/exec	Free draft tier, 10-20 attempts	The verifier absorbs failures, so breadth stays cheap
Over a third of failures are "valid SQL, wrong answer"	Paid endpoint, 1-3 attempts, plus an oracle	Review minutes dominate; breadth multiplies debt
Every task needs fresh fixtures	Free server for the rehearsal database	Throwaway rehearsal is the cheapest part of the loop
Schema under data-residency or client-contract limits	Self-hosted only	Any hosted free tier is still a third-party processor

The rule is not "free beats paid" or the reverse. Breadth wins when your verifier is strong and your oracle is per-task; precision wins when your verifier is structural and your oracle is a human in a queue.

Limitations and who should not use this

Skip the breadth-first loop if you cannot write a per-task oracle, because you will be multiplying exactly the failures you are unable to detect. Skip any hosted free tier if schema cards or sample rows fall under a data-processing agreement that does not cover that provider, and check the terms before the first request rather than after the first audit.

Do not plan a budget around a published quota, and do not assume a free tier is permanent. Re-run the harness after any provider change, because your accept-rate history is the only early warning you will get.

This workflow is also a poor fit for one-shot schema migrations. There, review is the only gate you have, and ten cheap drafts simply hand a reviewer ten ways to be wrong.

If you want to test the breadth-first branch without paying per draft, the free tier is the cheapest way to get the harness above running - measure it with the same oracle and the same decision rule before you commit to it.

Masked Extracts or Local Draft Models: A Debate for Agent SQL Placement

Morgan Li — Tue, 13 Oct 2026 01:04:27 +0000

A platform team watched a checkout report stall after an agent rewrote a revenue query during a release review. The statement joined three large tables and omitted a selective predicate, so the planner chose a broad scan. An engineer cancelled the statement before it held locks, then recorded the draft path rather than the model brand. The remaining decision was where the next draft should run, and which data could leave the production boundary.

That incident is a composite scenario for this debate, not a measured outage report from a named company. It still matches a pattern that shows up whenever agents draft SQL against live catalogs without a placement rule. Better language models do not, by themselves, decide whether schema text may cross a network boundary. Software controls around placement, redaction, and rehearsal still determine whether a fluent draft is acceptable to run.

Two credible positions

Position A sends a masked catalog extract to a free hosted model, then rehearses the returned SQL on a free disposable server. Position B keeps all draft generation on a local model that remains inside the team trust boundary. That position uses an external server only as an execution witness that is loaded with synthetic rows. They disagree about which artifact may move, and about which system may see real object names.

Position A argues that hosted models often draft more fluent SQL when prompts include current table names and key relationships. A masked extract can remove row samples, comments, and high-sensitivity column names before that hosted call. A free server then provides an isolated planner and a permission set that production roles do not share. The claim is that separation of draft generation from production execution reduces lock risk more than an unrehearsed local draft.

Position B argues that column names, check constraints, and relationship graphs can still reveal product structure even after row samples are removed. A local model can read the live catalog through an internal tool and never transmit that text. The free server, if used at all, should receive only synthetic identifiers and the candidate statement. The claim is that an execution witness does not require the drafting model to sit outside the boundary.

Evidence that can actually be checked

Neither position is universally cheaper, safer, or more accurate, and this article does not report a benchmark. The useful evidence is qualitative and checkable by each team against its own written catalog policy. Hosted draft quality matters only when the team is allowed to export a defined schema subset. Local draft quality matters only when the team can actually run a model beside the catalog.

Rehearsal value depends on whether the disposable server has similar indexes, not on whether the server was free. The table below compares those placement inputs without ranking any vendor, model family, or hosting plan. Availability of a free hosted model and a free server can make Position A practical for unclassified practice catalogs. That availability does not change a contractual ban, and it does not prove that masked names are harmless.

Decision input	Favors masked hosted draft	Favors local draft model	Reject both external hops
Schema classification	Names are internal but not regulated	Names reveal unreleased product scope	Any catalog text is barred from export
Prompt contents	Row samples already stripped	Catalog text never leaves the host	A useful draft would require samples
Planner fidelity	Synthetic server can mirror indexes	Local database already mirrors indexes	No safe mirror exists this week
Bad-join failure cost	Rehearsal can catch it before production	Local explain can catch it before review	Write access cannot be prevented
Operational constraint	Hosted call and server are available now	Local model is maintained by the team	External terms are unacceptable

A placement workflow with numbered checks

The workflow below is a concrete placement procedure for the debate, and it can be run on an unclassified catalog. Each numbered step produces an artifact that a reviewer can inspect without trusting the agent's explanation. Commands are patterns for PostgreSQL-style rehearsal, and they should be adapted to the server version in use.

Classify the catalog extract before any prompt is built, and mark each table as exportable, mask-required, or local-only.
Build the extract from catalog metadata only, keeping names, types, and declared keys while dropping comments and sample values.
Score the extract with an automated gate that fails on missing labels, sensitive classes, or literals copied from logs.
Choose hosted placement only when the gate passes and a reviewer can read the exact payload before the call.
Rehearse on a disposable server with synthetic rows, a read-only role, and an explain plan captured before execution.
Record the model placement, extract hash, server identity, and explain output beside the statement hash for later review.

Artifact: a gate, a role, and four checks

The following Python is a proposal for the gate in step 3, and it is not a production policy engine. It has not been executed against a private catalog for this article, so teams should treat the output as a starting check. A passing result means the payload avoided three obvious failures, not that the schema is safe to export.

import re
from hashlib import sha256

SENSITIVE = {"email", "phone", "ssn", "api_key"}
LITERAL = re.compile(r"[A-Z0-9._%+-]+@[A-Z0-9.-]+\\.[A-Z]{2,}", re.I)

def gate(columns, payload):
    missing = [c["name"] for c in columns if "class" not in c]
    leaked = [c["name"] for c in columns if c.get("class") in SENSITIVE]
    literals = LITERAL.findall(payload)
    ok = not missing and not leaked and not literals
    digest = sha256(payload.encode("utf-8")).hexdigest()
    return {"ok": ok, "missing": missing, "leaked": leaked, "digest": digest}

A passing gate is necessary but not sufficient, because the rehearsal role still needs a database-side boundary. On PostgreSQL, a reviewer can create a read-only role and inspect the plan without granting write rights. The statements below are a pattern for a disposable server, not a claim that every host uses the same defaults. Replace the dates and table names with fixtures that contain no production values before anyone runs them.

CREATE ROLE agent_reader NOLOGIN;
GRANT CONNECT ON DATABASE rehearsal TO agent_reader;
GRANT USAGE ON SCHEMA public TO agent_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO agent_reader;
SET ROLE agent_reader;
EXPLAIN (FORMAT TEXT)
SELECT o.id
FROM orders AS o
JOIN payments AS p ON p.order_id = o.id
WHERE o.created_at >= DATE '2026-10-01';

PostgreSQL documents EXPLAIN and privilege rules in the current official reference, which is the primary source for those commands. A team should read that version's pages before copying the grants, because default privileges can differ by release. If the disposable server cannot host a faithful index set, label the plan as a syntax witness rather than a cost forecast.

Run four checks before anyone trusts the helper, and record the returned dictionary rather than a screenshot of a chat. These checks are expected behaviors for the proposal, not a transcript of an executed private run. Keep the fixture columns small enough that a reviewer can compare the dictionary with the source list by eye.

Pass a payload that lists only exportable columns with classes present, and expect the ok flag to be true.
Fail a payload that includes a column classed as email, and expect that column name to appear under leaked.
Fail a payload that contains an email literal in the text, and expect the gate to reject that payload.
Fail a column entry that omits its class field, and expect that column name to appear under missing.

Where a free practice surface fits

Some teams lack a maintained local model, yet they still need a place to practice agent SQL without touching production. In that setting, MonkeyCode's free model access and free server option can serve as the practice surfaces for that gated path. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Readers should confirm current terms before relying on either surface, because this article does not treat availability as permanent.

This article does not name models, quotas, hardware, or duration, because those facts were not supplied as stable specifications. A free option can lower the cost of trying the workflow on an unclassified catalog that already passed the gate. It cannot replace the classification gate, and it should not be treated as a permanent control boundary. If the gate fails, the reviewer keeps the draft local and still uses an isolated database for the explain step.

Limitations and who should skip this

Masking column names does not anonymize a schema, because unique table names can reveal a launch, a partnership, or a fraud rule. Position A is therefore unsafe for catalogs whose names are themselves confidential, even when row samples never appear in the prompt. A free server with empty statistics will mislead cost comparisons, so its plan cost should not be treated as a production forecast. The sample gate also misses many secret shapes, including internal identifiers that do not resemble email addresses.

Teams should not use the hosted path when contracts forbid external inference or when classification labels are incomplete. They should also skip that path when the agent can obtain write credentials on any reachable database. This debate is the wrong tool if a human acceptance step cannot be staffed for every promoted statement. An automated promotion from a fluent draft to production sits outside the decision rule that follows.

Decision rule

Reviewers should choose the masked hosted draft only when three conditions hold together for that candidate statement. Every referenced object must be classified exportable before the payload is assembled for a hosted call. The gate report must show no sensitive columns and no literals, and the rehearsal server must stay isolated from production. Choose the local draft model when any object is local-only, or when the team cannot review the exact payload before the call.

Reject both external hops when write access cannot be prevented or when no faithful non-production mirror exists. The rule prefers the stricter placement whenever the evidence is mixed, incomplete, or still waiting on classification. Fluency is not evidence of safety, and a free practice surface is not evidence of an acceptable boundary. The recorded extract hash, role grant, and explain output are the acceptance package that later reviewers should trust.

If review notes already capture plans but not placement, add the extract hash before the next agent SQL change. That single field makes the debate auditable, whether the draft model ran locally or on a free hosted practice path. Teams with an export clearance can compare both placements on fixtures and keep the stricter result when the plans disagree.

Grant Matrices or Query Rewrites: A Debate for Agent SQL Least Privilege

Morgan Li — Sun, 11 Oct 2026 21:22:04 +0000

This account previously published a night-shift story about an agent query that locked a production table. The lock was the visible failure, but the missing debate was which privilege path allowed the statement to run at all. A reporting agent can still ask for a temporary superuser role when a narrower view would answer the question. Reviewers need an explicit rule before they choose between a new grant and a query rewrite.

Why least privilege is the debate

Recent developer discussion has stressed that model quality can improve while the surrounding software controls stay unchanged. That signal fits agent SQL, because a sharper model still runs inside roles, views, and grants that humans own. This article does not cite vendor benchmark scores, since no primary measurement was supplied for this draft. The practical question is which control should reject a dangerous statement before it touches shared data.

Position one: expand a grant matrix

A grant matrix treats the agent as an untrusted author and the role catalog as the system of record. Each workflow receives a dedicated login, a narrow schema usage grant, and explicit table or view rights. The matrix records who requested the right, which statement shape needs it, and when the grant should expire. Evidence for this position comes from ordinary privilege errors rather than from model confidence scores or prose explanations.

Supporters argue that query rewrites can hide missing rights until a later report needs one more column. A reviewed matrix makes that gap visible in role table grants before the agent is allowed to run. The operational cost is real, because every new column, sequence, or function can demand another reviewed grant. Teams that keep reporting schemas stable usually absorb that review cost better than teams shipping daily migrations.

PostgreSQL already exposes the evidence through catalog views, so the matrix does not depend on a new engine. A reviewer can compare requested relations with information_schema.role_table_grants and reject any right that lacks an owner. Sequences and functions need separate checks, because table grants do not cover nextval or routine execution. Primary documentation for GRANT and privilege types lives in the current PostgreSQL docs, which should be read for the exact major version in use.

Position two: rewrite onto an approved surface

A rewrite position refuses new grants and forces the agent to target views, functions, or procedures that already exist. The database owner defines those objects, and the agent receives only EXECUTE or SELECT on the approved surface. This approach reduces the chance that a generated statement invents a new path through a base table. The main tradeoff is flexibility, because a useful business question may have no approved object yet.

Evidence here is the diff between the drafted SQL and the allowed surface, which a reviewer can inspect. If the rewrite still needs a new column, the correct response is a schema change, not a silent grant. Rewrites fail closed when the catalog lacks an object, which is often safer than a broad role. They can fail open in practice when someone later adds a security definer routine without a fresh review.

View design matters, because a view can leak rows if the owner bypasses the caller's privileges. PostgreSQL documents security_invoker views, and teams should confirm that option on the version they actually run. A rewrite that ignores owner rights is not least privilege, even when the agent login looks narrow. The safer rewrite is boring: stable names, explicit column lists, and no dynamic schema search path.

CREATE VIEW

Evidence that can actually decide the debate

Decision input	Favors grant matrix	Favors query rewrite	Do not treat as proof
Same report shape runs daily	Rights can be reviewed once and expired on a calendar	An approved view already matches the shape	Model says the SQL looks safe
Schema migrations land daily	Matrix churn may exceed review capacity	Rewrite waits for a reviewed object	A passing local syntax check
Statement needs nextval or EXECUTE	Matrix must name sequence and routine rights	Rewrite should call a procedure instead	Table SELECT alone
Agent asks for superuser or BYPASSRLS	Reject and record the request	Reject and keep the approved surface	Free-tier availability
Reviewer cannot name the data owner	Stop, because a grant has no accountable owner	Stop, because a view owner is also unclear	A green dry run on empty tables

The table is a decision aid, not a measured benchmark, and every cell should be checked against the target catalog. Empty-table success is weak evidence, because missing privileges sometimes appear only after a sequence or a policy is touched. A language model can fill the first draft of this table, but it cannot certify the catalog. Server evidence still means the grants and the rewritten objects were applied on an isolated instance and inspected there.

Numbered rehearsal on a disposable database

The following workflow is a proposed test plan, and it was not executed against a production server for this article. Run it only on a disposable database that you can drop without notice or ticket approval. Keep the agent login unable to create roles, and apply every grant from a separate admin session. Record the SQL diff, the grant diff, and the final privilege query in the same change ticket.

1. Create the narrow role and the approved view

Create the role without superuser, createdb, or createrole, then point the agent at a view you own. Set security invoker only after you confirm that the option exists on the server version you run. Grant schema usage and view select, and do not grant the base table in this step. If view creation fails, stop and fix the owner path before you debate any extra rights.

-- Proposed example, not executed for this article.
-- Replace the password outside version control. Do not reuse this placeholder.
CREATE ROLE agent_reports LOGIN PASSWORD 'replace-me'
  NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT;
CREATE SCHEMA IF NOT EXISTS reporting;
CREATE VIEW reporting.daily_orders
WITH (security_invoker = true) AS
SELECT o.id, o.created_on, o.status
FROM sales.orders AS o
WHERE o.created_on >= CURRENT_DATE - 7;
GRANT USAGE ON SCHEMA reporting TO agent_reports;
GRANT SELECT ON reporting.daily_orders TO agent_reports;

2. Stop drafts that ask for a privileged surface

Scan the drafted text for privilege verbs before you spend any review time on a rewrite. This scan is a heuristic filter, and it will miss obfuscated statements or comments that hide keywords. Treat a match as a stop condition, then ask the agent for a narrower statement shape. Do not treat a clean scan as permission to run the draft against any shared database.

# Proposed local check. It does not parse SQL and it is not a security boundary.
printf '%s\n' "$DRAFT_SQL" | grep -E -i -n \
  'pg_read_file|pg_sleep|bypassrls|security definer|copy |grant |revoke |alter role' \
  && echo 'stop: draft asks for a privileged surface'

3. Collect catalog evidence for both positions

Apply the view path first, then run the two catalog checks from an admin session and from the agent role. A successful view count supports the rewrite position only for that object and that role. A base-table error supports least privilege only if the error is insufficient privilege, not a missing relation caused by search path. Save both outputs beside the drafted SQL so the debate has server evidence rather than model prose.

-- Position A: rights the granting admin can see because that admin is the grantor.
SELECT table_schema, table_name, privilege_type
FROM information_schema.role_table_grants
WHERE grantee = 'agent_reports'
ORDER BY 1, 2, 3;

-- Position B: connect as agent_reports. SET ROLE works only for a member or a superuser.
-- Expect the view to succeed and the base table to fail with insufficient_privilege.
SELECT count(*) FROM reporting.daily_orders;
SELECT count(*) FROM sales.orders;

4. Time-box a grant only after the rewrite loses

Choose the matrix only when the missing right is stable, owned, and narrower than the agent's original request. Put the grant and the matching revoke in one ticket, even if the revoke runs later by schedule. If you cannot name an owner or an expiry, the decision rule below says to stop. A query rewrite remains preferable when an existing approved object already answers the stated business question.

-- Proposed ticket pair. Do not leave the grant without the matching removal.
GRANT SELECT ON sales.orders TO agent_reports;
REVOKE SELECT ON sales.orders FROM agent_reports;

Decision rule

Use the rewrite position when an approved view, function, or procedure already returns the required columns and the agent can access it. Use the grant matrix when no such object exists, a named owner accepts the right, and the grant is narrower than superuser or bypassrls. Stop when the draft asks to create roles, read server files, copy data to a client path, or disable row security. Also stop when the only passing test used empty tables, because that result does not exercise sequences, policies, or default privileges.

If both positions seem viable, prefer the rewrite for one-off questions and the matrix for a report that will run unchanged for weeks. Revisit the choice after each migration, since a new column can invalidate either a view or a grant list. The rule is intentionally conservative, and it will block some useful drafts that an agent could otherwise run. That delay is an accepted cost, because a wrong privilege typically lasts longer than one delayed report.

Where a free model and a free server fit

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

MonkeyCode is included here as an open-source project with operator-stated free model access and a free server option. Those two availability claims are operator-supplied, and this draft does not verify a quota, model list, hardware shape, or duration. A free model can draft the grant matrix, propose the view, and explain which decision-table row it chose. A free server can host the disposable database in the numbered plan, so the privilege checks do not land on production.

Use the model output as a proposal, then require the catalog queries above before anyone accepts a grant. Do not paste production connection strings into a hosted prompt, and do not reuse the sample password from the code block. If current project terms no longer include free model access or a free server, the workflow still stands on local PostgreSQL. Readers who want to rehearse the matrix can confirm today's MonkeyCode terms and repository before they copy any statement into a shared environment.

Limitations and who should skip this

This approach does not replace a SQL parser, a migration framework, or a formal access review. The text scan misses encoded statements, dynamic SQL inside functions, and rights inherited through group roles. security_invoker is version-dependent, and older servers need a different view design that you must verify locally. No latency, cost, or accuracy number in this article was measured against a live database service.

Skip the pattern when you cannot create a disposable database, cannot separate admin and agent logins, or cannot name a data owner. Also skip it for break-glass maintenance that legitimately needs a superuser, because hiding that work inside an agent prompt is worse. Teams that already generate grants from infrastructure code should extend that code, not add a parallel matrix in a chat log. If your only goal is to spend a free quota, this debate will not make the resulting SQL safer.

Closing the choice

Least privilege for agent SQL is a catalog problem with two honest answers, not a prompt-quality contest. Grant matrices make repeated rights reviewable, and query rewrites keep one-off questions on objects you already trust. The decision rule prefers the existing surface, allows a named expiring grant only when that surface is missing, and stops on superuser requests. Server evidence from the numbered checks should outrank a fluent explanation produced by any language model.

Fixture Databases or Disposable Servers: A Debate for Agent SQL Rehearsal

Morgan Li — Sat, 10 Oct 2026 17:47:20 +0000

A checkout service merged an agent-written refund update after a single-schema fixture returned three affected rows. The production planner resolved the unqualified table name through a session search path that the fixture never set. The statement updated a staging copy that shared the table name, and the refund job reported success. The finance auditors noticed the mismatch only after the nightly settlement export failed its reconciliation checks.

This scenario is a composite reconstruction, not a named customer incident, and it isolates one failure mode. Local fixtures proved that the statement could change three rows under a simplified catalog and role. They did not prove that the engine version, privileges, and search path matched the production session. The debate below asks where an agent-written mutation should be allowed to fail before any promotion.

The question the gate has to answer

Agent SQL tools often draft mutations faster than reviewers can replay them on a faithful engine. A fixture database is cheap to host, deterministic to reload, and easy to reset between tests. A disposable server is slower to provision, but it can expose planner, extension, and privilege behavior that a reduced fixture hides. The useful question is not which side sounds stricter, but which evidence the promotion gate can actually collect.

Position A: keep rehearsal inside fixture databases

Fixture advocates want every agent draft to fail inside versioned schema files and a local container. The catalog is small, the data is synthetic, and the test does not depend on a network or a shared host. Reviewers can diff the fixture files and the expected row counts in the same pull request. That position is strongest when the workload is read-only, the dialect is narrow, and production extensions are already mirrored in the fixture.

The weakness of this position is catalog fidelity, not the convenience of resetting a local container. A single-schema SQLite file will not reproduce PostgreSQL search path resolution, partial indexes, or role grants. A container that loads only the happy-path tables can still hide a view, a rule, or a trigger. Passing a fixture then becomes evidence about the fixture, not evidence about the engine that will execute the statement.

Position B: rehearse on a disposable server before promotion

Server advocates want the same statement to run against an engine that matches the production major version and the required extensions. The server should be disposable, loaded only with synthetic rows, and destroyed after the rehearsal run. Network distance and setup time are accepted costs because a wrong schema resolution is more expensive than a slower check. This position is strongest for data mutations, dynamic search paths, and catalogs that fixtures routinely simplify.

The weakness is operational scope, because a hosted server can leak secrets if connection strings are copied from production. It can also create false confidence if its version, extensions, or roles still differ from the target. A green run on the wrong major version is not stronger evidence than a green run on a fixture.

Evidence worth scoring

The decision rule needs evidence columns that either side can satisfy without stating a product preference. The table below is a proposed review rubric, not a benchmark taken from a measured lab. Scores in that table are ordinal labels for a review meeting, not percentages from a production study. A missing cell means the promotion gate cannot claim that class of evidence for the current draft.

Evidence	Fixture databases	Disposable servers
Catalog objects under test	Only what the fixture file creates	Whatever the rehearsal role can see
Search path and role grants	Often omitted or hard-coded	Set in the session before execution
Extension and version match	Easy to skip	Required before the run counts
Reset and reproducibility	Strong, because files are versioned	Weaker, unless the load script is versioned
Data-handling risk	Low if rows are synthetic	Higher if any production extract is used
Time to first failure	Usually shorter	Usually longer

A numbered rehearsal workflow

The numbered steps below are an unexecuted example for a PostgreSQL mutation rehearsal gate, not a timed study. They do not claim measured timings, and they assume a reviewer can run Docker on a local machine. Replace the database names, host ports, and rehearsal credentials before any real use of these commands.

Pin the engine and refuse to continue when the server version does not match the agreed major version.
Load only synthetic rows from a versioned script, and fail if the script contains a production connection string.
Set the rehearsal role, the search path, and a statement timeout before the agent statement is submitted.
Execute inside a transaction, capture row counts and notices, then roll back unless a later human step promotes the change.
Record which evidence columns were actually satisfied, and block promotion when any required column is missing.

A local fixture can still own the load step and the rollback step when the catalog is already complete. A disposable server should own the version pin and the session contract when the statement is a mutation. The gate should store the rollback output next to the SQL draft so the reviewer sees engine evidence, not only model commentary. Comments in the examples mark them as unexecuted, so nobody should treat the sample password as a real secret policy.

-- Unexecuted example: session contract before any agent mutation.
BEGIN;
SET LOCAL statement_timeout = '3s';
SET LOCAL search_path = app, public;
SET LOCAL ROLE rehearsal_writer;
-- Paste agent SQL below this contract, never before it.
-- ROLLBACK is the default end state for rehearsal.
ROLLBACK;

# Unexecuted example. Replace MAJOR with the production major version before running.
docker run --rm --name agent-sql-rehearsal \
  -e POSTGRES_PASSWORD=rehearsal-only \
  -e POSTGRES_DB=rehearsal \
  -p 55432:5432 "postgres:${MAJOR}"
psql 'postgresql://postgres:rehearsal-only@localhost:55432/rehearsal' \
  -c 'SHOW server_version;'

-- Unexecuted fixture that makes the composite failure visible.
CREATE SCHEMA app;
CREATE SCHEMA staging;
CREATE TABLE app.refunds (id int PRIMARY KEY, status text);
CREATE TABLE staging.refunds (id int PRIMARY KEY, status text);
INSERT INTO app.refunds VALUES (1, 'open'), (2, 'open'), (3, 'open');
INSERT INTO staging.refunds VALUES (1, 'open'), (2, 'open'), (3, 'open');

# Unexecuted example: list leading mutation statements for a manual qualifier check.
grep -nE '^(UPDATE|DELETE FROM|INSERT INTO) ' draft.sql

How to read a failed rehearsal

A failed run is useful only when the log shows the session state that produced it. Treat a missing notice, a missing role name, or a missing rollback marker as an incomplete test rather than a pass. Do not widen the statement timeout to hide a lock, because that change answers a different debate about budgets and caps. Record the failing statement text exactly as submitted, including any schema qualifier the agent omitted before execution.

Confirm the server version before you interpret a syntax error, because a version mismatch can mimic a dialect bug.
Print the search path and current user immediately after the failure, and store both lines with the SQL draft.
Compare the affected row count with the fixture expectation only after you know which schema resolved the table name.
Roll the transaction back before you retry, so a diagnostic query does not leave a partial mutation in the rehearsal database.

-- Unexecuted example: capture session state after a rehearsal failure.
SELECT current_user, current_schema(), current_setting('search_path') AS search_path;

Where free model access fits

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

MonkeyCode is described in this outreach as an open-source project with free model access and a free server option. This article treats free model access and a free server option as availability claims supplied for the draft, not as a measured capacity sheet. A reviewer can use free model access to draft the mutation and to list assumptions, then ignore that commentary unless the server output agrees. The free server option is relevant only when a local container is unavailable and the documentation still confirms the offer.

The model should not be the acceptance witness for a mutation that can touch more than one schema. Ask it for a short assumption list: target schema, required indexes, roles, and statements it refused to qualify. Compare that assumption list with the session contract and with the rolled-back server output before anyone promotes the draft. If the model says the table is unique and the server shows two schemas with the same name, the server evidence wins.

That comparison is the same discipline whether the draft came from the assistant under test or from another tool. Reviewers should keep the product name out of the acceptance log and keep the server transcript in it. The draft source matters less than whether the rolled-back engine contradicted an assumption in the list.

Decision rule

Choose fixture databases when the statement is read-only and the fixture already creates every object it can touch. Choose a disposable server when the statement mutates data or uses unqualified names under a role the fixture never grants. Require both when the change is promoted to a shared environment, because each side covers a different failure. Reject the change if the server major version is unpinned, the rows are not synthetic, or the transaction does not roll back by default.

A practical tie-break helps when reviewers disagree about which missing column is acceptable for that draft. If a missing evidence column could change the target object or the lock footprint, the disposable server is mandatory. If the missing column could only change fixture convenience, the fixture is enough for that draft. Write the chosen column set into the pull request so the next agent run cannot silently drop it.

The function below is an unexecuted sketch of the tie-break, and it returns a boolean rather than a performance score. Callers must fill the evidence dictionary from server output, not from the model's own summary of that output. A false return means the draft stays in rehearsal, even if the generated SQL looks complete in review.

# Unexecuted example: promotion checklist. Labels are review notes, not measurements.
REQUIRED_FOR_MUTATION = (
    'version_pinned',
    'synthetic_rows_only',
    'search_path_set',
    'role_set',
    'rolled_back',
)

def allow_promotion(evidence: dict, statement_mutates: bool) -> bool:
    if not statement_mutates:
        return bool(
            evidence.get('fixture_objects_complete')
            and evidence.get('synthetic_rows_only')
        )
    return all(evidence.get(key) for key in REQUIRED_FOR_MUTATION)

Limitations and who should skip this

This workflow does not prove production safety, because a synthetic server is not production traffic, statistics, or concurrency. It does not estimate cost, and it does not replace grants reviews, backups, or a human approval for destructive statements. Quotas, model lists, server regions, and retention rules are outside this article and must be read from current project documentation before use. Anyone who cannot keep sample data synthetic should not point an agent at a hosted server.

Teams that lack a rollback default, a version pin, and a named rehearsal role should not treat a green model answer as acceptance. Operators who need a measured benchmark, a named model, or a guaranteed capacity number will not find those claims here. Readers who only need a local container should skip the hosted option and keep the session contract anyway. The composite opening is a teaching case, so it should not be cited as evidence that any vendor failed.

If the gate in your repository still accepts agent SQL from fixture row counts alone, compare that habit with the session contract above. The MonkeyCode project documentation is one place to check whether free model access and a free server option fit that gate today. Do that check before changing the promotion rule, and do not treat this article as a capacity guarantee. The decision remains the evidence columns in the rubric, not the assistant that drafted the statement.

Model Critique or Server Evidence: A Debate for Agent SQL Acceptance

Morgan Li — Fri, 09 Oct 2026 14:16:57 +0000

A Thursday review queue held one agent draft that joined orders, payments, and refunds for a weekly finance extract. The author had requested a seven-day window, yet the draft projected every column from all three source tables. Two reviewers debated the draft for several minutes before either would approve it for the scheduled job. One reviewer wanted a second model critique, while the other demanded execution evidence from a disposable server.

Both positions can be defended with operational evidence, yet they answer different questions about failure and exposure. A written critique can name a missing predicate, but only a server run shows the plan, the row count, and the locks. This article compares those gates, supplies a reproducible evidence worksheet, and ends with a decision rule for promotion.

The question that should frame the debate

The useful question is not which tool sounds more modern during a crowded afternoon review meeting. The useful question is which failure you fear, and which artifact can actually observe that failure. A missing date predicate is visible in the statement text, while a bad join order appears only after planning. Lock waits, temp file growth, and underestimated row counts appear only when a server executes the statement.

If your acceptance rule collects the wrong artifact, you will feel confident while the risky behavior remains untested. That mismatch, rather than model brand or server price, is the failure mode this debate should reduce. Headlines about model quality do not change the observation problem, because a fluent explanation is still not a plan. Treat news about newer models as a reason to retest your gate, not as a substitute for the artifact.

Position A: a structured critique as the acceptance gate

Position A says a second model pass should accept or reject the draft before any database connection opens. Supporters point to speed, repeatability, and the absence of lock risk while the statement remains plain text. A critique checklist can require named checks for predicates, join keys, selected columns, and explicit limits. The output can be stored beside the draft, diffed across revisions, and reviewed without copying table rows.

The evidence for this position is real, but it is evidence about the text rather than evidence about execution. A careful critique often catches a cartesian join, an unbounded scan, or a write hidden inside a function call. It cannot tell you whether the planner chooses a nested loop, a hash join, or a sequential scan. It also cannot show whether a selective predicate matches zero rows because of a type or timezone mistake.

Position A becomes weak when the same model family drafts the statement and then reviews its own work. Shared blind spots travel from the draft into the critique, especially around business calendars and late-arriving facts. A second pass remains useful as a prefilter, yet it should not be renamed into proof that the query is safe. Keep the critique artifact, and label it as a text review rather than as an execution result.

Position B: server evidence as the acceptance gate

Position B says no agent statement is accepted until a disposable server returns a plan and a bounded result. Supporters argue that production-shaped statistics reveal mistakes that a fluent critique will describe and then miss. A rehearsal session can set a statement timeout, a lock timeout, and a read-only transaction before the draft runs. Those settings do not make the draft correct, but they make a bad draft fail where you can afford it.

The evidence for this position is the plan, the estimates, the bounded output, and the error text from the session. A sequential scan on a fixture of known size is a fact, while a model warning about scans is only a hypothesis. Server evidence also exposes search path surprises, missing indexes, and casts that prevent index use. Those facts are difficult to invent from the SQL text alone, even when the critique sounds specific and confident.

Position B becomes weak when the fixture is tiny, stale, or shaped differently from the production tables. A clean plan on a small synthetic sample can hide a hash spill that appears on a much larger month. A hosted rehearsal server also does not grant permission to upload regulated rows, secrets, or unmasked customer attributes. If the fixture cannot legally leave your network, this position must be satisfied on infrastructure you control.

Where a free model pass and a free server participate

MonkeyCode offers free model access for the critique pass and a free server option for the rehearsal database.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

This draft states neither model names, token quotas, hardware size, nor how long either option remains available. Confirm the current terms in the product documentation before any promotion gate depends on them. The same worksheet still works if you replace that model access with another API and that server with local Postgres. Removing the product name should not remove the debate, the session limits, or the decision rule below.

Use the free options only for masked fixtures and for statement text, not for raw extracts from production. Record which option produced each artifact so a later review can see the boundary you actually tested. A hosted target is a collector of evidence, not a quieter copy of the production role. If the documented terms are narrower than this worksheet, follow the terms and shrink the fixture.

Numbered workflow: collect both artifacts, then decide

The following commands are a proposal for a local rehearsal, and they were not executed for this article. If you use a hosted free server, keep the SQL and replace only the connection target after you confirm its terms. Do not point this workflow at production, even with a read-only role, until a separate change process allows it. Start from an empty database so leftover objects from an earlier experiment cannot silently change the plan.

1. Start a disposable database

# Local throwaway password. Do not reuse it. Pin a supported image tag before relying on this.
docker run --rm --name agent-sql-rehearsal \
  -e POSTGRES_PASSWORD=rehearsal \
  -e POSTGRES_DB=rehearsal \
  -p 55432:5432 \
  postgres:16

The image tag above is an example for a local container, not a description of any hosted free server. Wait for the port to accept connections, then load a masked fixture you are allowed to copy. Keep the fixture row counts in a small file so later steps can detect drift before you trust a plan. Stop the container when the review ends so the data does not linger on a laptop.

2. Record fixture volume before planning

SELECT 'orders' AS relname, COUNT(*) AS fixture_rows FROM orders
UNION ALL
SELECT 'payments', COUNT(*) FROM payments
UNION ALL
SELECT 'refunds', COUNT(*) FROM refunds;

Compare those three counts with the ranges published by the team that owns the weekly finance extract. A fixture that is empty, duplicated, or missing a month will make both the plan and the critique look calmer than production. Write the counts into the evidence record before you open a model prompt or run EXPLAIN. If the drift exceeds the agreed threshold, rebuild the fixture and do not promote the draft.

3. Run the draft inside a read-only, time-bounded transaction

BEGIN READ ONLY;
SET LOCAL statement_timeout = '1500ms';
SET LOCAL lock_timeout = '400ms';
EXPLAIN (FORMAT JSON, COSTS, VERBOSE)
SELECT o.id, p.amount_cents
FROM orders AS o
JOIN payments AS p ON p.order_id = o.id
WHERE o.created_at >= DATE '2026-10-02'
  AND o.created_at < DATE '2026-10-09'
LIMIT 100;
ROLLBACK;

BEGIN READ ONLY rejects writes in that transaction, even if a later statement tries to insert rows. The timeouts bound waiting and execution, but they do not certify that the selected rows are the rows the author wanted. Save the JSON plan, the SQLSTATE if the statement fails, and the wall time reported by psql. If you need actual row counts, run a second statement with EXPLAIN ANALYZE only after the read-only plan is understood.

4. Ask for a critique without sending row samples

Review this SQL as text only. Do not request sample rows.
Checks: date predicate present, join keys named, selected columns minimal,
no DDL, no DML, no unbounded scan language, limit present.
Return a JSON object with pass, findings, and the fear each finding addresses.

Send the statement text and the checklist, not a CSV extract and not the JSON plan's private filter values if those values are sensitive. A critique that asks for example rows is a data-handling event, and it should fail the review even if the SQL looks sound. Store the model output next to the plan, using separate fields so neither artifact overwrites the other. If the critique and the plan disagree, keep both and let the decision rule below pick the stricter gate.

5. Score the record with an explicit function

# Proposal only: not executed against a live database or model for this article.
def promotion_allowed(record: dict) -> bool:
    writes = record["statement_class"] in {"dml", "ddl"}
    if writes and not record["server_evidence"]:
        return False
    if record["fear"] in {"plan", "locks", "row_estimate"} and not record["server_evidence"]:
        return False
    if record.get("regulated_columns") and record.get("rows_sent_to_model"):
        return False
    if record.get("fixture_drift_ratio", 0) > record.get("drift_limit", 0.2):
        return False
    if not record.get("human_reviewed"):
        return False
    return True

The function encodes the debate instead of hiding it inside a prompt that a later editor cannot diff. A 0.2 drift limit is a placeholder threshold for the example, not a measured standard from a production incident. Change that placeholder only when the owning team publishes a numeric range for the masked rehearsal fixture. Run the function in your test suite against the cases in the next section before you trust it in review.

Evidence map and proposed cases

Feared failure	Critique can observe it	Server can observe it	Acceptance rule
Missing date predicate	Yes, from the text	Yes, as an unexpectedly large scan	Either artifact may block; do not accept on silence
Bad join method	Only as a guess	Yes, in the plan nodes	Require server evidence
Hidden write	Sometimes, if the syntax is visible	Yes, read-only mode errors	Require server evidence
Lock wait	No	Yes, when `lock_timeout` fires	Require server evidence
Rows copied into a prompt	No	No	Fail closed; neither gate excuses the copy
Fixture drift	No	Only if you counted rows first	Discard the plan and rebuild

Use the table as a test oracle for promotion_allowed, not as a slogan to paste into a model prompt. The following cases are proposed inputs, and they illustrate the rule without claiming a measured pass rate. A read with fear plan, server evidence present, no regulated columns, drift 0.05, and human review returns true. A write without server evidence returns false, even when the critique field says the statement looks safe.

A regulated extract that sent sample rows to the model returns false, regardless of how clean the plan looks. An empty fixture with drift above the limit returns false, because the plan would describe the wrong data set. These cases are small on purpose, so a reviewer can implement them in minutes and argue about the rule rather than about a framework. Add a case from your own incident archive only when that archive can be shared inside the team.

Decision rule

Name the feared failure before you choose a tool, and write that name into the evidence record.
If the statement writes, changes objects, or calls a function you have not classified, require server evidence on non-production data.
If the fear is a plan shape, a lock, or a row estimate, a critique may prefilter the draft but cannot accept it.
If any column is regulated, do not upload those rows to a third-party server and do not paste samples into a model prompt.
If fixture drift exceeds the published threshold, discard both the plan and the critique's confidence language.
Promote only when the collected artifact matches the fear, the session limits match the script, and a human has read the record.

Apply the six checks in order, and stop at the first failed check instead of averaging them into a soft score. A soft score hides a regulated-data failure behind a fluent critique and a fast rehearsal plan. The rule is intentionally strict about copies and writes, because those failures are expensive relative to a delayed review. Textual doubts can still be resolved by editing the draft and collecting a new pair of artifacts.

Limitations, and who should skip this approach

This approach does not estimate production latency, and it should not be cited as a benchmark of any model or server. A masked fixture can still leak rare identifiers, so legal review remains necessary even when the SQL session is read-only. Timeouts can abort the statement before the needed plan is printed, so a timeout is not itself a safe plan. Shared rehearsal servers can also be noisy, so a slow plan there is not automatic proof of a slow plan in production.

Skip the hosted free server when the fixture cannot leave a private network, or when your policy forbids third-party compute. Skip the model critique path when the statement contains secrets, customer keys, or unpublished financial figures in literal predicates. Skip the whole worksheet if the only available credentials can also reach production, because a pasted connection string defeats the rehearsal boundary. Teams that need a change-advisory approval for every query should keep this method in a lab until that process explicitly allows it.

Closing

Before the next promotion meeting, run one unsettled draft through the six checks and keep the artifact that matches the feared failure. If those free collectors are currently available to you, use them only as described above after you confirm the live terms. That comparison is useful when it changes a decision, and it is noise when it merely adds another confident paragraph. Leave the production role untouched until the written record shows which gate actually observed the risk.

Session Budgets or Driver Caps: A Debate for Agent SQL Exploration

Morgan Li — Thu, 08 Oct 2026 09:49:39 +0000

A composite warehouse incident, rather than a claimed personal outage, is enough to frame this operational choice. An exploratory agent drafted a wide analytical query against a shared reporting database during an ordinary afternoon. The statement sorted a large fact table and held one pooled connection much longer than the dashboard jobs expected. Waiting sessions alone exhausted the pool, so a production lock was not required for the queue to stall.

Teams that let agents explore SQL face the same narrow question after that kind of stall. Should the database session carry the budget, or should the client driver refuse excess work first? Both positions are credible, and both fail in specific, observable ways that a small fixture can expose. The rest of this note compares those positions, then gives a measurement workflow you can rerun.

Two positions, stated without slogans

A session budget is a set of PostgreSQL parameters applied to the connection before the agent statement starts. Typical controls include statement_timeout, lock_timeout, and idle_in_transaction_session_timeout, and each value is a millisecond bound on the session. The server cancels the statement, or the idle transaction, when a bound is crossed, regardless of which client sent the work. That independence is the main evidence for this position, because agents often bypass a careful application wrapper.

A driver cap is a limit enforced in the client before, or while, rows are fetched from the server. Examples include a read-only transaction flag, a client-side query timeout, and a hard maximum on fetched rows. The appeal is precision, because the tool can stop a result stream without waiting for a server timeout to elapse. The weakness is coverage, because any second client, console, or retry path can skip the same wrapper.

These positions are not cosmetic variants of the same control, and the difference shows up in timing. A session budget still lets the server start the work, and only then aborts the statement. A driver cap can refuse further fetches, yet the server may already have produced a batch of rows. Measuring that split matters more than preferring whichever control happens to be easier to configure locally.

Evidence that should settle the argument

Evidence should come from a fixture you control, not from a vendor latency chart or a single anecdote. The useful observations are which bound fires, how many rows leave the server, and whether the pool slot is released. Cost estimates alone do not settle this debate, and neither does a successful run against a tiny sample. A query can be cheap to plan and still pin a connection while a client slowly drains a wide result.

PostgreSQL documents statement_timeout as a client-connection setting that aborts any statement exceeding the configured millisecond limit. The same manual chapter documents lock_timeout and idle_in_transaction_session_timeout as separate bounds that use different failure triggers. A single timeout therefore does not cover lock waits, long statements, and abandoned transactions at once. I am using that manual as the primary description of server behavior, and I am not claiming a hosted benchmark.

Primary source: Client Connection Defaults

Where a free draft host fits

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The operator describes MonkeyCode as an open-source project that offers free model access and a free server option. I am not restating a token quota, a model name, a hardware size, or a duration in this note. Those details were not attached as a primary source, and product terms of that kind change without notice. Check the current project documentation before you plan any workload around a number you saw elsewhere.

In this workflow, free model access is only a drafting aid for two candidate statements, not a safety judge. The free server option is only a disposable PostgreSQL host for the fixture, useful when a local container is inconvenient. Neither availability claim replaces the session budget or the driver cap, and neither claim decides the debate. If those options are unavailable, run the same steps on any Postgres instance you are allowed to reset.

Measurement workflow

The examples below are unexecuted proposals, and they are labeled so they are not mistaken for measured results. They use a tiny table so you can see a cancellation path without scanning a real warehouse table. Replace the connection string with a database you are allowed to reset, and never point the script at production. A passing local run still needs the decision table, because one green script does not rank the two positions.

1. Create a resettable fixture

Create the fixture table, load twenty thousand wide rows, and collect planner statistics before either probe starts. The payload column is intentionally wide, so a careless projection costs memory even when the row count looks modest. Identity keys keep the insert simple, and the region column gives the grouped query a small, stable cardinality. Run ANALYZE so the planner is not the accidental source of a timeout you meant to attribute to data volume.

-- Unexecuted example. Run only on a disposable database.
DROP TABLE IF EXISTS explore_events;
CREATE TABLE explore_events (
  id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  region text NOT NULL,
  payload text NOT NULL,
  occurred_at timestamptz NOT NULL DEFAULT now()
);

INSERT INTO explore_events (region, payload)
SELECT
  CASE WHEN g % 4 = 0 THEN 'east' ELSE 'west' END,
  repeat('x', 200)
FROM generate_series(1, 20000) AS g;

ANALYZE explore_events;

2. Record a session budget on a fresh connection

Open a fresh connection, apply three local timeouts, and expect a cancellation rather than a quiet success. The sleep call is a synthetic delay, so the bound can fire without depending on your disk or CPU speed. A completed statement is not evidence that the budget works, so keep adjusting until you observe the error. The error you want, when the bound is actually hit, is SQLSTATE 57014, which means query_canceled.

-- Unexecuted example. Expect query_canceled if the sleep exceeds the budget.
BEGIN READ ONLY;
SET LOCAL statement_timeout = '150ms';
SET LOCAL lock_timeout = '100ms';
SET LOCAL idle_in_transaction_session_timeout = '2s';

SELECT region, count(*), pg_sleep(1)
FROM explore_events
GROUP BY region
ORDER BY region;

COMMIT;

3. Record a driver cap on another connection

This client stops after fifty fetched rows, which is the concrete driver-cap claim under test today. It does not prove the server avoided work, because a named cursor may already have filled one batch. Capture pg_stat_activity during the fetch if you need to separate client silence from server idle time. Close the cursor by leaving the block, so an abandoned hold does not imitate a pool leak.

# Unexecuted example. Requires psycopg 3 and a disposable DSN.
import os
import psycopg

dsn = os.environ["EXPLORE_DSN"]
sql = """
SELECT id, region, payload
FROM explore_events
ORDER BY id
"""

with psycopg.connect(dsn) as conn:
    conn.execute("SET statement_timeout = '30s'")
    with conn.cursor(name="agent_probe") as cur:
        cur.itersize = 100
        cur.execute(sql)
        rows = []
        for row in cur:
            rows.append(row)
            if len(rows) >= 50:
                break
print(len(rows))

4. Compare one shell observation

Run the activity query while each probe is in flight, using a role that can read pg_stat_activity. Note whether the session remains active, or idle in transaction, after the client has stopped reading rows. In practice, that server-side row often reverses a preference formed entirely from the client application logs. Repeat the check for both probes, because a single snapshot can miss a session that already exited.

# Unexecuted example. Replace the DSN, and do not use a production role.
psql "$EXPLORE_DSN" -c "SELECT pid, state, wait_event_type, query_start
FROM pg_stat_activity
WHERE datname = current_database()
  AND pid <> pg_backend_pid();"

Decision table

Observation on the fixture	Favors session budgets	Favors driver caps	Practical reading
A second client can open a session	Yes	No	The server bound is mandatory
A statement ends quickly but streams many rows	Weak alone	Yes	Add a fetch cap
A client dies and leaves a transaction open	Yes, if the idle timeout is set	No	Set the idle-transaction timeout
You need the error in the server log	Yes	Usually no	Keep the server bound
The wrapper is the only permitted client	Still useful as a backstop	Yes for row stops	Use both, with the server last

Decision rule

Adopt session budgets whenever any client other than your wrapper can reach the exploration database at all. Add driver caps when the tool streams rows and a finished statement can still exhaust memory or pool time. Do not treat a driver cap as a substitute for statement_timeout, lock_timeout, or an idle-transaction timeout. If the fixture cannot show a cancellation or a stopped fetch, do not promote the control into a shared tool.

Use the server budget as the backstop even when the driver cap looks sufficient on one happy script. Retry paths, SQL consoles, and later agents are new clients, and they will not inherit yesterday's wrapper settings. A read-only transaction reduces write risk, but it does not by itself limit CPU, locks, or result size. Keep the three server settings even if the fetch loop already stops at a small row count.

Limitations

This fixture uses twenty thousand rows, so it will not reproduce production planner choices or cache behavior. A statement_timeout that fires here may never fire on a selective query with a huge projected payload. Named cursors reduce client memory, yet the server can still perform substantial work before the first fetch. Free model drafts can propose unsafe SQL, so a human should read both candidates before any execution.

I did not run these statements against a hosted service for this draft, and I am not reporting timings. I am also not reporting quotas, hardware sizes, or permanence for the free server option mentioned above. Availability of that option can change, and a shared host is the wrong place for private data or load generation. Roles that can write, or that can change global configuration, sit outside this read-only exploration workflow.

Who should skip this approach

Skip this approach if the workload is latency-sensitive OLTP and a canceled statement is worse than a slow one. Skip it if policy forbids session-level settings and you also cannot wrap every client that reaches the database. Skip it if the rows are production records and the only available host is a shared evaluation server. Skip it if the agent must apply migrations, because write probes need controls beyond read exploration.

Closing the choice

Session budgets and driver caps answer different failure modes, and the fixture above makes that split visible. Prefer the server bound when you cannot enumerate every client, and add the driver bound when row volume is the risk. Re-run the four steps after any change to pool size, timeout values, or the agent tool's fetch loop. If a local database is inconvenient, confirm the current free-server terms, then run only this disposable fixture there.

Schema Cards or Isolated Rehearsal: A Debate for Agent SQL Drafts

Morgan Li — Thu, 24 Sep 2026 20:15:23 +0000

The staging failure below is a reconstructed example, not a measured incident from this account's history. A checkout service asked an agent to draft a backfill after refunds.amount became a stored generated column. The prompt still held an older schema card that described amount as a writable numeric field. The draft update looked legal on that card and survived a short human skim in review.

Shared staging rejected the statement only after the agent had already consumed a full review cycle. The channel then split between people who wanted stricter cards and people who wanted a disposable database. Neither side had a written rule for when a paper review of the card was enough. This debate keeps both positions and ends with a rule you can apply before any promotion.

Two positions that both survive contact with SQL

A schema-card position treats the attached card as the only schema the agent is allowed to trust. The card lists tables, columns, types, nullability, generated flags, and the privileges of the drafting role. Reviewers compare the SQL text with that card and refuse execution while the draft remains open. The blast radius stays small, because a wrong statement never opens a live database connection at all.

An isolated-rehearsal position treats the same card as a hypothesis rather than as proof of executability. The agent may run the draft only on a database that holds synthetic rows and no production secrets. Every trial sits inside a transaction that ends with rollback, together with a short statement timeout. The useful output is an error class, not a guess about how the target server will reject the text.

What this debate refuses to rerun

This split is not a rerun of the contract-versus-catalog tool debate, which asks how an agent learns table shape. Here the card is already in hand, and the open question is whether text review is sufficient before promotion. Execution on shared staging is excluded from both winning paths in the decision rule that follows. The artifact is a hash plus a rolled-back SQLSTATE, not a preference for one metadata reading API.

Evidence you can check without a benchmark

PostgreSQL rejects an ordinary update that assigns to a stored generated column, which a thin card can hide. In PostgreSQL's documented error codes, that rejection is SQLSTATE 428C9, and you should confirm it on your major version. A card that omits the generated flag will approve text that a matching server is required to refuse. A rehearsal on a different major version can hide the same fault, so the server version must be pinned in the run record.

Catalog reads are not a substitute for that pin, because information_schema reflects the database you actually connected to. If the card was exported yesterday and the rehearsal catalog was built last month, the hashes will disagree. Disagreement is a hard stop condition, not a warning you silently override inside the agent prompt. The rest of this workflow is an unexecuted proposal you should run on disposable data before you trust it.

Step 1: Export a schema card and hash it

Start from a database role that can read metadata and cannot read any customer table rows. The export below keeps only the columns a reviewer needs in order to judge a write target. Pipe the copy to a hash so later runs can prove they used the same card. Store the hash beside the draft instead of pasting the whole catalog into every new prompt.

-- Unexecuted proposal. Confirm column names on your PostgreSQL version before use.
SELECT table_name,
       column_name,
       data_type,
       is_nullable,
       is_generated,
       generation_expression
FROM information_schema.columns
WHERE table_schema = 'public'
ORDER BY table_name, ordinal_position;

# Unexecuted proposal. REHEARSAL_URL must point at synthetic data only.
psql "$REHEARSAL_URL" -v ON_ERROR_STOP=1 -At -f card_export.sql | sha256sum

Step 2: Build a synthetic catalog that matches the hash

Apply only the DDL that the card describes, using invented keys and amounts rather than a production sample. Skip extensions, collations, and row-level policies that you have not copied on purpose into this catalog. After the load, recompute the hash and stop if it differs from the card hash in the pull request. A mismatched hash means you are rehearsing a different database than the one the agent was shown.

-- Unexecuted proposal. Synthetic rows only.
CREATE TABLE refunds (
  refund_id bigint PRIMARY KEY,
  order_id bigint NOT NULL,
  net_amount numeric(12,2) NOT NULL,
  fee_amount numeric(12,2) NOT NULL,
  amount numeric(12,2) GENERATED ALWAYS AS (net_amount - fee_amount) STORED
);
INSERT INTO refunds (refund_id, order_id, net_amount, fee_amount)
VALUES (42, 7, 20.00, 1.50);

Step 3: Run the draft inside a transaction that always rolls back

Give the agent a rehearsal role that can write the synthetic tables and nothing else at all. Set a local statement timeout so a bad join cannot occupy the session for the rest of the review. Execute the candidate text, capture the SQLSTATE, and roll back even when the statement succeeds cleanly. Success inside this wrapper means the text parsed and ran on this catalog, not that it is safe for production.

-- Unexecuted proposal. Always end in ROLLBACK.
BEGIN;
SET LOCAL statement_timeout = '3s';
SET LOCAL search_path = public, pg_temp;
UPDATE refunds
SET amount = amount - 5.00
WHERE refund_id = 42;
ROLLBACK;

On the table above, that update should fail because amount is generated always as an expression. Record 428C9 if your version returns it, and record the exact message if it does not. Do not edit the draft until the recorded class matches the failure you intended to catch. A timeout, a missing table, or a permission error is a different defect and needs its own row in the log.

Step 4: Score the two positions with the same run record

Use one row per draft so the debate does not depend on memory of the review thread. The columns below are deliberately boring, because a promotion meeting should be able to read them aloud. Fill them from the hash command and the rolled-back session, not from the agent's own summary. If a cell is unknown, the decision rule later in this article treats the draft as not ready.

Check	Schema-card only	Isolated rehearsal	Stop if
Card hash stored with the draft	Required	Required	Hash missing
Generated and identity flags present	Required	Required	Flag omitted
Write executed somewhere	Forbidden	Allowed on synthetic data	Shared staging was used
SQLSTATE captured	Not available	Required for writes	Class unknown
Version pin recorded	Optional	Required	Rehearsal version differs
Rollback proven	Not applicable	Required	Session committed

A decision rule for promotion

Choose the schema-card position when the statement is read-only and names only columns on the hashed card. Also require that the statement does not call a function with side effects or a volatile helper. In that narrow case, execution adds little evidence and a banned connection is the safer default. Require isolated rehearsal when the statement writes or targets a generated or identity column at all.

Also require rehearsal when the statement joins tables whose row counts are absent from the card. Refuse both options when the only reachable database is shared staging or production, then return the draft to a named owner. A named owner is a person who can change grants, not the agent that produced the SQL text.

Read-only does not mean harmless, because a select can still lock rows if the agent adds a locking clause. Treat FOR UPDATE, FOR SHARE, and any explicit lock statement as a write for this rule. Also treat DDL, COPY, and calls that insert into audit tables as writes even when the main verb looks like a query. The rule is conservative on purpose, and it will send some safe drafts through rehearsal that a senior reviewer might have waived.

Where a free drafting setup fits

Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode, supplied here as an open-source option, offers free model access and a free server for rehearsal. Use that pair only as the rehearsal role described here, with the hashed card attached to the prompt. Keep rollback as the default ending, and do not send production connection strings, dumps, or customer keys.

It does not replace the decision rule, and it should never receive a credential that can reach shared staging. The model can propose the update text, while the free server is only useful if it can run your pinned engine. Keep the agent on the rehearsal role so a confident review note cannot open a broader grant. If the free server cannot load an extension you depend on, stop and record that limitation instead of using shared staging.

A missing extension is a catalog mismatch, and the hash check is already designed to catch that class of drift. If your synthetic catalogs already exist, the free model access and the free server option can host the next write rehearsal. Do not treat that hosting convenience as evidence that the generated SQL is correct on your production major version. Confirm the version pin in the run record before anyone promotes the text beyond the rehearsal role.

Limitations that should stay visible

This workflow does not estimate cost, lock duration, or rows touched on a production-sized refund table. A three-second timeout on synthetic data says nothing about a sequential scan against a much larger refund table. Generated-column rules and identity rules vary across major versions, so a pin from last year is not current evidence. Free server capacity can also differ in collation, timezone, and installed extensions, which is why the hash remains mandatory.

The reconstructed checkout story is only a teaching frame, and it is not a customer result or a measured outage count. No latency, token, or accuracy figure is claimed here, because this account did not run a comparative benchmark for this draft. If your operator later supplies versioned product limits, cite those primary notes beside the step that depends on them. Until then, treat availability of a free server as a convenience, not as a guarantee that the option remains unchanged.

Who should not use this split

Skip the rehearsal half if policy forbids sending schema names to an external model, even when the rows are synthetic. Skip it if the workload needs an extension, foreign-data wrapper, or collation that the free server cannot load. Skip the card-only half if reviewers cannot reliably see generated flags, identity flags, and grants on the attachment. Skip the whole debate if the agent already holds a write credential on a shared database, because that credential breaks the rule.

Teams that promote SQL through a locked migration tool may already have a stronger gate than either position. They can still borrow the hash and the SQLSTATE log without adopting the full agent loop. Everyone else should keep the stop row in the table, since an unknown cell is cheaper than a committed staging trial. The next useful change is a stricter card, or a cleaner synthetic catalog, not a broader database role.