Sequeler: a native Linux SQL client written in Vala

A desktop SQL client that belongs on Linux

Sequeler calls itself a friendly SQL client and is described in the README as a native Linux SQL client built in Vala and Gtk. The word native is the one that separates it from the alternatives, because most database tools today are either Java applications that start slowly or Electron wrappers that consume memory like a browser.

The description of what it does is short. It connects to local and remote databases, it lets you write SQL in a text editor with language recognition, and it visualises SELECT results in a Gtk.Grid widget. Screenshots of the database view in both the light and dark themes are in the repository, which is a small sign of the polish level.

The stack explains the behaviour. Vala compiles to C and to GObject introspection, so the application is a real GTK program with a real widget toolkit rather than a set of web views. Granite supplies the elementary OS widget style, which is why the app looks like it belongs on a Pantheon or elementary desktop, and GtkSourceView provides the editor that does the language recognition.

The audience is a developer or administrator on Linux who wants a database tool that starts instantly, integrates with the desktop theme, and does the one job of running queries without a modelling layer on top.

The supported databases and the query workflow

Three database families are supported: PostgreSQL, MariaDB and MySQL, and SQLite.

That list covers the common cases for a developer working on a machine, from a production Postgres instance to a local SQLite file. What is not listed is as informative as what is, since there is no MySQL fork of the protocol beyond MariaDB and MySQL themselves, and no specialised clients for time series or document stores.

The workflow the README describes is the familiar one. You connect to the database, you write SQL in the editor with language recognition, so keywords, identifiers and string literals are highlighted as you type rather than the whole document being one colour, and the results of a SELECT appear in a grid widget where you can sort and inspect them.

The dependency list in the README explains how the connections work underneath. libgda-5.0 is the GNOME database abstraction that provides the actual drivers, so the same UI code serves every backend. libsecret-1 handles credential storage, which is what lets a saved connection keep its password in the keyring rather than in a config file. libssh2 provides SSH, which in a tool like this is what makes tunnelling to a remote database over an encrypted channel possible without an external tool. gtksourceview-4 provides the editor component with its syntax highlighting engine.

So the feature set is deliberately modest: connect, write, run, read the grid. The value is in doing that quickly and natively rather than in covering the long tail of database administration.

Installing from Flathub, AppCenter or source

There are three routes, and the README lists them in the order of convenience.

The AppCenter of elementary OS is the primary distribution channel, with a badge linking to the AppCenter listing under the application id io.github.ellie_commons.sequeler. Flathub is the second route and, as the README puts it, works no matter which distribution you are using.

Both of those are the right answer for most people, because a Flatpak gives you the same binary on any distribution without touching the system libraries, and the AppCenter handles updates and integration with the desktop.

Building from source is the third option, and the README gives the dependency list to install first.

The list is GTK 3 at version 3.22.29 or later, Granite 5.3 or later, glib-2.0, gee-0.8, gobject-2.0, libxml-2.0, libgda-5.0, gtksourceview-4, libsecret-1, libssh2 and Meson 0.59.0 or later.

The version floors are worth noting. GTK 3.22.29 is the minimum, Granite 5.3 is the elementary widget library, and Meson 0.59.0 is the build system requirement. libgda-5.0 pins the database abstraction to the 5.x series, and gtksourceview-4 pins the editor widget to version 4, which is the GTK 3 generation.

The build itself is two commands, because the project uses Meson with Ninja as the backend.

meson build --prefix=/usr
sudo ninja -C build install

The development profile and running from a terminal

For people who want to work on Sequeler rather than just use it, the README documents a development build profile.

meson build --prefix=/usr -Dprofile=development
sudo ninja -C build install

The stated purpose is to keep the stable version perfectly working while hacking on Sequeler, which is what the profile option is for. It is a build-time switch that separates the development variant from the release one, so the two can sit side by side on the same machine.

The application is then launched by its application id rather than by a generic name.

io.github.ellie_commons.sequeler.Devel

The .Devel suffix is the convention that distinguishes the development build from the released one, so the two do not overwrite each other in the desktop menu.

Two things follow from the dependency on libsecret. Credentials stored in a development build land in the same keyring as any other application, so the separation between profiles is at the binary and configuration level rather than at the secret storage level. And inside a Flatpak, the keyring access is mediated by the portal, which is the usual place where a sandboxed database client behaves differently from a native install.

Repository layout, translations and packaging

The top level of the repository shows a mature project rather than a single file application.

There is a meson.build with a meson_options.txt beside it, a src directory holding the Vala sources, a data directory for the icons, the logo and the screenshots, a po directory for translations, a build-aux directory for the usual autotools style helpers, and a vapi directory for Vala bindings. The io.github.ellie_commons.sequeler.yml file at the root is the Flatpak manifest, and .gitmodules plus the shared-modules directory show that some pieces are pulled in as submodules rather than vendored.

The vapi directory deserves a note, because it is the part that explains the Vala choice. Vala needs to know about the C libraries it binds to, and those bindings are either shipped with the system or maintained here as vapi files. For a project like this, where the interesting interfaces are libgda for database access and Granite for widgets, keeping those bindings local is what allows the project to build against specific versions of the underlying libraries.

Translations are handled on Weblate, and the README asks for help there specifically. That is the usual arrangement for a GNOME application: the source strings live in the po directory, the translation platform does the work, and the badge in the README tracks the coverage.

The AUTHORS file and the funding links, PayPal and Patreon, complete the picture of a project that is small, actively maintained and community funded.

Releases, alternatives and the honest limits

The release history is short and recent. There are two tags from 2025-12-25, v0.9.0 and the packaging revision v0.9.0-1, and before that v0.8.2 from 2021-08-11, released under the name Odin. The last push was on 2026-10-14, so development continues even though the version number has barely moved in five years.

That gap between v0.8.2 and v0.9.0 tells you something about the project's pace, and it is worth weighing if you plan to depend on it. It is a small application with a small maintenance burden, which cuts both ways: nothing is going to break, and nothing new is going to arrive quickly either.

The alternative is the wider category of database clients. A Java based tool gives you schema modelling, a visual query builder and profiling, at the cost of a slow start and a large footprint. A browser based tool gives you a web interface and a server to run. Sequeler gives you a native table editor and nothing else, which is the right trade for a developer who already knows their schema and wants to run a query and read the rows.

There is also the option of the command line. For scripted work, the psql and mysql clients remain the right tools, and a graphical client is not a substitute for them. Sequeler is for the interactive case.

Two limits to keep in mind. The database list is short, so anything outside PostgreSQL, MariaDB, MySQL and SQLite is out of scope. And the version number below 1.0 means the interface can still change between releases, which matters if you script against it.

Editorial conclusion

Sequeler is the right tool for a developer on Linux who wants a database client that looks and behaves like the rest of their desktop rather than a cross platform application in a wrapper, and who values the language recognition in the editor and the straightforward table view. It is the wrong choice for a team that needs schema modelling, diffing or a visual query builder, since those belong to the heavier clients, and the wrong choice if you need a database it does not support. Verify first that your database is one of PostgreSQL, MariaDB, MySQL or SQLite, and if you install the Flatpak that your credentials are stored through libsecret in the sandbox, since that behaves differently from a native install.

Frequently asked questions

Official sources

1. ellie-commons/sequeler on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases