Skip to content
LayerbaseLayerbase
Browse docs

Guide

AI query debugging

When a query fails in the query console, a panel appears under the error offering to explain it. It reads the statement you ran and the error the engine gave back, says whether the syntax is valid for that engine, explains why it failed, and often hands you a corrected query. It is included on the Pro plan and on dedicated servers, in every cloud console except the TigerBeetle ledger form.

What it does

  • Click Debug with AI under the error. You get a syntax verdict for that specific engine (dialects differ, and it is judged against the one you are on), a short explanation of the failure, and a recommended next step.
  • Apply a proposed fix. When it is confident enough to write a corrected query, an Apply fix to editor button loads it into the editor. It is never run for you: you read it and press Run yourself, like any other query.
  • Tell it that did not work. A feedback box under the answer takes a sentence in your own words and re-analyzes. Attempts, the errors they produced, and what you said about them stay with the console tab, so it does not keep proposing something you already tried.
  • Ask for a schema-aware answer. Some failures cannot be diagnosed without knowing your tables and columns. When that is the case it says so and asks first. See the next section.

What is sent, and what never is

This is the part worth reading closely. Analysis happens off our servers, at a model provider, so it matters exactly what leaves the platform.

Sent when you click Debug with AI

  • The engine you are on, as a name like PostgreSQL.
  • The text of the query that failed.
  • The error message the engine returned.
  • Earlier attempts in this console session: the queries, their errors, the recommendations you were given, and any feedback you typed.

Sent only after you click Yes, introspect

  • Your table names, column names, and column types. Nothing else: the schema is a list of identifiers, and it is trimmed to the tables your query actually mentions before it is sent.
  • On the document console, your collection names only, with no field information. On the key-value console, keys are treated as data, not schema: what is shared is a sampled summary of key name patterns like user:*, where a segment survives only when it repeats like a namespace, and no raw key name ever leaves your browser.
  • The reading is done by your browser over the same console connection you already query with. The model never connects to your database, and nothing is read until you say yes. Declining simply gets you an answer without it.

Never sent, in any step

  • Your rows. Query results are not part of any request, before or after the schema step.
  • Your credentials, connection string, host, or certificates.
  • Anything from a different database, or from anyone else’s.

Requests reach the model through OpenRouter, and our routing accepts only endpoints that retain nothing and refuses any provider that may store prompts. That constraint is set once, for every AI feature we run, rather than per feature. We keep a record that a call happened (which account, which engine, how large, how it ended) for billing and abuse work; we deliberately do not keep your query text, the error text, or your schema.

One consequence worth stating plainly: an error message can quote your data. A unique-violation names the conflicting value, a type error names the literal that would not cast. If your errors are sensitive, that is the thing to weigh before clicking, not the schema step.

Which consoles have it

Every cloud query console except one: PostgreSQL, MySQL, MariaDB, SQLite, DuckDB, ClickHouse, libSQL, TypeDB, Redis, Valkey, FerretDB, QuestDB, InfluxDB, Qdrant, Meilisearch, CouchDB, and Weaviate. Each console offers it in its own terms. The SQL and TypeQL editors and the time-series consoles show the panel under the error pane. The key-value CLI shows it under a failed command. The document console shows it under the error banner, and a proposed fix loads back into the mongosh-style editor. The REST consoles offer it for a failed request, including an HTTP error status, since a 4xx body is the engine’s error message there; a proposed fix loads the corrected method, path, and body back into the request builder. On Meilisearch it lives in the API view, where you write requests by hand.

The one exception is TigerBeetle: its ledger console is a structured form for accounts and transfers, with typed fields validated before anything is sent, so there is no free-text query for a debugger to analyze or rewrite.

Limits

  • Per minute: up to 20 requests a minute per account. You will not meet this by clicking a button.
  • Per day: up to 50 analyses a day per account, resetting at midnight UTC. Only requests that actually reach the model count. If you use them all, the panel says so and your queries keep running normally.
  • Size: very long queries and very large schemas are refused rather than truncated silently, and a wide schema is narrowed to the tables your query references.
  • Scope: requests are screened, and input that is not a database query to debug is declined. It is a query debugger, not a general-purpose assistant.

These are the figures in force today, not a permanent contract. They exist to keep a shared cost from being run up by one account, and we expect to revisit them as we see real usage.

Turning it on

There is nothing to turn on. Run a query that fails on a Pro plan or a dedicated server, and the panel appears under the error with a Debug with AI button. On Free and Solo the panel is not offered; upgrading is what adds it. See plans.

Good practice

  • Read a proposed fix before running it. It is a suggestion from a model that has seen your query and your error, not a reviewed change, and it can be confidently wrong.
  • Treat a fix that writes data the way you would treat any other write. The console’s destructive-statement prompt still applies, and it is the last thing standing between a suggestion and your table.
  • Say what went wrong in the feedback box rather than re-running the same analysis. The second answer is better than the first mainly because you told it something.