Text-to-SQL safety checker
No sign-up. The SQL is checked in memory and not stored.
172 / 20,000
What it checks
- Read-only: exactly one statement, a query at the top, and no INSERT, UPDATE, DELETE, MERGE, CREATE, DROP, ALTER or SELECT INTO anywhere inside it — the same rule the DBShifts self-hosted data plane enforces.
- Tables read and tables written, with CTE names left out so a WITH clause is not reported as a table.
- Red flags: writes hidden in a WITH clause, INTO OUTFILE, locking reads, EXEC and CALL, file and network functions (pg_read_file, LOAD_FILE, xp_cmdshell, dblink, OPENROWSET, UTL_HTTP), sleeps, password and catalog tables, OR 1=1, joins with no condition, reads with no WHERE or LIMIT, SELECT *.
- Text the parser cannot read is reported as unsafe, never guessed to be fine.
Questions
How do I know if SQL generated by an AI is safe to run?
Check three things before it touches a real database: that it is a single read-only statement, which tables it reads, and whether it does anything a question never needs — reading files, sleeping, touching password tables, matching every row. This page checks the text. Then run it as a database user that cannot write, so a mistake the check misses still cannot change data.
Can a SELECT statement change data?
Yes. PostgreSQL allows INSERT, UPDATE and DELETE inside a WITH clause, so a statement that starts with SELECT or WITH can delete rows. SELECT ... INTO creates a table, MySQL's SELECT ... INTO OUTFILE writes a file on the server, and FOR UPDATE takes row locks. Functions can have side effects too: pg_read_file and LOAD_FILE read server files, dblink and OPENROWSET reach other servers.
Is this a replacement for database permissions?
No. It reads the statement; it does not run it. A function written by your own team can do anything, and a parser is not a security boundary. Use it to review what an AI produced and to catch mistakes early, and give the agent a read-only database user — the generator on this site writes one for six engines.
Is the SQL I paste stored?
No. It is parsed in memory on our server and the answer is sent back; the request body is not logged or saved. Up to 20,000 characters per check, and a limit of 30 checks a minute per network.
Which databases does it understand?
PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, SQLite, Snowflake and BigQuery. Pick the dialect the SQL was written for: the same text can parse differently (MySQL reads double quotes as a string, PostgreSQL as a column name).
Let agents ask questions without trusting their SQL
Agent Gateway enforces this at the server instead of after the fact: the agent gets read-only tools rather than raw SQL, sensitive columns are masked before rows leave, and every request is audited.