How it compares
How to read this
Every tool here is good at something this one is not. The tables below are meant to help you work out whether SQL Workbench replaces what you use, sits beside it, or does not fit at all — so the gaps are in the tables rather than in a footnote.
Three caveats worth stating before the tables:
- What is written about the other tools is their well-known capability, taken from their public documentation, not from a bench test of every row. They all move; check anything you are about to make a decision on.
- SQL Workbench is pre-1.0. It is used daily by the people who build it, and the engines arrived in this order: SQL Server first and deepest, then PostgreSQL, MySQL and SQLite. Anywhere the tables say a feature is SQL Server only, that is where the work has reached, not a decision.
- A blank cell is a blank cell. Where this tool does nothing, the row says so, and the "administration" table exists precisely because that is where it does nothing at all.
● yes · ◐ partly, or for some engines · blank: no.
Reach and platform
| SQL Workbench | SSMS | DataGrip | Redgate | MySQL Workbench | pgAdmin | DBeaver | |
|---|---|---|---|---|---|---|---|
| Windows | ● | ● | ● | ● | ● | ● | ● |
| macOS | ● | ● | ● | ● | ● | ||
| Linux | ● | ● | ● | ● | ● | ||
| SQL Server | ● | ● | ● | ● | ● | ||
| PostgreSQL | ● | ● | ◐ | ● | ● | ||
| MySQL / MariaDB | ● | ● | ◐ | ● | ● | ||
| SQLite | ● | ● | ● | ||||
| Oracle, DB2, and dozens more | ● | ◐ | ● | ||||
| One tool for every engine it supports | ● | ● | ● | ● | ● | ● |
DataGrip and DBeaver reach far more engines than this tool ever will — that is their whole design, and if you need Oracle or a warehouse, the answer is one of them. Redgate's coverage is per product: SQL Compare and SQL Data Compare are SQL Server's, with separate products and separate licences for the other engines.
Everyday work
| SQL Workbench | SSMS | DataGrip | Redgate | MySQL Workbench | pgAdmin | DBeaver | |
|---|---|---|---|---|---|---|---|
| Query editor with completion from the live schema | ● | ● | ● | ◐ | ● | ● | ● |
| Full parser and refactoring of SQL | ◐ | ◐ | ● | ◐ | ◐ | ||
| Result grid at a hundred thousand rows | ● | ◐ | ● | ◐ | ◐ | ● | |
| Filter a result without re-running it | ● | ● | ◐ | ● | |||
| Edit a result in the grid and save it | ● | ● | ● | ● | ● | ||
| Script statements from selected result rows | ◐ DELETE, SQL Server | ◐ | ● | ● | |||
| Export to Excel, CSV, JSON, XML, SQL, Markdown, wiki, fixed width | ● | ◐ | ● | ◐ | ◐ | ● | |
| Import a CSV or Excel file | ◐ as a grid and generated SQL | ◐ wizard | ● | ● | ◐ | ● | |
| Object explorer with per-type folders and a filter | ● | ● | ● | ● | ● | ● | |
| Script an object as DDL | ● | ● | ● | ● | ● | ● | ● |
| Offline language reference and per-engine primers | ● | ◐ | ◐ | ||||
| Column meanings and coded values from your own knowledge packs | ● | ||||||
| Environment guards: production refuses until unlocked | ● | ◐ colour only | |||||
| Command palette | ● | ● | ◐ | ||||
| Light and dark | ● | ◐ | ● | ◐ | ● | ● | ● |
The two rows nothing else has are the reason this tool exists: environment guards, where a
connection carries what kind of environment it is and a production connection will not run a write
until you unlock it, in the tab, the banner and the badge; and knowledge packs, which put your
own description on a column called nc_st and name the values it holds, in the editor, the grid
and the inspector.
Two rows to read against yourself. Editing a result in the grid is something every other console here does and this one does not, on any engine; the nearest it comes is scripting DELETE statements from selected rows of a keyed SQL Server result. And full parser: DataGrip's understanding of SQL is deeper than this tool's — it parses, so it refactors and renames across a project. Here only T-SQL has a real parser; the other three engines are lexed, which is also why none of them can key a result back to its table — nothing can say for certain which table a column came from, and the editor says so instead of guessing.
Compare, deploy and version control
| SQL Workbench | SSMS | DataGrip | Redgate | MySQL Workbench | pgAdmin | DBeaver | |
|---|---|---|---|---|---|---|---|
| Schema compare, database to database | ● | ◐ via SqlPackage | ● | ● | ● | ◐ EE | |
| Schema compare, database to a folder of SQL in git | ● | ◐ | ● | ||||
Schema compare to a .dacpac or project |
● | ◐ | ● | ||||
| Line-by-line diff of an object's definition | ● | ● | ● | ◐ | ◐ | ||
| Generate a deployment script | ● | ◐ | ◐ | ● | ◐ | ◐ | |
| Apply it, with a dry run first | ● | ◐ | ◐ | ● | ◐ | ◐ | |
| Refuse a change that would lose rows, until you say otherwise | ● | ◐ | ● | ||||
| Data compare and a row-level sync script | ◐ not SQLite | ◐ | ● | ◐ EE | |||
| Export a whole database to a clean folder of SQL | ● | ◐ | ◐ | ● | ◐ | ◐ | ◐ |
| Commit what a sync wrote, and refuse a dirty tree | ● | ◐ | |||||
| A command-line tool with the same engine behind it | ● | ◐ SqlPackage | ● | ||||
| Writes a migration file your runner accepts | ● Flyway, DbUp, grate | ● | |||||
| Keeps the migration history and applied state | ● Flyway |
Redgate is the tool this one is most directly measured against, and on SQL Server it is ahead: SQL Compare has two decades of edge cases in it, and Flyway does the migration history this tool deliberately does not. Where this one differs is that the same comparison engine handles four engines and every side — database, folder, project, package — through one CLI that a pipeline can call, at no licence cost per seat.
The administration surface
This is the table that says what the tool is not. Every blank in the first column is deliberate, and the reasoning is in "Who it is for".
| SQL Workbench | SSMS | DataGrip | Redgate | MySQL Workbench | pgAdmin | DBeaver | |
|---|---|---|---|---|---|---|---|
| Execution plans, visual | ● | ● | ◐ | ● | ● | ◐ | |
| Query tuning and index advice | ◐ | ● separate products | ◐ | ||||
| Live sessions, blocking, kill a session | ● | ● | ● | ● | ◐ | ||
| Monitoring, alerting, history | ◐ | ● separate product | ● | ◐ | |||
| Backup and restore | ● | ● separate product | ● | ● | ◐ | ||
| Jobs and schedules | ● | ● | ◐ | ||||
| Users, roles and permissions | ● | ◐ | ● | ● | ◐ | ||
| Server configuration, HA, replication | ● | ● | ◐ | ||||
| Stored procedure debugger | ◐ | ||||||
| ER diagrams and visual modelling | ◐ | ● | ● | ◐ | ● | ||
| Data generation or masking | ● | ● separate products | ● EE |
So which one
- You administer SQL Server for a living — SSMS, and nothing here changes that.
- You need Oracle, DB2, a warehouse, or fifteen engines at once — DataGrip or DBeaver.
- You are deep in one engine's operational console — pgAdmin or MySQL Workbench is where its own community documents everything.
- You do SQL Server schema and data deployment as a profession — Redgate, with Flyway for the history. This tool will do most of it, across more engines, from a pipeline, but it has not been through as many strange databases as SQL Compare has.
- You write an application, support one, or move schema between environments — this one. It starts fast, the grid does not buckle, it will not let you write to production by accident, it compares and deploys between any two sides across four engines, and everything it does by hand it also does from the command line.
Most people reading this will end up with two tools, and that is a reasonable outcome. The point of being clear about the tables above is so that the second tool is the one you actually need.