Competitor watch: connections that drop or hang

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. Today's batch is about connections: idle ones that die quietly, queries that can't be stopped, hosts macOS won't let you reach, and SSH tunnels that work right up until they ask you a question. I checked each one in the code and with tests against a real SSH server and a real SQL Server. Ages are as of October 21, 2026. "Vendor" means someone the tracker marks as a member, collaborator or staff, or whose profile names the vendor as their company.

The twelve issues

Database connection times out after idle period; SQL operations fail and app restart is required DBeaver #42373

Age: opened 9 days ago (October 12, 2026). A reply from DBeaver came the same day; the reporter's follow-up question has waited 7 days.

Reactions / comments: 0 / 2.

The vibe: open a table, walk away, come back, and every operation on that connection times out until you restart the whole app. The advice was to raise the connect timeout or the server's wait_timeout. The reporter asked, quite reasonably, where those settings live, preferably with screenshots. The issue is labelled "wait for response", which is true, just not in the direction the label means.

Credit: @BraveMomo reported it and asked the follow-up. @davestokes suggested the timeouts.

SQLly: we had a smaller version of this, now fixed. SQLly never needed a restart: kept connections are replaced after five idle minutes, and a query that fails before reaching the server is retried on a fresh connection. But a firewall or cloud load balancer that silently dropped an idle connection (some do it after four minutes) could leave the next query waiting on a dead socket until you pressed Cancel. SQL Server, PostgreSQL and MySQL connections now send a keepalive after a minute of quiet, so those idle drops don't happen, and a connection that really died is noticed within about 90 seconds. (commit f229d6cf)

Connection loss / utility crash is unrecoverable — RPC layer has no timeout and never rejects in-flight requests Beekeeper Studio #4739

Age: opened 6 weeks ago (September 9, 2026). Last vendor reply 35 days ago, asking the reporter to try a master build.

Reactions / comments: 0 / 2.

The vibe: this is the best-written bug report in today's batch. The connection dies, a request that will never be answered sits in a map forever, every "loading" flag is waiting for a finally that never runs, and the only way out is to close the window. The reporter lists nine older issues describing the symptoms and then finds the cause underneath them. The vendor jumped on it within two days ("I'm working on these issues :-)") and posted a build to test. The report has been waiting on that test ever since, so it is the most hopeful entry here.

Credit: @diogomrts reported it with file and line references. @rathboma took it on and posted a build.

SQLly: checked, not a problem we have. Cancel always ends a run on SQLly's side, even when the server never answers, and the run is shown as cancelled rather than left spinning. When SQLly talks to a remote engine through the bridge or relay, a dropped link fails the waiting request straight away, and every request has a deadline. (changelog)

EHOSTUNREACH on MacOS Golden Gate / OrbStack Beekeeper Studio #4774

Age: opened a month ago (September 19, 2026). Last vendor reply 28 days ago.

Reactions / comments: 0 / 2.

The vibe: MySQL in an OrbStack container answers the command line, answers the reporter's own app, and answers nc over IPv4 and IPv6. Beekeeper gets EHOSTUNREACH. The reporter found the workaround themselves: launch the app with a Node flag that tries IPv4 first. The vendor's two follow-ups were good questions, the second being whether macOS's Local Network permission is involved. That question is one we took home with us.

Credit: @crmr1 reported it with the dscacheutil and nc output and the workaround. @not-night-but asked about the address order and about Local Network access.

SQLly: checked, not a problem we have. SQLly tries each address a hostname resolves to, in turn, until one connects, so an unreachable IPv6 address falls through to IPv4 with no flags needed. The Local Network question led to the DataGrip fix below. (changelog)

refresh connection doesn't work - requires full shutdown and reopen application DbGate #1380

Age: opened 7 months ago (March 10, 2026). Last vendor reply 216 days ago.

Reactions / comments: 0 / 4.

The vibe: switch from wired to Wi-Fi, or let the VPN reconnect, and the refresh button stops doing anything. A second user leaves DbGate open for days over an SSH tunnel and finds the status bar still saying "Connected" above a table list that says the database is empty. The vendor pointed to "Reopen connection" in the status bar menu, which does work. "Connected" claiming to be connected while plainly not being connected has been the state of things since spring.

Credit: @ajboschee reported it and confirmed which menu item works. @turbo2ltr added the SSH tunnel case and the days-long one. @Stelinkaa suggested the status bar.

SQLly: the same fix as the DBeaver entry above. After a network switch, the first query in SQLly could wait on a kept connection that had died with the old network. Now a SQL Server connection that doesn't answer a quick check within 5 seconds is replaced on the spot, and keepalives find dead PostgreSQL and MySQL connections. SQLly's SSH tunnels already send their own keepalives and reconnect when the session drops. (commit f229d6cf)

Keeps connection open when explicitly closed, and then crashes HeidiSQL #2631

Age: opened 9 days ago (October 12, 2026). The vendor replied the same day; the reporter's crash log has waited 7 days.

Reactions / comments: 0 / 4.

The vibe: disconnect from a server, close the SSH tunnel it used, run a query on a different, local server, and HeidiSQL hangs. Restart it, and it reconnects to the server you explicitly disconnected, then fails. The vendor asked whether auto-reconnect was on (it was) and whether the reporter had waited 30 seconds (they waited minutes). The reporter came back with a crash log. Whether the hang belongs to that one server or to all of them is the open question, and the log is the next move.

Credit: @FlyveHest reported it, explained the expectation, waited it out and posted the crash log. @ansgarbecker asked the right first question.

SQLly: checked, not a problem we have. Disconnect in SQLly affects only that server; others keep their own connections. A workspace restored at launch stays disconnected until you choose Connect, so a server you left disconnected stays that way. Every connection attempt has a time limit, so an unreachable server produces an error rather than a hang. (changelog)

"No route to host" connecting to a Parallels VM (it worked fine for years) DataGrip DBE-22995

Age: opened 1 year, 7 months ago (March 12, 2025). One reply two days later asked for the IDE log; the log was attached the next day. Nothing since, for 585 days.

Reactions / comments: 0 votes / 2.

The vibe: a local VM that DataGrip reached for years stops answering after a macOS update, on two different Macs, while MySQL Workbench still connects fine. The reporter found DataGrip in Privacy & Security → Local Network with three sliders that "move together and do not help at all". The logs went in, and the issue has been quiet ever since.

Credit: wwinogrodzki reported it with screenshots and attached the logs. Aleksandr Molchanov asked for them.

SQLly: we had a version of this, now improved. On macOS 15 and later an app needs your permission to reach the local network, and when it is off every connection to a VM or container just says "No route to host", which SQLly also showed with no explanation. SQLly now tells macOS why it wants local network access, and that error now points you to System Settings → Privacy & Security → Local Network. We can't flip the switch for you, but we can stop pretending the network is broken. (commit f229d6cf)

SSH key confirmation causes crash Sequel Ace #2040

Age: opened 2 years, 3 months ago (July 11, 2024). No vendor reply, ever. Labelled "PR Welcome".

Reactions / comments: 0 / 0.

The vibe: delete a host key from known hosts, force a reconnect, and Sequel Ace asks you to confirm the key with a dialog you can see but cannot click. The reporter worked around it by turning off strict host key checking for that address, which is the sort of workaround that makes security people sigh. 832 days, zero comments: the issue isn't ignored so much as left in a drawer.

Credit: @mjaggard reported it with a screenshot and a precise recipe.

SQLly: we had this, and ours was worse, now fixed. SQLly's dialog did appear and could be clicked, but by then the tunnel behind it had already given up, so Trust saved nothing and the connection failed. This happened every time you connected to an SSH host SQLly had never seen, not just in an edge case. The answer now reaches the tunnel, and a test runs a real tunnel to a new host with the app's own prompt plumbing. Thank you, @mjaggard, for a report that found a bug in software you have never used. (commit 77a85669)

Unable to Stop Query Sequel Ace #2053

Age: opened 2 years, 2 months ago (July 29, 2024). No maintainer reply; a contributor tried to reproduce it 577 days ago.

Reactions / comments: 8 / 3.

The vibe: "Occasionally I am able to stop a query, but I'd say 95% of the time it fails." The button greys out, the query keeps running, and the reporter opens a terminal to KILL it by hand, as they have done since the Sequel Pro days. A helpful contributor couldn't reproduce it on a 690 MB table over SSH, then could, sort of, and then the thread went still. Eight people gave it a thumbs up and kept the terminal open.

Credit: @billynoah reported it and came back with the SSH details. @vuon9 tried to reproduce it twice.

SQLly: checked, not a problem we have. Cancel runs KILL QUERY for you from a separate connection through the same SSH tunnel, then ends the run in SQLly whether or not the server answers. A live test against MySQL checks that the kill stops a running statement. (changelog)

Can't connect to database using SSL through remote server Sequel Ace #2132

Age: opened 1 year, 11 months ago (November 13, 2024). Last vendor reply 698 days ago. Labelled "Need More Info" and "Low priority".

Reactions / comments: 0 / 4.

The vibe: a database reachable only from inside a server, which requires TLS, with the certificate files on that server. Sequel Ace only lets you pick local files, and copying the files to the laptop didn't work either. The maintainer suggested it isn't really a supported path and offered a manual tunnel; the reporter wasn't sure what that meant, and the thread ended there.

Credit: @pmpcabral reported it and tried editing an exported connection file. @Jason-Morcos replied twice.

SQLly: we had the part that bites after you copy the files over, now fixed. TLS is done on your machine, so local certificate files are the right model. But through an SSH tunnel, SQLly checked the server's certificate against the tunnel's local address, 127.0.0.1, instead of the server's name, so Verify full failed even with the correct certificate. SQL Server, PostgreSQL and MySQL now check the certificate against the server name in the connection editor. (commit f229d6cf)

Add a Disconnect Database Connection Feature Sequel Ace #2720

Age: opened 3 weeks ago (September 30, 2026). No vendor reply yet. Labelled "Low priority".

Reactions / comments: 0 / 0.

The vibe: staging servers that shut down at night, and a tab full of queries you want back in the morning. A tidy, specific request with a clear use case.

Credit: @fernandosoria asked for it.

SQLly: we already have this. Tools → Disconnect closes the connection, and Settings → Editor → Tabs → When disconnecting is set to "Keep tabs and results" by default, so the queries stay where you left them. (changelog)

add ssh jump server support please Sequel Ace #2321

Age: opened 9 months ago (January 5, 2026). No vendor reply. Labelled "PR Welcome" and "Low priority".

Reactions / comments: 0 / 3.

The vibe: one line of request, then a friendly stranger answered it better than any changelog could: put ProxyJump in ~/.ssh/config and it just works. The reporter said thanks, bro, and also that they would still like it built in.

Credit: @virskor asked for it. @kimegede posted the ssh config workaround and cheered when it worked.

SQLly: we already have this. The connection editor's SSH section has jump host fields, so no config file is needed. (changelog)

Add support for ssh authentication with combination of publickey and keyboard-interactive (MFA) Sequel Ace #2391

Age: opened 6 months ago (April 26, 2026). No maintainer reply; a contributor diagnosed it 146 days ago.

Reactions / comments: 0 / 1.

The vibe: public key plus a one-time code is how plenty of bastion hosts work now, and Sequel Ace's tunnel helper answers every prompt containing the word "password" with the stored password, MFA prompts included. A contributor found the exact line and explained what a fix would need.

Credit: @andreiaf asked for it. @eyupcanakman traced it to the askpass helper.

SQLly: we don't have this either. SQLly's SSH tunnels sign in with a password, a key file, or ssh-agent, but not with keyboard-interactive codes. It's on our list to decide on.

What changes in SQLly

Trusting a new SSH host now works: the dialog's answer reaches the tunnel, the key is saved, and the connection opens. SQL Server, PostgreSQL and MySQL connections send a keepalive after a minute of quiet, so firewalls and load balancers stop dropping idle ones, and a connection that died is replaced instead of hanging the next query. Through SSH tunnels and proxies, Verify full now checks the certificate against the server's name rather than 127.0.0.1. On macOS, SQLly says why it asks for local network access, and "No route to host" now points you to the Local Network setting. The details are in the changelog.