DEV Community: Omer Hochman

The duplicate-rows query you re-Google every six weeks

Omer Hochman — Tue, 18 Aug 2026 01:22:27 +0000

Originally published at nlqdb.com/blog

There is a query nobody memorises and everybody needs: find the rows that are duplicated. A customer signed up twice, an import ran twice, a join fanned out and doubled every row. The answer has been the same for thirty years — GROUP BY the suspect columns, HAVING COUNT(*) > 1 — and yet if you are not writing SQL daily you look it up every single time, because the shape is just unusual enough to not stick.

-- Which emails appear more than once?
SELECT email, COUNT(*) AS n
FROM customers
GROUP BY email
HAVING COUNT(*) > 1;

The trap is not difficulty — it is that the shape changes under you

It bites in quiet ways. Group by the wrong columns and you under- or over-count — the grain of the query is the definition of "duplicate," and it is easy to pick the wrong one. And the moment you want the whole duplicate row rather than just the duplicated key, the query you Googled stops being the query you need. GROUP BY collapses each group to one summary row; to keep every offending row you reach for a window function instead:

-- Keep the full rows, tag the extras
SELECT *
FROM (
  SELECT *,
         ROW_NUMBER() OVER (
           PARTITION BY email
           ORDER BY created_at
         ) AS rn
  FROM customers
) t
WHERE rn > 1;

Same question — "where are my duplicates?" — two structurally different queries, and which one you want depends on whether you need the count or the rows. It is a yes/no question wearing a SQL costume, and the costume changes every time.

Ask in English — then read the SQL it ran

This is exactly the case for asking in plain English and reading the SQL it generates. Not because SQL is beneath you — because the grain matters here and you want to verify it. "Which customers appear more than once by email?" should hand you back both the rows and the GROUP BY email HAVING COUNT(*) > 1 it ran, so you can confirm it grouped on the column you meant before you trust the count. A chat model can write you that query; it cannot run it against your data, and if you paste rows into a prompt and ask it to count, it will confidently hallucinate the tally.

(That is the half we built nlqdb for: ask the duplicate question in English over a Postgres it provisions, or one you already run via a signed-in connect, and get the rows plus the compiled SQL. Honest split — it reports duplicates with a read-only query; which row to keep and how to merge is a write you run deliberately, and matching is exact, not fuzzy.)

Your text-to-SQL eval is lying: the gateway returns HTTP 200 with the error in the body

Omer Hochman — Wed, 12 Aug 2026 01:29:12 +0000

Originally published at nlqdb.com/blog

We were reading a text-to-SQL benchmark score that looked too low. Seven questions per 150-question run came back tagged no_sql — the model, we thought, had simply failed to produce a query. On a frontier lane that is a jarring number. So we opened the raw responses, and the model had failed to produce nothing. The HTTP status was 200 OK. The body was an error.

A 200 is a promise the gateway makes before it knows the answer

This is a property of gateways, not a bug in one vendor. When you call an LLM through an aggregator like OpenRouter, two machines are involved: the gateway you connect to, and the upstream provider it routes your request to. The gateway has to decide its HTTP status when it starts streaming a response to you — and at that moment the upstream request may still be in flight. So it commits to 200 OK, opens the stream, and then the upstream call rate-limits, times out, or errors. The status line already went out. The only place left to report the failure is the response body.

OpenRouter documents exactly this: an error can arrive with a 200 status and a top-level error object instead of choices (errors reference). The shape looks like a normal completion envelope right up until you go looking for the content that isn't there.

// HTTP/1.1 200 OK  ← the status lies
{
  "error": {
    "code": 429,
    "message": "Provider returned error",
    "metadata": { "provider_name": "..." }
  }
}
// no "choices" — the completion never happened

Why res.ok quietly corrupts an eval

The natural client is a two-branch one: if res.ok, parse the completion; otherwise, it's an infrastructure error — pause, back off, retry. That branch is where the damage happens. A 200 with an error body takes the success branch. Your parser reaches for choices[0].message.content, finds nothing, and hands back an empty string. Downstream, an empty completion is indistinguishable from "the model answered but produced no SQL" — so it gets scored as a wrong answer.

That single misclassification does two bad things to a benchmark. It undercounts your engine's true accuracy — the model was never given a chance to answer, yet it eats the loss. And it hides a real capacity problem — those seven failures were rate-limits the harness should have paused and retried, not quality losses to investigate. You end up staring at planner prompts trying to fix an accuracy gap that is actually an outage in disguise.

The fix: res.ok is necessary, not sufficient

Inspect the body for a top-level error before you trust the choices. A response is only a real completion if the transport succeeded and the payload carries content. Everything else is infrastructure — classify it as such so your retry logic and your metrics both see it correctly.

const body = await res.json();

// A 200 is not enough — the error can ride inside it.
if (!res.ok || body?.error) {
  const status = body?.error?.code ?? res.status;
  // 429 → capacity: pause + retry, don't score it
  // 5xx → provider error: retryable, still not a quality loss
  throw new UpstreamError(status, body?.error?.message);
}

const sql = body.choices?.[0]?.message?.content;
if (!sql) throw new UpstreamError(200, "empty completion");

In our own eval harness this was a seven-line change to the response classifier, and it moved the frontier lane's ceiling immediately: seven no_sql "losses" per 150-question run reclassified from engine failure to capacity pause, which the tail-retry already covers. The accuracy number stopped lying, and the retry logic started catching the failures it was written for.

The general rule

Any time you talk to a model through a gateway — an aggregator, a proxy, a load balancer, your own edge worker — the HTTP status describes the hop you completed, not the work you asked for. The two can disagree, and they disagree exactly when things are going wrong, which is the worst time to be blind. Read the body before you believe the status. If you're building an eval or an agent on top of a routed LLM, this one check is the difference between a metric you can trust and a metric that flatters your infrastructure by blaming your model.

(This is one of the classifier rules behind nlqdb, the data layer you ask in English: a rate-limited upstream is paused and retried, not counted as a query the engine couldn't answer — so the accuracy we report is the engine's, not the gateway's.)

The text-to-SQL demo takes an afternoon. The other 90% is why you should buy it.

Omer Hochman — Tue, 11 Aug 2026 01:46:04 +0000

Originally published at nlqdb.com/blog

The demo really is an afternoon. Pull the table definitions out of information_schema, template them into a prompt with the user's question, call a model, run whatever SQL comes back, render the rows. Every stack has a tutorial for this now, and they all work — "let our users ask their data in English" goes from ticket to working prototype before the day ends. That's the 10%.

The other 90% shows up after the first real user

The prototype's job was to produce SQL. The feature's job is to run model-authored SQL against your production database, on your users' behalf, unattended. Those are different jobs, and the gap between them is a stack of infrastructure the tutorial never mentions:

A validator that fails closed. The model will eventually emit a write — a DELETE inside a CTE, a DROP behind a comment, a join onto a table the asker should never see. You need a parser-level allow-list that rejects everything except the reads you meant to permit, and rejects anything it can't parse. A regex denylist is the bug report you haven't received yet.
A plan cache keyed on question + schema version. The same question shouldn't cost a model call twice, so you cache compiled plans — but a cached plan is only valid until the schema moves, so the key has to carry a schema fingerprint and invalidation becomes your problem. Skip this and every dashboard load bills you fresh tokens at p95 model latency.
An eval harness over a labelled set. Prompts get edited, models get swapped or silently updated, and NL→SQL accuracy moves when either happens. Without a scored question→gold-answer set you find the regression when a customer does. Building the harness is a project; keeping the labelled set honest as your schema evolves is a chore with no finish line.

None of this is exotic — every piece is buildable. The catch is that every piece is maintainable: production infrastructure with your on-call rotation's name on it, in service of a feature that probably isn't your product.

The honest build-vs-buy test

The wrong question is "can I generate SQL from English?" Yes — in an afternoon, that's the point. The right question is "do I want to own that stack?" If natural-language querying is your product — you're building a BI tool, a data platform, an agent framework — own it; the validator and the eval harness are your moat. If it's a reporting tab, a search box over each user's own rows, an in-app assistant — a feature inside a product that's about something else — buy the pipeline and embed it, the way you'd buy auth or email instead of running an SMTP server.

(That second case is the one nlqdb exists for: drop in one element or one POST /v1/ask, the English compiles against the live schema, the compiled SQL is shown before anyone trusts it, reads pass a fail-closed allow-list, and the validator/cache/eval stack is our maintenance burden instead of yours. Honest limits: it's a hosted pipeline you embed, not a library you vendor — and "many users over their own rows" still means a database or an isolation scope per tenant, because per-user row-level security inside one shared database isn't shipped.)

The general lesson: a demo prices the first afternoon; a feature prices the years after it. When an AI capability collapses the demo cost to nearly zero — and text-to-SQL has — the build-vs-buy decision doesn't disappear. It just moves to the part of the stack the demo never showed you.

Your offline LLM eval isn't measuring your model — it's measuring your rate limits

Omer Hochman — Sat, 08 Aug 2026 01:16:33 +0000

Originally published at nlqdb.com/blog

Our small NL-to-SQL benchmark — twenty questions, one gold query each, scored by executing the SQL and comparing result sets — came back 17/20 on a greedy pass. An immediate second run on the same commit, drawing three samples per question instead of one, came back 6/20, with 14 of the 20 questions returning no SQL at all. Ninety seconds apart, same engine, same prompts, an eleven-answer collapse.

Nothing regressed. The engine behind nlqdb runs on a chain of free-tier LLM providers, and the second run tripled the request volume the first run had already spent. The providers got tired. The score didn't measure the model's reasoning — it measured the moment the free quota ran out.

The failure signature: instant, empty, off the books

The tell is in the error tally, not the score. Those 14 no-SQL answers were circuit_open fast-fails: an earlier 429 had opened the provider's circuit breaker for its Retry-After window, so the call failed before any tokens were generated — the p50 latency of a failing question was ~0 ms. A model that reasons badly takes seconds to be wrong; a rate limit is wrong instantly. When your failures are instant, you are measuring availability, not accuracy.

On a multi-provider chain the collapse compounds: the 429 opens one breaker, the chain falls through to the next provider (also cooling down), and within a few questions every attempt fails without reaching a model. We hit the same wall at scale — our first full 500-question BIRD dispatch scored a dismal 0.214, and 246 of its 283 no-SQL failures were breaker fast-fails. We discarded the number. It measured the wall, not the engine.

Three rules that keep availability out of the accuracy number

Throttle to measure reasoning. Spacing questions ~4 s apart keeps the run inside the free tiers' request rates. Our first clean throttled pass scored 21/23 — consistent with the healthy 17/20, nowhere near the starved 6/20. Slower, but the number means what it claims to mean.
Budget-stop and resume; don't push through. When every attempt in a stretch fails with rate_limited or circuit_open after one bounded capacity wait, stop scoring and write a checkpoint keyed on the commit SHA. A full 500-question pass now runs as a handful of ~15-minute windows resumed across the day, instead of one starved marathon that scores the outage.
Keep the smoke test away from the powered run. The quick greedy smoke and the windowed canonical run drain the same shared quota; back-to-back, the second one measures the first one's exhaust. Anything else that borrows the free chain — for us, an e2e suite whose driver is an LLM — belongs on a different day than a full eval.

The general lesson: if a benchmark number moves more between 9:00 and 9:02 than it does between two commits, read the error tally before the diff. An execution-accuracy score is only meaningful over questions that actually reached a model, so report attempted-versus-total next to the headline number — and treat instant failures as a capacity problem to engineer around (throttles, breakers, resumable windows), not a reasoning regression to bisect.

Your text-to-SQL model isn't as wrong as your benchmark says. The gold SQL is.

Omer Hochman — Fri, 07 Aug 2026 01:23:04 +0000

Originally published at nlqdb.com/blog

You run BIRD-dev, read an execution accuracy of 0.512, and the instinct is immediate: start writing planner directives to close the gap. We had the same instinct. Before acting on it we did one thing that changed the whole plan — we bucketed the losses. Not skimmed a few failures; tagged all 238 mismatches with a structural differ and counted what actually went wrong in each.

19% of our losses were one DISTINCT — added correctly

The biggest bucket was startling: 46 of 238 mismatches (19%) differ from the gold SQL only by a DISTINCT the model added and gold didn't. COUNT(DISTINCT customer_id) where gold wrote COUNT(*). SELECT DISTINCT x where gold wrote a plain SELECT x. Read the pairs one by one and a large share of them are the model being more correct than the annotation.

-- Question: how many patients had an abnormal lab result?
-- Gold (BIRD annotation):
SELECT COUNT(T1.ID)
FROM Patient AS T1
JOIN Laboratory AS T2 ON T1.ID = T2.ID
WHERE T2.result = 'abnormal';
-- one patient with 5 abnormal labs counts 5 times

-- Model:
SELECT COUNT(DISTINCT T1.ID)
FROM Patient AS T1
JOIN Laboratory AS T2 ON T1.ID = T2.ID
WHERE T2.result = 'abnormal';
-- counts patients — the thing the question asked for

A patient-to-labs join is one-to-many. Counting patients after that join needs COUNT(DISTINCT T1.ID); gold's bare COUNT(T1.ID) over-counts the fan-out. Execution accuracy compares result sets, gold's result set is wrong, so the scorer marks the model wrong for being right.

This is not one benchmark having a bad day

Independent measurement backs the pattern. The Kang lab at UIUC audited BIRD and found 52.8% of instances carry annotation errors (VLDB 2026, arXiv:2601.08778) — wrong gold SQL, ambiguous questions, schema mismatches — and released a corrected evaluation set. When half the answer key has errors, the number the leaderboard prints is not a measurement of your engine. It's a measurement of your engine and the answer key's noise, entangled.

The trap: optimizing into the noise

Here is why this matters beyond bruised pride. If you chase the biggest loss bucket with a prompt directive — "avoid DISTINCT unless explicitly requested" — the benchmark number goes up. You will feel good about it. And you will have taught your model to drop a DISTINCT it should keep, silently degrading real-world answers over one-to-many joins, which are everywhere. That is overfitting to wrong gold: trading production correctness for benchmark points.

The fix: classify your loss mass before touching the prompt

The differ that buckets losses is about a hundred lines and needs no LLM — parse both queries, diff the structure, tag the difference class (extra_DISTINCT, extra column, wrong aggregate, wrong filter…), histogram the tags. Then apply one rule: only write a directive for a bucket where gold is right and the model is wrong.

The same audit that disqualified the DISTINCT bucket qualified another: 7 losses where the model concatenated two requested columns into one (first_name || ' ' || last_name) against a gold that correctly returned two columns — 7 clean losses, zero gold-noise, and no winning query used the pattern. That bucket earned a directive, and re-scoring the de-concatenated predictions against the real databases confirmed it: wrong-to-right flips, zero regressions.

The rule

A benchmark number is a floor bounded by its gold quality, not a measure of your engine. Before you optimize any metric, audit what it's actually counting — because past a point, the returns on prompt engineering aren't limited by your model. They're limited by the answer key.

(This audit is standing practice for nlqdb, the data layer you ask in English: every eval run's losses are bucketed structurally before any planner change ships, so the directives we write target real engine mistakes — not annotation noise.)

Your text-to-SQL accuracy is measured on schemas your users will never build

Omer Hochman — Thu, 06 Aug 2026 01:23:38 +0000

Originally published at nlqdb.com/blog

Every text-to-SQL engine publishes the same two numbers: BIRD and Spider. Ours are not flattering — the strict-$0 free-model chain behind nlqdb currently scores 0.52 on BIRD Mini-Dev and 0.19 on the Spider 2.0-lite SQLite subset. We track both weekly, against a pinned baseline, with a paired significance test, because those benchmarks are the honesty instrument of this field: hard, public, and comparable to every research paper.

But look at what they actually measure. BIRD's databases are real-world dumps — dozens of tables, cryptic column names, dirty values, questions that hinge on external knowledge notes. Spider 2.0 is enterprise-analytics scale on purpose; its authors built it because models had gotten too good at the small clean stuff. Both are the right kind of hard for a research leaderboard. Neither looks anything like the database a user of a product like ours ever touches.

The schema your users build is the one you never scored

Our users describe a goal in plain English and get a small, freshly-provisioned Postgres: a form-submissions table, a four-table agent-memory schema, a webhook event log. Five tables, honest column names, no fifteen-year accretion of legacy views. That shape — the one 100% of production queries actually run against — had zero rows in either benchmark. Which means the headline accuracy number described a workload we don't serve, in both directions: it undercounts what users experience, and it can hide regressions on the queries they really ask.

persona-bench: gold queries over the ICP shape, same scorer

So we added a third benchmark and open-sourced it into the repo: persona-bench, 23 hand-authored question/gold-SQL pairs over the two schema shapes our personas actually build (a SaaS app DB and the agent-memory preset). Three rules kept it honest:

Same execution-accuracy scorer as BIRD/Spider. A result-set match against gold, not an LLM judge — the number is comparable across all three datasets.
Gold is literal-date, never relative. No now() in gold SQL, so a question's answer never drifts with the clock and a run today reproduces a run in March.
A gold-executability invariant runs first. Every gold query must execute against the fixture and return non-degenerate rows before any model is scored. A benchmark with broken gold measures nothing — the ruler gets checked before the thing it measures.

The result: the same free chain that scores 0.52 on BIRD and 0.19 on Spider scores 0.96 (22/23) on persona-bench. That is not a brag — small clean schemas are exactly where NL-to-SQL is easy, which is the point: the difficulty distribution of a benchmark is a product decision, and defaulting to the academic one silently pins your roadmap to someone else's workload. The one persona-bench miss told us more about our planner than fifty BIRD misses over schemas we will never host.

Keep both numbers

The failure mode to avoid is swapping the hard public benchmark for your flattering private one. We report all three: BIRD and Spider for comparability and as the hard floor that keeps us honest, persona-bench for the workload users hit. Two caveats we attach every time: 23 questions is small — one flipped answer moves the score about 4 points — and a benchmark you author yourself has an obvious conflict of interest, which the executability invariant and publishing the fixture mitigate but do not remove.

If you ship an NL-to-data feature, the take-away is one afternoon of work: write twenty gold queries over the schema shape your users actually have, score them with the same execution-accuracy check the papers use, and run it beside the public benchmarks — not instead of them. (nlqdb is the database you talk to; the harness, fixture, and all three scores live in the open repo.)

Every data tool shipped an MCP server this year. Your agent still can't build on most of them.

Omer Hochman — Mon, 03 Aug 2026 09:24:08 +0000

Originally published at nlqdb.com/blog

MCP is the new "we have an API." Writing a competitor comparison recently, I went to mark "agent-callable" as our differentiator against an AI data-notebook tool — and stopped, because they'd shipped an MCP server too. So had the BI tool two rows up. The honest move was to concede the checkbox. But conceding it surfaced the real axis, and it's one worth naming.

Two shapes of MCP server

There are two shapes of MCP server, and they look identical in a feature matrix. The first wraps a destination app: "ask my published notebook a question," "answer from my dashboard in Slack." The human's workflow, now reachable by an agent. The second exposes infrastructure the agent owns: provision a database, write rows, query them, migrate the schema. Both speak MCP. Only the second lets an agent build something that outlives the conversation.

The tell is to ask what the agent owns after the call returns. If the answer is "a view into a human's analysis," that's a genuinely useful human-in-the-loop surface — and a dead end for an autonomous agent, because the agent can read but can't accumulate. It has nowhere to put the row it just computed. An agent that can query but not persist is a calculator, not a coworker.

"Does it have MCP" is the wrong question

So the question to ask a tool's MCP server isn't "does it exist" — by 2026 it always does. It's "what does it let the agent own?" Read-only over someone else's app, or a substrate the agent can write to and come back to. The matrix can't tell them apart; you have to read what the verbs actually do.

(At nlqdb the MCP verb nlqdb_query materialises a Postgres on first reference — omit the database id with none provisioned and it creates one from the goal, so the agent gets a database it owns, not a window into ours. The comparison that prompted this is at nlqdb vs Hex.)

Your agent's memory is a vector store. Ask it "how many" and watch it fall over.

Omer Hochman — Sun, 02 Aug 2026 09:20:23 +0000

Originally published at nlqdb.com/blog

The standard agent-memory build is an afternoon of work: embed every fact worth keeping, upsert it into a vector store, and before each reply pull the top-k most similar memories back into context. And for what it's built for, it works. Ask "what did this user say about the Berlin migration" and the right snippets come back, ranked by cosine distance. Recall is solved enough that it feels like memory is solved.

Then the agent has been running for a month, and you ask its memory a different kind of question: "how many users asked about pricing this month?" "Average deal size per stage?" "Top 10 topics I logged, ranked by count?" The store dutifully returns the twenty memories most similar to the question text, the LLM eyeballs them, and you get a confident, specific, wrong number.

Recall is similarity. Reporting is aggregation.

Nothing malfunctioned — the two questions want different machines. A vector store's primitive is nearest-neighbour search: embed the query, rank stored vectors by distance, return the top-k, optionally narrowed by a metadata filter. That is the whole contract. There is no COUNT, no GROUP BY, no JOIN, no HAVING — a similarity engine ships no query planner, and even the metadata filter only narrows candidates around the approximate search, so what comes back is still a ranking of similar items, never a computed result set.

"How many" has to touch every matching row. If the agent logged 4,000 memories and top-k is 20, the context the LLM sees is structurally incapable of producing the count — and an LLM doing arithmetic over a retrieved sample is a hallucination generator, not a query engine. The failure is quiet, too: the answer arrives fluent and plausible, and nothing flags that it was computed from half a percent of the data.

-- "top topics this month, ranked by count" is not a similarity query.
-- It's this — and it must scan every matching row, not the top-k:
SELECT topic, count(*) AS mentions
FROM memories
WHERE created_at >= date_trunc('month', now())
GROUP BY topic
ORDER BY mentions DESC
LIMIT 10;

So the split worth keeping: when the question is "find what's like this" — RAG context, related-document lookup, fuzzy recall over conversation — a vector store is exactly the right machine, and a managed one like Pinecone is genuinely good at it. When the question is "count, group, or rank what I stored", the memory needs to be typed rows behind a real query planner. Neither machine substitutes for the other, and bolting a bigger LLM onto the first one doesn't turn it into the second.

They compose cleanly: vector store as the recall layer, relational store as the analytical one. That second layer is what nlqdb is — a real Postgres the agent provisions itself over MCP and queries in plain English, with the compiled SQL shown so you can read exactly what ran. The honest caveat cuts the other way too: nlqdb ships no embedding search, so it is not your recall layer. Pick the store per question shape — the full side-by-side is at nlqdb vs Pinecone.

Your database scales to zero. Your retry loop doesn't know that.

Omer Hochman — Wed, 29 Jul 2026 17:24:40 +0000

Originally published at nlqdb.com/blog

Serverless Postgres is wonderful until the first query after an idle spell. A free-tier Neon branch parks its compute after ~5 minutes of no traffic; the next query has to wake it, and that first connection can fail while the compute spins back up. We had a retry loop in front of it — three attempts, textbook. It made things worse. The retries fired so fast they all hit the same cold connection, and the user got a crisp db_unreachable about 40 ms after the database had already started waking up.

One retry loop, two completely different failures

Our /v1/ask pipeline has three stages that can each throw a transient: route (an LLM classifier call), plan (the LLM emits SQL), and exec (the query hits the database). We wrapped all three in the same helper — three attempts, then surface. The mistake was assuming a retry is a retry. It isn't. The right delay between attempts depends on why the stage failed, and the two failure modes here want opposite things.

When an LLM call fails, it's usually one provider returning a 5xx or a rate-limit. The fix is to fail over to a sibling provider — and you want to do that immediately, because the sibling is a different machine that is already warm. Any delay is dead time on a spinner. But when exec fails on a cold serverless branch, the fix is the opposite: the same endpoint needs a moment of wall-clock time to become reachable. Retrying it instantly just re-dials a socket that isn't listening yet.

The bug: instant retries replay a cold connection

With a zero-delay loop, all three exec attempts land inside the same few tens of milliseconds — before the compute has finished resuming. Three cold dials, three failures, then a 502 db_unreachable handed to the user. The surface then lies: it says we couldn't reach the database, when in truth we reached it three times in a row while it was mid-boot and gave up ~600 ms before it would have answered. The retries didn't absorb the transient. They burned through the budget the transient needed.

Back off the stage that needs wall-time, not the one that doesn't

The fix is one option on the retry helper: an optional per-stage backoff. route and plan keep retrying instantly — their transient is a provider that fails over to a warm sibling with no benefit to waiting. Only exec opts into a delay, and only because its dominant transient is a compute that needs to wake up.

// route + plan: an LLM provider 5xx'd. Fail over to a sibling
// provider on the NEXT attempt, instantly — waiting buys nothing,
// the sibling is a different machine and already warm.
await withStageRetry("plan", planOnce);

// exec: the dominant transient is a scale-to-zero Postgres compute
// that needs wall-time to resume. Back off so attempts 2/3 land warm.
await withStageRetry("exec", runQuery, {
  backoffMs: (failedAttempt) => 300 * 2 ** (failedAttempt - 1), // 300ms, then 600ms
});

The timeline: attempt 1 at t=0 (cold, fails), wait 300 ms, attempt 2 at t=300 ms, wait 600 ms, attempt 3 at t=900 ms. A free-tier Neon compute resumes inside that ≤900 ms window, so attempt 3 lands warm and the query returns — the user never sees the cold start. The happy path is untouched: a database that's already awake answers on attempt 1 and never sleeps a millisecond. The backoff is pure failure-path cost, paid only by the request that would otherwise have failed outright.

Prove it without a flaky database

A cold-start bug you can only reproduce by waiting five minutes for a real branch to idle is a bug you will never keep fixed. So we made the delay injectable — the helper takes a sleep function, real timers in prod, a fake clock in the test. The test models a branch that stays unreachable until t=700 ms: without backoff, all three instant attempts land before 700 ms and the request surfaces db_unreachable; with the exec backoff, attempt 3 lands at t=900 ms and recovers. Same code path, deterministic, no real database, no five-minute wait. The regression can't silently come back.

The rule

A retry policy is not one setting — it's one per failure mode. Before you pick a backoff, ask what the retry is actually waiting for. Waiting for a different machine to answer? Don't wait — fail over now. Waiting for the same machine to wake up? The wait is the entire point, and retrying without it is just three ways to fail at the same instant. The error message that says "unreachable" is often really saying "you asked 600 ms too early."

(This runs under every question you ask nlqdb, the data layer you talk to in English: the LLM stages fail over between providers instantly, the database stage backs off just long enough for a scale-to-zero branch to wake, and a cold start turns into a slightly slower answer instead of an error.)

AI made the internal-tool builder faster. It didn't ask whether you needed the tool.

Omer Hochman — Tue, 28 Jul 2026 17:19:16 +0000

Originally published at nlqdb.com/blog

Every low-code platform now has an AI layer. Describe the app, it scaffolds the screens against your schema. Ask in English, it writes the SQL. Point an agent at it and it plans, calls tools, and queries your data with guardrails. This is real and it's good — the thing that used to take an afternoon of dragging components and wiring queries takes a prompt.

What got faster is building the tool

But notice what got faster: building the tool. The output is still a destination — an internal app a human opens, logs into, and reads. AI shortened the path from "I need a dashboard" to "I have a dashboard." It didn't question the premise that the answer to a data question is a dashboard you build.

A lot of the time it isn't. The data question lives inside a product you're already shipping — "show this customer their last five orders," "what did this account spend this quarter" — and the honest deliverable isn't a separate admin app, it's an answer rendered inline, on the page the user is already on. Or the asker isn't a human at all: it's an agent that needs to provision a database, write to it, and query it programmatically on every request, with no UI in the loop ever. Neither of those wants a built tool. They want a backend primitive.

Builder or backend primitive

That's the fork. A builder — even an AI-supercharged one — assumes a human will assemble and operate the result. A backend primitive assumes nobody will: you embed one element or call one API, pass an English goal, and get typed rows back. (At nlqdb we took the second side on purpose — English compiles to SQL over a Postgres the product or agent provisions and owns, writes diff-previewed, no app to assemble first — which is exactly why we don't ship a drag-drop canvas. Different job.) The builder wins when the deliverable genuinely is a standalone tool a team will run; the primitive wins when the answer belongs in the product, or the asker is code.

Lesson: when an AI feature makes an old workflow 10× faster, check whether it made the workflow faster or the outcome faster. Scaffolding an internal tool faster is a real win — but if what you actually needed was the answer in your own app, or a database your agent stands up itself, the fastest builder is still building something you didn't need.

Top N per group is the query `LIMIT` can't write

Omer Hochman — Mon, 27 Jul 2026 17:19:13 +0000

Originally published at nlqdb.com/blog

You want the top 3 best-selling products in each category. Or the most recent order per customer. Or the highest-scoring attempt per user. The English is so plain it feels like it should compile to something you already know — ORDER BY revenue DESC LIMIT 3 — and that is exactly the trap. LIMIT caps the whole result set. Ask it for the top 3 and it hands you the 3 best rows across every category combined, not 3 per category. The word "per" quietly moved the query somewhere LIMIT cannot follow.

-- What you wrote (wrong): 3 rows total, not 3 per category
SELECT category, name, revenue
FROM products
ORDER BY revenue DESC
LIMIT 3;

"Per group" is a partition, not a limit

This is the classic "greatest-N-per-group" problem, and the reason it gets re-Googled every time is that the correct shape looks nothing like the question. You are not limiting rows — you are ranking within each group and keeping the top of each rank. That is a window function: number the rows inside each partition, then filter to the rank you want.

-- Rank inside each category, then keep the top 3 of each
SELECT category, name, revenue
FROM (
  SELECT category, name, revenue,
         ROW_NUMBER() OVER (
           PARTITION BY category
           ORDER BY revenue DESC
         ) AS rn
  FROM products
) t
WHERE rn <= 3;

The PARTITION BY is the "per category" the English asked for; the ORDER BY inside the window is the "best-selling"; the outer WHERE rn <= 3 is the "top 3." You cannot filter on rn in the same SELECT that computes it — window functions are evaluated after WHERE — so it has to be a subquery (or a CTE). That structural jump, from a flat query to a nested ranked one, is the whole difficulty. Nothing here is hard; it just doesn't resemble the sentence you started with.

The decision hiding in "top 3": what happens to ties

There is a second choice buried in that query, and it is the one that bites in production. If two products tie for third place by revenue, do you want exactly 3 rows, or all the rows tied at rank 3? ROW_NUMBER() breaks ties arbitrarily and gives you exactly 3 — but which of the tied rows it drops is undefined unless your ORDER BY is fully deterministic. RANK() keeps every tied row (so "top 3" might return 4). DENSE_RANK() keeps ties but doesn't skip rank numbers. Same English, three different answers, and the query never tells you which one you picked — you have to have decided.

ROW_NUMBER() — exactly N rows per group; ties broken by the ORDER BY (add a tiebreak column, or the drop is nondeterministic).
RANK() — every tied row at the cutoff is included, and rank numbers skip after a tie (1, 2, 2, 4).
DENSE_RANK() — ties included, no gaps in the numbering (1, 2, 2, 3).

Ask in English — then read the SQL it ran

This is a good case for asking in plain English and reading the query back, precisely because the failure mode is silent: the wrong-LIMIT version runs fine and returns rows — just the wrong ones — and the tie behaviour never announces itself. "Top 3 products per category by revenue" should hand you back both the ranked rows and the ROW_NUMBER() OVER (PARTITION BY category ORDER BY revenue DESC) it compiled, so you can confirm it partitioned by the column you meant and see how ties resolve before you trust the numbers in a deck.

(That is the half we built nlqdb for: ask the top-N question in English over a Postgres it provisions, or one you already run via a signed-in connect, and get the ranked rows plus the compiled window-function SQL. Honest split — it returns a read-only ranked answer, not a live leaderboard that updates on its own; and if you want ties included, say so and it switches ROW_NUMBER to RANK or DENSE_RANK.)

The general lesson: when a question says "per" or "in each," the grain moved from the result set to a group inside it, and set-level tools like LIMIT stop applying. Reach for a window function — and decide the tie rule on purpose, because the query will pick one for you whether or not you meant to.

We published 20 blog posts and never shipped a feed. Nothing could subscribe.

Omer Hochman — Sun, 26 Jul 2026 17:32:18 +0000

Originally published at nlqdb.com/blog

For weeks the blog grew and the reach didn't. We published post after post — engineering notes, SQL traps, honest comparisons — and every one rendered fine at its own URL. Anyone who already knew the URL could read it. That was the whole reach: people we'd already reached. The pages were live, and publishing felt done. It wasn't. Publishing a page and publishing a feed are two different acts, and we'd only done the first.

Publishing ends when a machine can subscribe, not when a page renders

A web page is something a human pulls up once. A feed is something a machine subscribes to and pulls forever. Everything that redistributes your writing — every reader, every aggregator, every cross-post integration — is a machine, and a machine needs a stable URL that lists your posts in a format it can parse. That URL is your RSS or Atom feed. Without it, your content has doors a human can walk through one at a time and no door a machine can automate. The blog isn't dead; it's just sealed to everything that would spread it.

What a feed unlocks that a page can't

Feed readers. Feedly, Inoreader, NetNewsWire — the people most likely to follow an engineering blog live in a reader. No feed URL, no way to follow. You are invisible to your most loyal potential audience.
Auto-import to high-authority venues. dev.to, Medium, and Hashnode all have an 'import your posts from RSS' setting: point it at your feed and every new post auto-mirrors to a domain with far more indexing authority than yours — with a rel=canonical link pointing back, so the SEO credit still accrues to your copy. This is the part that actually moves the yield needle, and it is impossible without a feed URL.
Everything else that speaks RSS. Newsletter tools, Slack/Discord post bots, IFTTT/Zapier automations — the long tail of redistribution all keys off one feed URL. Ship it once and every one of these becomes a config field instead of a project.

Without a feed, each of those becomes a manual copy-paste: open the venue, paste the title, paste the body, fix the formatting, set the canonical link by hand. It works for exactly as long as your discipline holds, and then it quietly stops — the third week you're busy, the re-posts don't happen, and nobody notices because there's no error, just silence.

The fix was about 40 lines and no dependency

The obvious move is to reach for a plugin — for us, @astrojs/rss. We didn't. Our posts already live in one typed data file that the sitemap and the llms.txt endpoint both read; a feed is a third reader of the same array. So it's a hand-rolled endpoint that maps each post to an RSS <item>, the exact no-dependency pattern the sitemap already uses, and it runs on Cloudflare Workers with nothing to bundle.

import type { APIRoute } from "astro";
import { BLOG_POSTS } from "../data/blog";

// Titles/descriptions are free text → XML-escape before embedding.
const esc = (s: string) =>
  s.replace(/&/g, "&amp;").replace(/</g, "&lt;").replace(/>/g, "&gt;");

export const GET: APIRoute = () => {
  const items = BLOG_POSTS.map((p) =>
    `<item>\n` +
    `  <title>${esc(p.title)}</title>\n` +
    `  <link>https://nlqdb.com/blog/${p.slug}/</link>\n` +
    `  <pubDate>${new Date(`${p.date}T00:00:00Z`).toUTCString()}</pubDate>\n` +
    `  <description>${esc(p.description)}</description>\n` +
    `</item>`,
  ).join("\n");

  const body = `<?xml version="1.0" encoding="UTF-8"?>\n` +
    `<rss version="2.0"><channel>\n${items}\n</channel></rss>`;

  return new Response(body, {
    headers: { "Content-Type": "application/rss+xml; charset=utf-8" },
  });
};

Two details earn their place. First, XML-escape the free text — titles and descriptions are prose, not known-safe URLs, so an unescaped & or < produces a feed that won't parse (this is the one thing the sitemap endpoint gets to skip, because it only ever emits URL paths). Second, add one <link rel="alternate" type="application/rss+xml"> to the site's <head> so browsers and readers autodiscover the feed from any page — the endpoint exists, but this is what lets a reader find it by pasting your homepage instead of hunting for /rss.xml.

The rule

Count the doors into your content, not the pages. A page count measures how much you wrote; a feed measures how many ways that writing can leave your site without you lifting a finger. A post nobody can subscribe to is a post nobody re-shares — and the gap doesn't show up as an error, it shows up as a referral graph that stays flat while the sitemap keeps growing. If you've been publishing for weeks and the reach isn't compounding, check whether a machine can even subscribe.

(This blog is the daily build log for nlqdb, the data layer you query in plain English. The feed above is real — every post here is auto-importable, rel=canonical back to this domain, from the same typed file that renders the page you're reading.)