It reads the database before it writes the query.

It starts with a map.

Before any tool call it gets the table names, their row counts and the joins. No columns yet. It asks for those when it needs them.

It reads the table that matters.

The data comes from a Czech bank, so its codes are in Czech. The catalog says POPLATEK PO OBRATU means 'issuance after transaction'.

It guesses wrong, and the database says so.

There is no column called region. The region is in A3. It also guessed 'region'. The database refused and listed the real columns.

It checks how the data is written.

The data writes 'east Bohemia' with a lower-case e. The question's spelling matches nothing. The data has no English words, so it uses the code from the catalog.

Then it writes the query once.

One query, one number.

SELECT COUNT(*) FROM account AS a
JOIN district AS d ON d.district_id = a.district_id
WHERE a.frequency = 'POPLATEK PO OBRATU' AND d.A3 = 'east Bohemia'

A harder one: three tables.

It reads three tables in one step: races, results and drivers. The winner is the row with positionOrder 1. Names are split in two columns.

Same habit: look at the values first.

It checks the exact race name before it writes the filter. It looks at the time column. Most rows hold a gap like +5.7, not a full time.

One join, one row.

Three tables, one join, one row.

SELECT d.forename, d.surname, res.time
FROM races AS r
JOIN results AS res ON res.raceId = r.raceId
JOIN drivers AS d ON d.driverId = res.driverId
WHERE r.year = 2008
  AND r.name = 'Canadian Grand Prix'
  AND res.positionOrder = 1

Any SQL database.

The same 149 questions on SQLite and on PostgreSQL. The gap is inside the noise.

Every query runs read-only. On SQLite the file opens read-only and only reads are allowed. On PostgreSQL the role can only SELECT, and every statement has a time limit.