# The mysql-workbench repository is an end-of-life snapshot of the MySQL GUI > This repository holds a snapshot of MySQL Workbench 8, the Oracle graphical tool for SQL development, data modelling, server administration and data migration, published whenever a product release ships. It is the end-of-life branch, and the last push was on 2026-04-23. **mysql/mysql-workbench** — This repository contains the now EOL version of MySQL Workbench 8. For the new Workbench, see https://github.com/mysql/mysql-shell-plugins - Repository: https://github.com/mysql/mysql-workbench - Stars: 1,003 · Forks: 357 - Language: C++ - License: NOASSERTION - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/mysql-mysql-workbench ## A release snapshot, not a development tree The first thing the repository description says is that it contains the now end-of-life version of MySQL Workbench 8, and that for the new Workbench you should see a different repository, mysql-shell-plugins. The default branch is 8.0, and the last push was on 2026-04-23. The README then explains the publishing model, which is the part that changes how you should read the history. The code repository on GitHub is where a snapshot of the internal repository is published every time a new release of the product is published. That is not the same as a normal open source development workflow. There is no continuous stream of upstream commits, no pull requests merged into a master branch that the maintainers work from day to day, and no guarantee that the tip of the branch is what the next release will contain. The commits you see correspond to releases. It is a sensible way to publish the source of a product whose primary development happens inside a company, and it has a real consequence: the git history is a release history, not a development history. If you are trying to understand why a change was made, you are looking for it between two release snapshots, which is a coarser instrument than a normal commit log. The README also says you can use GitHub or the MySQL bug system to contribute, and that filing a pull request on GitHub or a new issue on the MySQL bug system with a patch will be handled. Both channels are named, and which one is actually read is not stated, which is worth considering before you invest time in a patch against a snapshot branch. ## Five areas of functionality, and where the GUI sits in a MySQL workflow Workbench is described as a graphical tool for working with MySQL servers and databases, and it fully supports MySQL server versions 5.6 and higher. The functionality covers five main topics. SQL Development covers creating and managing connections to database servers, configuring connection parameters, and executing SQL queries with the built-in SQL Editor. Data Modeling, called Design in the README, covers creating models of a database schema graphically, reverse and forward engineering between a schema and a live database, and editing the database with the Table Editor. The Table Editor is described as offering facilities for editing Tables, Columns, Indexes, Triggers, Partitioning, Options, Inserts and Privileges, Routines and Views. Server Administration covers administering MySQL server instances by administering users, performing backup and recovery, inspecting audit data, viewing database health, and monitoring server performance. Data Migration allows migration from Microsoft SQL Server, Microsoft Access, Sybase ASE, SQLite, SQL Anywhere, PostreSQL as spelled in the README, and other RDBMS tables, objects and data to MySQL, and it also supports migrating from earlier versions of MySQL to the latest releases. The fifth is MySQL Enterprise Support, meaning support for Enterprise products such as MySQL Enterprise Backup, MySQL Firewall and MySQL Audit. The ordering of those five is the interesting part. A tool that only had a SQL editor would be a query client, and a tool that only had a schema modeler would be a diagram tool. The combination is what makes Workbench a development environment rather than a client, and the reverse and forward engineering feature is the piece that ties the model and the live database together. ## The build is a native C++ desktop application The repository layout is what a large C++ desktop application looks like, and it is worth reading for the shape of the codebase. The primary language is C++, and the top level carries a CMakeLists.txt alongside MySQLWorkbench.sln and a MySQLWorkbench.xcodeproj/ directory, so the same tree builds with CMake on Linux, with Visual Studio on Windows and with Xcode on macOS. There is an App.config and a .clang-format, plus vsprops/ for the Visual Studio project property sheets and prefix/ which typically holds the shared prefix header, with a set_wb_version script at the root for stamping the version. The code is split into frontend/ and backend/, which is the standard separation for an application of this kind, with the frontend carrying the widgets and the backend carrying the logic that talks to the server. The modules/ directory holds the functional parts, plugins/ holds the plug-in surface, and library/ holds shared code. The res/ directory holds resources, images/ holds artwork, po/ holds translations, and ext/ holds third-party code. There is also a samples/ directory with a models/ subdirectory, which in a data modelling tool means sample schema files, and a testing/ directory, plus a WBTests.manifest for the test suite. The doc/ directory holds documentation sources. Several files point at a specific platform convention. Info.plist and WBExtras-Info.plist and Scintilla-Info.plist are macOS bundle metadata, and Scintilla is a well known open source text editing component, which tells you the SQL editor is built on it. PrepareOutputDir.cmd is a Windows batch script, and make_deb is a Debian packaging script, so the repository contains the packaging glue for at least Linux and Windows. ## Licensing is in a file, and third-party materials come with the distribution The licence question for this repository is handled by pointing at a file rather than by naming a licence, and the wording is careful. The README says licence information can be found in the License.txt file, and then adds that the distribution may include materials developed by third parties, and that for licence and attribution notices for those materials you should refer to the same License.txt file. The top level has a License.txt and a SECURITY.md, and the project metadata lists the licence as one that GitHub cannot classify. So the honest position is that this is a proprietary distribution of a commercial product with the source published, and the terms are in the file rather than in a short SPDX expression. The distinction matters for a reader deciding whether they can use the code, and the answer is in License.txt rather than in the README. The copyright line is MySQL Workbench, copyright 2007, 2026, Oracle and/or its affiliates, and the README says MySQL Workbench is brought to you by the MySQL team at Oracle. The AUTHORS file at the top of the tree is the contributor list. The third-party materials point is not a formality in a C++ application of this size. With a native GUI toolkit, a SQL editor component, a charting or scripting layer and localisation data, the bundled dependencies are a substantial part of what you are downloading, and the project handles that by consolidating the notices into one file rather than scattering them. ## What this repository is for, and what it is not The clearest way to describe the value of this repository is as a source of record rather than as a development environment. If you want to know what a given release of Workbench contained, this is where that code is, and it is published under the same version numbers as the product. It is useful for a few specific things. Reading how the SQL editor, the schema modeler or the migration engine actually works, because the source is here rather than behind a binary. Patching a snapshot, which the README explicitly invites, whether that is a build fix for your platform or a change you need to make for your own environment. And understanding the boundaries of the tool itself, which is a schema design and administration tool with a SQL editor attached, not a general database IDE in the Eclipse or JetBrains sense. The limits are equally clear. The branch is end-of-life, so any bug you find here is not going to be fixed upstream in this tree, and the README points elsewhere for the current work. It is a snapshot, so the history is coarse. It is a desktop application, so building and running it needs a GUI environment, a compiler toolchain for the platform and the Qt or native dependencies the frontend needs. And the migration list is the piece that dates the tool. SQL Server, Access, Sybase ASE, SQLite, SQL Anywhere and PostgreSQL as sources, with MySQL as the target, describes a generation of enterprise database landscape. ## Conclusion The mysql-workbench repository suits someone who needs to read or patch the source of the Workbench 8 GUI, and it is the wrong place to start for a new MySQL tooling project, because the description says this is the end-of-life version and points at a different repository for the new Workbench. Before filing anything, read the note that the repository is a snapshot published at release time rather than a continuously developed tree, because that changes what a pull request means. Verify first that the bug tracker you use is the one the project is watching, since the README lists both the MySQL bug system and GitHub issues as places to report. ## FAQ ### What is the mysql-workbench repository? It holds a snapshot of the internal source of MySQL Workbench 8, the Oracle graphical tool for MySQL servers and databases, published to GitHub every time a new product release ships. The repository description notes it is the end-of-life version of Workbench 8 and points to another repository for the new Workbench. ### What can MySQL Workbench do? It covers SQL Development with connection management and a built-in SQL Editor, Data Modeling with graphical schema models and reverse and forward engineering, Server Administration for users, backup and recovery, audit and performance, Data Migration from other RDBMS systems, and support for MySQL Enterprise products. ### Which MySQL server versions does Workbench support? The README says MySQL Workbench fully supports MySQL server versions 5.6 and higher. The application itself is written in C++ and builds with CMake, Visual Studio and Xcode, with frontend and backend directories. ### How do I report a bug in MySQL Workbench? The README says to use the MySQL bug system at bugs.mysql.com to report issues, and that you can use GitHub or the MySQL bug system to contribute to the development, by filing a pull request on GitHub or a new issue on the MySQL bug system with your patch. ### Where are the MySQL Workbench downloads and documentation? The README points to mysqlworkbench.org for the tool, dev.mysql.com/doc/workbench/en for the documentation, and dev.mysql.com/downloads for additional downloads and the source. Licence information is in the License.txt file, which also carries the notices for third-party materials included in the distribution. ## Sources - [Issues](https://github.com/mysql/mysql-workbench/issues) - [mysql/mysql-workbench on GitHub](https://github.com/mysql/mysql-workbench) - [README](https://github.com/mysql/mysql-workbench/blob/8.0/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mysql-mysql-workbench