Optimize SQL with reasoning.

A SQL optimizer rewrites a query so the database can run it with less work. SQL Optimizer reads one statement, applies the syntax and version limits of the engine you choose, and returns a rewrite with a reason and a risk level attached to every change, plus index and statistics advice where it applies.

It makes one statement cheaper for the engine that runs it: fewer rows scanned, a better join order, a projection that stops pulling columns nobody reads. It changes the statement and nothing else — your schema, indexes and data are left alone, and advice about them is reported separately so you can judge it against your own tables. Anything that could alter the result set is flagged rather than applied, and your SQL is not stored, logged or used for training.

Measure before rewriting: read the plan with actual row counts, check whether the index on the filtered column can be used at all, cut the rows and columns the statement asks for, and only then change the SQL. Elapsed time alone does not say which step is the problem — stale statistics or a function wrapped around the filtered column are the usual causes.

Four, in this order: estimated versus actual rows, scan versus seek, the join method and how many times it looped, and where the sort happens. When the two row counts differ by orders of magnitude, the plan was built on wrong statistics and the rest of it cannot be trusted. Total cost is not one of the four — it is an arbitrary unit comparable only inside the same plan.

SQL optimization is supported for PostgreSQL 12 through 18, MySQL 5.7 through 9.0, Oracle 11g through 23ai, and SQL Server 2016 through 2025. The rewrite follows the rules of the selected engine, so pagination, quoting, null handling and string concatenation are emitted in that dialect rather than as a generic template.

No, and the two are separate levers. Index and statistics advice answers whether the database can find rows quickly; a rewrite answers whether the statement asks for the right work at all. SQL Optimizer reports both, but it never invents an index that the rewrite depends on without saying so.

Yes, and the failure is quiet. An empty string is NULL on Oracle but not on PostgreSQL; || concatenates in PostgreSQL and Oracle but is logical OR in MySQL's default mode; unquoted identifiers fold to lower case in PostgreSQL and upper case in Oracle. A rewrite is only correct for the engine and version it was written for, which is why pagination, quoting and null handling are emitted in the dialect you selected.

No. The statement is read to produce the rewrite and is never written to disk, never logged, and never used for model training. Schema and execution-plan fields are optional, and session recording is masked across the entire workbench.

An execution plan tells you what the database did with the statement you gave it; SQL optimization changes the statement itself. The two are complementary: paste the plan into the optional context field and the advice accounts for it, but the rewrite is produced from the SQL.

Yes. One optimization per day is free without an account, for all four SQL dialects (PostgreSQL, MySQL, Oracle, SQL Server), and the output safety checks are included. Paid plans raise the monthly limit to 1,000 (Pro) or 3,000 (Max) optimizations; there is no per-seat pricing.

Treat every rewrite as a suggestion to review, not a result to deploy. Changes that could alter the result set are flagged instead of applied silently, and statements that were not present in the input are called out before you run anything. Check the stated assumptions against your own schema first.