The deterministic safety net for SQL — for the code you write and the code your AI writes.
Your AI wrote a SQL query, or refactored one. Is it correct? Does it still return the same results? sqlike answers that — deterministically, in about a millisecond, and without your real data ever leaving your machine. Part of sqlike.
These are thin remote clients: an MCP server, a CLI, and a shared client library. They tokenize your SQL locally — identifiers and literals are masked before anything leaves your machine — and forward only the tokenized query to the sqlike API. There is no analysis engine here; that runs server-side and is closed.
59% of developers ship AI-generated code they don't fully understand, and AI SQL looks plausible
while being wrong more often than you'd like — a LEFT JOIN quietly becomes an INNER and drops
rows, a WHERE goes missing and updates everything, tables get joined the wrong way. Plausible is
not correct.
sqlike is the deterministic check that catches it — a guardrail, not another prompt. It
verifies whether a rewrite really preserves results and flags unsafe patterns, and it never
rubber-stamps a change that isn't safe: when it can't prove equivalence, it says Undecided rather
than guess. No model in the loop means no retry loops, no per-token cost, and the same answer every
time.
Add it to any MCP client (Claude Desktop, Cursor, etc.):
{
"mcpServers": {
"sqlike": { "command": "npx", "args": ["-y", "@sqlike/mcp"] }
}
}Or install via Smithery. An optional
SQLIKE_API_KEY environment variable raises rate limits; without it you get the open anonymous tier.
Static analysis of one SQL query: validity, anti-patterns, suggested rewrites, and schema/index advice. Returns the JSON analysis envelope.
| Argument | Type | Description |
|---|---|---|
sql |
string | The SQL query to analyze. Required. |
schema |
string | Optional DDL (CREATE TABLE / CREATE INDEX) for column- & type-aware checks. |
dialect |
string | postgres (default), mysql, sqlite, or mssql. |
allow_raw |
boolean | Only used when a query fails to parse (so can't be tokenized): send raw SQL for a parse diagnostic. Default false. |
Check whether two SQL queries are equivalent (result-preserving) — for verifying a rewrite or
refactor, a judgement an LLM cannot reliably self-grade. Returns a verdict (Equivalent /
EquivalentWithNotes / Differs / Undecided), a confidence level, and a per-property report
(columns, rows, cardinality, order), so you see what changed, not just a yes/no. Undecided never
means equivalent.
| Argument | Type | Description |
|---|---|---|
sql_a |
string | The original query. Required. |
sql_b |
string | The rewritten query to check against sql_a. Required. |
schema |
string | Optional DDL both queries resolve against (one shared schema). |
dialect |
string | postgres (default), mysql, sqlite, or mssql. |
Run the same checks in a pipeline:
npx -y @sqlike/cli analyze query.sqlcrates/cli builds sqlike, a command-line client (--remote https://api.sqlike.com).
Tokenization happens here, on your machine, before any request — sqlike never sees your real
table names, columns, or values. Nothing to leak, nothing to train on (an AI assistant needs the
real thing; sqlike doesn't). If a query can't be parsed it can't be tokenized, and the client
refuses to send it rather than transmit raw SQL, unless you explicitly opt in (allow_raw /
--allow-raw).
crates/mcp:sqlike-mcp, the MCP server. Ships to npm as@sqlike/mcp.crates/cli:sqlike, the command-line client.crates/client: the shared, engine-free forwarder: tokenize → call API → detokenize.crates/core-parse: the SQL parser, stage model, tokenizer, and result types.packages/: the npm packaging for@sqlike/mcp(per-platform prebuilt binaries).
Try it at sqlike.com, or see how it's measured — including a head-to-head against the state-of-the-art academic prover — at sqlike.com/benchmark.
This repository is generated from the upstream monorepo (the source of truth). Please file issues here; code changes are made upstream and mirrored.
MIT OR Apache-2.0, at your option.