SQLly logoSQLly

Competitor watch: connections that forget

I checked 12 open connection bugs from DBeaver, Sequel Ace, Beekeeper, DbGate, HeidiSQL and Azure Data Studio against SQLly. Three were ours; all are fixed.

By

Before a SQL client can show you anything, it has to remember how to reach your server, and then actually get in. So I read twelve open issues from six other SQL clients where one of those two steps broke, and checked every one against SQLly.

SQLly had three of them, and all three are fixed today and ship in the next release (changelog). One feature request talked me into building it: direct TLS for PostgreSQL 17. The other eight I checked, and SQLly doesn't have them.

12issues checked
3bugs SQLly had, now fixed
1new feature: PostgreSQL 17 direct TLS

This is the daily competitor watch. I take a batch of open issues from other SQL clients' public trackers, check whether SQLly has the same problem, and fix it if it does. The people who reported these did the hard part, so every one of them is named and linked below. Some settings forgot themselves on save or on restart: passwords, SSH passwords, an idle timeout, a tool path. Some sign-ins couldn't get through: MySQL accounts on PAM or LDAP, an SSH config split across files, PostgreSQL behind a TLS proxy, and a user name with an "ö" in it. Ages are as of October 20, 2026. "Vendor" means someone the tracker marks as a member, collaborator or staff.

The twelve issues

Idle connection auto-close setting is lost on save (closeIdleConnection: true is removed) DBeaver #42384

Age: opened 1 week ago (October 12, 2026). Labelled regression.

Reactions / comments: 0 / 1.

The vibe: a lovely piece of detective work. Write false and it's saved. Write true and the act of saving deletes it. The reporter hand-edited the JSON to prove it. It's a checkbox that only remembers being unticked.

Credit: @AknowA reported it with the exact before-and-after of the settings file. @davestokes thanked them the next day.

SQLly: checked, not a problem we have. Every connection setting is saved whether it's on or off, and existing tests reload saved connections to prove it.

PostgreSQL: support direct SSL negotiation (sslNegotiation=direct, PG17+) to connect through SNI-routing TLS proxies DBeaver #42359

Age: opened 11 days ago (October 9, 2026). No vendor reply yet.

Reactions / comments: 4 / 3.

The vibe: the most polite feature request on the internet. The reporter explained PostgreSQL 17's new handshake and why Caddy and Traefik need it. They already wrote the patch (about 120 lines, with a unit test) and only asked whether a pull request would be welcome. Eleven days later they nudged, still politely. The patch is sitting there.

Credit: @jhf reported it and offered the implementation, then nudged today. @eriksoeb added their support.

SQLly: we built it today. PostgreSQL connections have a "Direct TLS (PostgreSQL 17+)" checkbox next to the TLS setting. Pasting sslnegotiation=direct ticks it, and Open in Terminal passes it on to psql. We tried it against a real PostgreSQL 17, which connected, ran a query and cancelled one, and against PostgreSQL 16, which refused, as it should. The error then says the option needs version 17.

Dump Database does not work with users containing a special character (ö) DBeaver #42389

Age: opened 1 week ago (October 13, 2026). No vendor reply yet.

Reactions / comments: 0 / 0.

The vibe: admin_björn goes in and admin_bj comes out the other side, cut off right where the "ö" was, and the server says Access Denied. It's a user name losing half of itself somewhere between the app and mysqldump.

Credit: @VersatyleBjorn reported it with the full command line and log.

SQLly: we took this one personally. On Windows, MySQL's tools read their command line in the old ANSI code page, and SQLly also put the user name on the command line. We couldn't reproduce it on a Mac, but there was no reason to wait for a Björn of our own. The user name now goes in the same UTF-8 settings file as the password, which mysqldump reads byte for byte.

Saving changes on SSH connection favorite with both MySQL and SSH changes does not save change in SSH password Sequel Ace #2077

Age: opened 2 years, 1 month ago (August 23, 2024). No vendor reply, ever. Labelled PR Welcome.

Reactions / comments: 0 / 0.

The vibe: change the database password and the SSH password together, press Test (it works, thanks to the new SSH password), then Save. Next launch, the SSH password is back to the old one. The reporter called the Test-then-Save flow a "great feature", which makes it sting a bit more. It's been waiting for a pull request for over two years.

Credit: @lostminds reported it with careful steps.

SQLly: checked, not a problem we have. One Save stores the database password, the SSH password or key passphrase, and the proxy password together in your system keychain.

SSH Password needs to be entered every time Sequel Ace #2266

Age: opened 1 year, 3 months ago (June 30, 2025). No vendor reply, ever.

Reactions / comments: 0 / 0.

The vibe: saved in the keychain, asked for again on every reconnect, on two different Macs, even after clearing and re-saving the keychain entries. The reporter did all the obvious troubleshooting before posting, and nobody has replied in fifteen months.

Credit: @benique reported it.

SQLly: checked, not a problem we have. A saved SSH password is read back from the keychain on every connect and reconnect.

Cleartext authentication plugin can be enabled without requiring TLS Sequel Ace #2681

Age: opened 1 month ago (September 17, 2026). Last vendor reply: 17 days ago.

Reactions / comments: 0 / 2.

The vibe: a careful security report from someone who also sent the fix: if cleartext sign-in is on and TLS is off, anyone on the network can ask for your password. The project is working through it in public, one pull request at a time. This one is a model of how it should go.

Credit: @neeo reported it and opened the fix. @Jason-Morcos (Sequel Ace) followed up on certificate checks.

SQLly: checked, not a problem we have. SQLly never sent a cleartext password without TLS. The new PAM and LDAP sign-in (see the Beekeeper and DbGate issues below) goes further: it only sends the password once the server's certificate has been verified, so Require (encrypted but unverified) isn't enough either.

SSH config Include does not resolve paths starting with ~ Sequel Ace #2744

Age: opened 13 days ago (October 7, 2026). No vendor reply yet. Labelled PR Welcome.

Reactions / comments: 0 / 0.

The vibe: ~ works in IdentityFile but not in Include, so hosts kept in ~/.ssh/conf.d/ disappear. A tidy report that rules out the usual sandbox suspects first.

Credit: @stimlocy reported it.

SQLly: we had a worse version. Our SSH host picker skipped Include lines entirely, ~ or not. Fixed today: it follows includes the way ssh does, including ~, paths relative to ~/.ssh, and wildcards like conf.d/*.conf.

Cannot connect to MySQL - enableCleartextPlugin option missing Beekeeper Studio #4778

Age: opened 28 days ago (September 22, 2026). Answered the same day by a Beekeeper contributor, fixed a week later, and confirmed working by the reporter. Still open.

Reactions / comments: 0 / 5.

The vibe: a driver update quietly switched off cleartext sign-in, and MySQL accounts that use it stopped connecting. This one went well: a same-day reply, a checkbox shipped in 6.1.3, and the reporter's "Thanx a lot". The only thing left is to close the issue.

Credit: @Pochwar reported it and confirmed the fix. @not-night-but diagnosed it and shipped the fix.

SQLly: we had this. SQLly turned cleartext sign-in on only for AWS and Google Cloud IAM, so a PAM or LDAP account couldn't get in. Fixed today, with no checkbox to remember: the password is sent only when TLS verifies the server's certificate (Verify CA or Verify full, the default). With anything weaker, the error tells you which setting to change.

Backup/restore binary tool path (mysqldump, pg_dump, etc.) not persisted between sessions Beekeeper Studio #4706

Age: opened 1 month, 20 days ago (August 31, 2026). Answered two days later by a Beekeeper contributor, who called it a feature request.

Reactions / comments: 0 / 1.

The vibe: browse to pg_dump again, every time you back up. The reporter even pointed at the setter that keeps the path for one session and forgets it at the next. The reply was that they don't save any backup or restore settings between runs, which at least is consistent.

Credit: @JeanPaiva42 reported it. @not-night-but replied.

SQLly: we already have this. SQLly finds pg_dump, mysqldump and friends on its own, and a path you set under Tools ▸ Options ▸ Advanced ▸ Database tools is saved.

MySQL cleartext auth (RDS IAM / PAM / LDAP) broken by mysql2 >= 3.22.0 — no way to set enableCleartextPlugin DbGate #1544

Age: opened 2 months ago (August 20, 2026). No vendor reply, ever.

Reactions / comments: 2 / 0.

The vibe: the same driver change as the Beekeeper issue above, reported a month earlier, with the upstream commit, the error code, and links to the exact lines that need one more option. Beekeeper shipped its fix in a week. This one has had two thumbs up in two months and no reply.

Credit: @oribb23 reported it.

SQLly: same story as the Beekeeper issue. AWS RDS IAM always worked in SQLly (it sends the token over TLS). PAM and LDAP accounts now work too, whenever TLS verifies the server.

Launching with restored sessions that are unreachable causes failure to open at all HeidiSQL #2604

Age: opened 28 days ago (September 22, 2026). No vendor reply yet. Labelled bug.

Reactions / comments: 0 / 0.

The vibe: four saved sessions behind SSH tunnels, all offline, so you open HeidiSQL five times: one error and quit for each dead session, then finally a window. It's a whack-a-mole start-up.

Credit: @EkriirkE reported it.

SQLly: checked, not a problem we have. A restored workspace opens disconnected until you choose Connect, and a server that can't be reached shows an error in the status bar, not a goodbye.

After Re-opening the app, connection password is lost so you need everytime to write password manually Azure Data Studio #26444

Age: opened 11 months, 4 weeks ago (October 23, 2025). No vendor reply, ever.

Reactions / comments: 0 / 0.

The vibe: "Remember Password" stays ticked, but the password doesn't come back. The screenshot shows the checkbox ticked over an empty password field. This one turns one year old on Friday.

Credit: @MihailDamian reported it.

SQLly: checked, not a problem we have. Saved passwords live in your system keychain (on Linux, the desktop's secret service) and are read back after a restart. If one is missing, SQLly tells you rather than signing in with a blank password.

What changed in SQLly today

  • SSH host picker reads included config files, with ~, paths relative to ~/.ssh, and wildcards.
  • MySQL accounts that sign in through PAM or LDAP can connect, sending the password only when TLS verifies the server (Verify CA or Verify full, the default).
  • MySQL backups and restores keep non-English user names intact on Windows.
  • Direct TLS for PostgreSQL 17, for databases behind a TLS proxy. See TLS settings.