Who it is for

SQL Workbench is built for the people who work on an application's database, not for the people who run the server it lives on. That is a narrow audience on purpose, and the narrowness is what makes the tool fast to learn and quick to use: every feature answers a question one of these three people actually asks.

The developer. You are writing the application. You need to read the schema you are coding against, run a query and see the rows, work out why a join returns nothing, script an object out to a file, and get the change you made on your machine onto the shared database. You want the editor to know your table and column names, and you want the result grid not to fall over when the answer is a hundred thousand rows.

The ops or support engineer. Something is wrong in production and you have to look. You need to find the case, read the row, see what a coded value means, fix one field with a statement you can read back, and export a result for whoever asked. What you mainly need is to not do damage: to know which server you are on before you press Execute, and to be stopped when you are about to write somewhere you did not mean to.

The consultant or integrator. You move a schema and its reference data between environments that are never quite the same. You need to compare a database with a folder of scripts in git, see the difference object by object and line by line, generate the script that closes it, and be told plainly what the script will lose before it runs.

Who it is not for

It is not a DBA tool. If your job is the health of the server — capacity, backups, indexes, plans, jobs, permissions, replication, failover — this tool does almost none of that, and it is not going to. SQL Server Management Studio, pgAdmin and MySQL Workbench are administration consoles first and query editors second; each is decades deep in its own engine's operational surface, and competing with them there would mean doing a worse job of the things above.

That boundary is also why the tool can be cross-platform, start in under a second, and speak four engines. The operational surface is the part of a database tool that is most engine-specific and least portable; leaving it out is what buys the rest.

What it does not do

No hedging, no "not yet" where "no" is the honest answer:

• No performance work. No execution plan viewer or plan comparison, no query tuning advice, no index recommendations, no wait statistics, no DMV or pg_stat dashboards, no profiler or trace capture. You can run EXPLAIN yourself and read the text it returns; nothing draws it for you.
• No monitoring. No live activity or session view, no blocking or deadlock display, no way to kill a session, no alerting, no history of how the server behaved.
• No backup or restore. Not a backup, not a restore, not point-in-time recovery, not a database copy or move at the file level. The one --backup-first flag a deployment takes is SQL Server's own, and PostgreSQL refuses it outright because the engine has no statement for it.
• No job or schedule management. SQL Server Agent jobs, pg_cron, MySQL events: the objects that are schema (a MySQL event's definition) compare and deploy like any other object, but nothing schedules, runs, enables or reports on a job.
• No server administration. No configuration pages, no memory or storage settings, no high-availability, replication, log shipping or failover, no linked servers, no tempdb or filegroup management, no database creation beyond the plain CREATE DATABASE a sync may need.
• No security administration. Users, roles and permissions are not managed, and they are excluded from comparison by default (ExcludeTypes is User, Role, Permission) precisely because a tool that syncs schema between environments must not carry one environment's grants into another. If you need to manage logins, use the engine's own console.
• No debugger. No breakpoints in a procedure, no stepping, no watch window.
• No visual modelling. No ER diagram designer, no drag-and-drop table editor, no reverse-engineered diagram to hand a stakeholder. The tool reads and writes SQL text; the diagram it does not draw.
• No migration framework. It writes a deployment as a migration file for the runner you already use — Flyway's V{n}__name.sql, DbUp's timestamp, grate's up/ folder — with a header carrying the two sides, the moment and a checksum of the body, and it takes the next version number from the folder. What it does not do is keep the history: no migrations table, no record of what has been applied, no repair, no baseline. Running the migrations remains Flyway's job or your framework's.
• No data generation or masking. Making up plausible test data is a different tool.
• No BI or ETL. No report designer, no pipelines, no scheduled extracts, nothing that competes with SSIS, SSRS or a warehouse loader. A query can be run as a report that writes one Excel workbook, and that is the whole of it.
• No NoSQL, no warehouses. Four relational engines, listed below. No MongoDB, no Redis, no Snowflake, no BigQuery, no ODBC catch-all.

And things it does not do yet, which is a different list

These are gaps rather than decisions, and each is honest about where it stands:

• SQLite has no schema sync and no data compare. It reads, queries and exports; the generator and the row reader are not written.
• You cannot edit a result in the grid, on any engine. What exists is narrower: on SQL Server, a result that comes from one table with a key offers Script as DELETE on the selected rows, which writes the statements into the editor for you to read and run. Keying a result back to its table needs to know which table each column came from, which needs a parser the other three engines do not ship, so they do not get even that.
• Only SQL Server has the dependency graph and the relation reader, so the impact view and the editor's offered join conditions are richer there than elsewhere.
• Only SQL Server does incremental refresh; the other engines re-read a database when something changed, because their catalogues record no per-object modification time.
• PostgreSQL deployment does not cover every object kind — extensions, domains, types, policies and rules are not read by the inventory, and a folder that defines one is refused by name rather than skipped silently.

The engines

What you get instead

The things this tool is trying to be better at than a general-purpose console: a result grid that does not care how many rows you asked for; environment guards that make writing to production a deliberate act; compare and sync between any two of a database, a folder of scripts, a project and a package; one command-line tool with the same engine behind it, so what you do by hand can be put in a pipeline; and knowledge packs that put your own meaning on a column whose name is four letters long. The full list is in the feature list, and how it stands against the tools you may be using now is in the comparison.