HeidiSQL: A Delphi Database Client for MariaDB, MySQL, SQL Server and More

What HeidiSQL is for, and who it is aimed at

HeidiSQL is a graphical interface for managing MariaDB or MySQL servers, Microsoft SQL databases, PostgreSQL, SQLite, Interbase or Firebird. The README lists the operations directly: browse and edit data, create and edit tables, views, procedures, triggers and scheduled events. It also exports structure and data, to an SQL file, to the clipboard, or to another server.

The target user is someone who administers or develops against one of those engines and wants a desktop client rather than a command line. The multi-engine support is the distinguishing part. A MySQL shop that also runs a SQLite file for a side project, or a team migrating between MariaDB and PostgreSQL, can point one client at all of them instead of keeping three installed.

The repository is not archived, and the last push was on 2026-09-18. Releases are frequent: v12.21 on 2026-08-03, v12.20 on 2026-06-22, and v12.19 on 2026-06-20. The project is written in Pascal, primarily Delphi, with a Lazarus/FreePascal path for other platforms.

How the client is structured and where the platform split lives

The repository root shows the shape of the project: source/, components/, packages/, res/, build/, extra/, out/, plus build-res.bat and build.php. That layout is a Delphi project layout, not a cross-platform application layout. The components and packages folders hold the third-party Delphi libraries the README says you must build and install before the main project will compile.

The platform split is explicit in the README. Building HeidiSQL for Windows requires Delphi 12.1. The README states that older Delphi versions will most likely fail and that newer versions may work or fail. It also states that Lazarus or one of the other free compilers cannot currently compile HeidiSQL. For platforms other than Windows, the README points at the lazarus branch.

That is the central architectural fact to understand before adopting the tool. The Windows build and the Linux/macOS build are not the same build path. The Windows path depends on a commercial Delphi installation plus madExcept and a set of resource compilation steps. The non-Windows path lives on a separate branch. If your team spans both, you are maintaining two toolchains, not one.

Installing on Windows and making a first connection

For ordinary use the README does not describe an install procedure; it points to the homepage and the online help page for usage, and to the issue tracker for bugs. The build instructions are aimed at people compiling from source, not at end users.

If you are building from source, the README gives the sequence. You need Delphi 12.1 installed first. Then you load the SynEdit project from the components folder, build both the run-time and design-time packages, and install the design-time package. You do the same for the VirtualTree component project.

# After Delphi 12.1 is installed: build SynEdit packages from components/,
# then VirtualTree packages from components/, then install madExcept.

Next the README says to install madExcept, and then to compile the .rc resource files. The table in the README gives the folder, the file and the command for each one. For example, the icon resource in the res folder is compiled with cgrc, while several others use brcc32.

brcc32 AwesomeFont.RC
cgrc icon.rc
brcc32 icon-question.rc
brcc32 version.rc
brcc32 styles.rc
brcc32 updater.rc

After the resources are compiled, you load the HeidiSQL project from the packages folder. The README notes that if updater.rc and updater.exe do not exist, you can copy them from updater64.rc and updater64.exe. That is the whole documented build path. It is a Windows developer workflow, and it assumes familiarity with Delphi package management.

What the build documentation leaves unsaid

The README is thin in places that matter for evaluation. It does not document rollback, and it does not describe an upgrade procedure for existing installations. It does not list supported server version ranges for any of the seven engines, so you cannot confirm from the README alone whether your particular MariaDB or SQL Server release is covered. It does not describe how the SSH tunnelling that users search for is configured, nor dark mode, nor a portable mode.

The build instructions themselves are the weakest part. The resource compilation table includes a row where the command column simply repeats the file name, manifest.rc, rather than giving a compiler. The README also says older Delphi versions will most likely fail and newer ones may work or fail, which is an honest statement but leaves no supported version range beyond the single 12.1 figure. For a project that ships releases every few weeks, that is a real gap for anyone trying to reproduce a build.

The contribution policy is another constraint worth reading before you plan work. Pull requests are only accepted for bugfixes, and the README says no new features please. A pull request must mention a ticket id, and if no ticket exists for the bug you need to create an issue first and fill out the issue template. Feature work is not a path into this codebase.

HeidiSQL versus DBeaver, and when a GUI client is the wrong tool

The obvious alternative people search for is DBeaver. The difference in approach is the runtime and the platform story. HeidiSQL is a native Pascal application whose Windows build requires Delphi 12.1, and whose non-Windows build lives on the lazarus branch. DBeaver is a Java-based client, which is why it runs the same way on Windows, macOS and Linux without a separate branch per platform. If your requirement is one client binary that behaves identically across three operating systems, that difference decides the choice before any feature comparison starts.

HeidiSQL is also the wrong tool in several concrete cases. If you are working primarily with a database engine outside the seven listed, the client is not aimed at you. If you need a client that installs from a package manager on Linux without building from a branch, the README does not offer that path. If you need to script the client itself, nothing in the README describes a command line or an API; the export targets are an SQL file, the clipboard, or another server, which is a manual workflow rather than an automatable one.

There is also a licensing boundary around the assets. Icons added in January 2019 into a TImageCollection component are copyright Icons8, used with permission granted to Ansgar for this project only. The README says not to copy them for anything other than building HeidiSQL. That matters if you were considering reusing parts of the interface in your own product.

Licence, maintenance and the cost of staying current

HeidiSQL is licensed GPL-2.0, and the LICENSE file sits at the repository root. The practical implication is the usual one for GPL software: if you redistribute a modified build, the GPL terms apply to that distribution. This is a description of the licence identifier, not legal advice; read the LICENSE file and the SECURITY.md file in the repository root before you build a distribution around it.

On maintenance, the repository is not archived and the last push was on 2026-09-18. Three releases landed within roughly six weeks in mid-2026: v12.19 on 2026-06-20, v12.20 on 2026-06-22, and v12.21 on 2026-08-03. That cadence is the relevant fact for planning upgrades, and the README does not document an upgrade or rollback procedure to pair with it, so you should treat version pinning as your own responsibility.

The upgrade cost for a source build is the part most teams underestimate. Every rebuild depends on Delphi 12.1, on the SynEdit and VirtualTree packages being built and installed, on madExcept, and on the resource compilation steps. None of that is automated by a documented script in the README, even though the repository contains build-res.bat and build.php. A team that builds from source owns that toolchain indefinitely.

Editorial conclusion

Adopt HeidiSQL if you spend your day inside MySQL or MariaDB on Windows and want a native client that browses data, edits tables, and moves structure between servers without a JVM or an Electron runtime. Do not adopt it if you need a single cross-platform client for a team on Windows, macOS and Linux, because the Windows build requires Delphi 12.1 and the repository points elsewhere for other platforms. Before committing, verify that your server version is covered by the client's connection protocol, and read the SECURITY.md and LICENSE files in the repository root for how issues and licensing are handled.

Frequently asked questions

Official sources

1. HeidiSQL/HeidiSQL on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases