sqlai.dev SQL Verifier

Execute a SQL query against a fresh ephemeral in-memory database built from your schema (and optional seed rows). Returns real rows (max 500, truncation flagged), column names+types, row_count, and dialect notes. Errors come back as structured JSON with type/position/suggestion — a failed query is a useful answer, not a failure of this tool. Example: schema "CREATE TABLE t(id INTEGER, name TEXT);", query "SELECT name FROM t WHERE id=1", seed {"t":[{"id":1,"name":"ada"}]} → rows [["ada"]].

{
  "type": "object",
  "properties": {
    "schema": {
      "type": "string",
      "description": "DDL statements (CREATE TABLE ...; multiple statements allowed)."
    },
    "query": {
      "type": "string",
      "description": "ONE SQL statement to execute. Stacked statements are rejected."
    },
    "seed": {
      "type": "object",
      "additionalProperties": {
        "type": "array",
        "items": {
          "type": "object",
          "additionalProperties": {}
        }
      },
      "description": "Optional seed rows: {\"table_name\": [{\"col\": value, ...}, ...]}. Max 10MB total."
    },
    "engine": {
      "type": "string",
      "enum": [
        "sqlite",
        "duckdb"
      ],
      "description": "Engine. Server-side supports 'sqlite' (default). 'duckdb' runs in the browser demo at sqlai.dev only."
    }
  },
  "required": [
    "schema",
    "query"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

Validate a SQL query against a schema WITHOUT executing it (parse + name/type binding via EXPLAIN). Returns ok with referenced tables, or a structured error: {type: unknown_column|unknown_table|syntax|..., message, position, suggestion}. The suggestion is rule-based (edit distance against your schema). Example: query "SELECT nmae FROM users" → error type unknown_column, suggestion 'did you mean "name"?'.

{
  "type": "object",
  "properties": {
    "schema": {
      "type": "string",
      "description": "DDL statements."
    },
    "query": {
      "type": "string",
      "description": "ONE SQL statement to validate."
    },
    "engine": {
      "type": "string",
      "enum": [
        "sqlite",
        "duckdb"
      ],
      "description": "Engine. Server-side supports 'sqlite' (default). 'duckdb' runs in the browser demo at sqlai.dev only."
    }
  },
  "required": [
    "schema",
    "query"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

Return the engine-native query plan for a query (SQLite: EXPLAIN QUERY PLAN) plus full-table-scan warnings. Use it to check whether an index would be used before recommending one. Example: "SELECT * FROM orders WHERE status=?" on an unindexed column → plan ["SCAN orders"], warning about the full scan.

{
  "type": "object",
  "properties": {
    "schema": {
      "type": "string",
      "description": "DDL statements (include your indexes!)."
    },
    "query": {
      "type": "string",
      "description": "ONE SQL statement to explain."
    },
    "engine": {
      "type": "string",
      "enum": [
        "sqlite",
        "duckdb"
      ],
      "description": "Engine. Server-side supports 'sqlite' (default). 'duckdb' runs in the browser demo at sqlai.dev only."
    }
  },
  "required": [
    "schema",
    "query"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

Run up to 10 queries against the same schema+seed. Each query executes in its OWN fresh database — writes in one query are NOT visible to the next (use this for testing variants, not for multi-statement transactions). Returns an array of run_sql results in order.

{
  "type": "object",
  "properties": {
    "schema": {
      "type": "string",
      "description": "DDL statements."
    },
    "queries": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "maxItems": 10,
      "description": "Up to 10 statements, one per entry."
    },
    "seed": {
      "type": "object",
      "additionalProperties": {
        "type": "array",
        "items": {
          "type": "object",
          "additionalProperties": {}
        }
      },
      "description": "Optional seed rows: {\"table_name\": [{\"col\": value, ...}, ...]}. Max 10MB total."
    },
    "engine": {
      "type": "string",
      "enum": [
        "sqlite",
        "duckdb"
      ],
      "description": "Engine. Server-side supports 'sqlite' (default). 'duckdb' runs in the browser demo at sqlai.dev only."
    }
  },
  "required": [
    "schema",
    "queries"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

Answer "do these two queries return the same thing?" — the self-check for query refactors. Executes query_a and query_b against identical fresh databases and compares result multisets (order-insensitive; order divergence reported separately when ORDER BY is present). Returns equal:boolean, row counts, and capped row-level diffs (only_in_a / only_in_b).

{
  "type": "object",
  "properties": {
    "schema": {
      "type": "string",
      "description": "DDL statements."
    },
    "seed": {
      "type": "object",
      "additionalProperties": {
        "type": "array",
        "items": {
          "type": "object",
          "additionalProperties": {}
        }
      },
      "description": "Optional seed rows: {\"table_name\": [{\"col\": value, ...}, ...]}. Max 10MB total."
    },
    "query_a": {
      "type": "string",
      "description": "Original query."
    },
    "query_b": {
      "type": "string",
      "description": "Refactored/alternative query."
    },
    "engine": {
      "type": "string",
      "enum": [
        "sqlite",
        "duckdb"
      ],
      "description": "Engine. Server-side supports 'sqlite' (default). 'duckdb' runs in the browser demo at sqlai.dev only."
    }
  },
  "required": [
    "schema",
    "query_a",
    "query_b"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}