Do longer SQL queries fail more often? We checked the logs

Not really. That was our first guess, and the logs did not back it up: short queries failed and long ones succeeded. What actually predicted failure was more interesting, and it came down to two things: how much SQL the model had to invent from scratch, and which warehouse it was inventing it for.

We noticed one workspace's warehouse producing more SQL errors than the others. Claude had full context. It knew the tables, the columns, the descriptions. It was not writing SQL into a blank warehouse. This is one workspace's error log, read by hand, so take it as patterns, not percentages. The short version: schema context is not query context.

What the errors actually were

The warehouse ran on ClickHouse, and the model was writing SQL that looked reasonable in a general SQL sense but was wrong for this specific warehouse. Four patterns showed up again and again.

Correlated subqueries

Common in Postgres-style SQL:

SELECT id, owner_id
FROM transactions
WHERE owner_id IN (
  SELECT owner_id
  FROM users
  WHERE country_code = 'NG'
)
LIMIT 5

ClickHouse: Correlated subqueries are not supported as IN function arguments yet

The model knew the tables and columns. The problem was not discovery. It chose a query pattern that is common elsewhere but not valid in ClickHouse.

Strict aggregation rules

SELECT
  user_id,
  argMax(account_type, created_at) AS latest_account_type
FROM kyc_events
WHERE status = 'verified'

ClickHouse: Column user_id is not under aggregate function and not in GROUP BY keys

The column existed, the table existed. The model had to know how this warehouse wants aggregation queries structured.

UUID and string mismatches

SELECT c.case_id, t.transaction_id
FROM case_scenarios c
JOIN transactions t
  ON c.transaction_id = t.id

ClickHouse: There is no supertype for types String, UUID. JOIN cannot infer common type

A human ClickHouse user learns this one quickly: cast explicitly. The model does not always infer it from schema alone.

Date function assumptions

SELECT dateDiff('day', created_at, '2026-06-01') AS days_since
FROM users

ClickHouse: Expected Date or DateTime, got String

Fixed by knowing the dialect: wrap the literal in toDate(...) before the date arithmetic.

Two things were going on

The real answer was two causes stacking on top of each other.

First, the dialect. ClickHouse is one of the least forgiving SQL dialects out there. SQL that is perfectly valid in Postgres or BigQuery gets rejected here for reasons that have nothing to do with the schema. So "generally correct SQL" fails in ClickHouse more than it would almost anywhere else. If you are wondering whether this is just ClickHouse being ClickHouse, that is half the answer.

Second, the shape of the data model. Based on the table names, descriptions, and repeated query patterns, this warehouse had fewer aggregate and summary tables than comparable ones. Claude had to answer more questions by writing real-time aggregation directly against raw tables.

Instead of:

SELECT month, revenue
FROM monthly_revenue_summary
WHERE month >= '2026-01-01'

It had to build the metric from base events:

WITH filtered_transactions AS (
  SELECT user_id, amount, created_at, status
  FROM transactions
  WHERE created_at >= '2026-01-01'
    AND status = 'completed'
),
monthly_revenue AS (
  SELECT
    toStartOfMonth(created_at) AS month,
    sum(amount) AS revenue
  FROM filtered_transactions
  GROUP BY month
)
SELECT month, revenue
FROM monthly_revenue
ORDER BY month

Not bad SQL. In many cases the right thing to do. But every extra line of hand-written SQL is another chance to hit one of those sharp edges. The two causes multiply: an unforgiving dialect, and a data model that forced the model to write far more SQL against it. That, not query length, is what predicted the failures.

What to do about it

If you see the same pattern, the moves are the same whatever your stack.

Watch for metrics the model rebuilds from raw tables over and over. Those are the ones that want a saved query, a metric definition, or a summary table, so the model reuses verified logic instead of re-deriving it every time.

And give it dialect rules. Not generic instructions like "write valid ClickHouse SQL," but the specific edges it keeps hitting:

• Avoid correlated subqueries in IN and JOIN patterns
• Cast UUID/string joins explicitly
• Use the dialect's date conversion functions before date arithmetic
• Be strict about every selected column in grouped queries

Those rules are boring, but they matter. They are also the kind of context that does not show up in a table schema.

Schema context is not query context

I expected the answer to be "longer queries fail more." That would have been clean. It was not what the logs showed.

Schema context is not the same as query context. Knowing the columns is one layer. Knowing which metrics already exist as summaries is another. Knowing the target dialect's sharp edges is another. The model needs all of it to reliably answer analytics questions.