SQLlyCompetitor watch: crashes and freezes
12 open crash and freeze reports from six SQL clients, checked against SQLly: launch hangs, frozen grids, tab crashes, and one latent crash of ours, fixed.
Today's theme is the one every database tool dreads: the app simply stops. Twelve open issues across six competitors where the client hangs, freezes, or falls over outright β opening a table, switching a Redis database, deleting a row, or just sitting there with a few tabs open. I read every one and checked whether SQLly has the same problem.
Mostly the answer was no, with the code to prove it. But one report β DbGate's stack overflow rendering a Redis database β sent me looking at our own structured-data viewer, and there it was: the same bug class, latent in our XML tree builder. It's fixed today (changelog).
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. Ages are as of October 22, 2026. "Vendor" means someone the tracker marks as a member, collaborator or staff.
The twelve issues
June 2025 1.52.0 update hangs on Ubuntu 24-04 Azure Data Studio #26436
Age: opened 1 year ago (October 14, 2025). No vendor reply, ever.
Reactions / comments: 0 / 0.
The vibe: install the June 2025 update on Ubuntu 24.04, launch, nothing. A year later the issue sits exactly where it was filed, presumably still hanging.
Credit: @Clifra-Jones filed it and waited.
SQLly: not applicable. SQLly is a native Rust application, not an Electron bundle with an auto-updater β there is no embedded Chromium runtime to wedge between the update and the first window.
App freezed in a postgres table when view data Beekeeper #4673
Age: opened 2 months ago (August 20, 2026). Contributor replied the same day; nothing since the logs arrived.
Reactions / comments: 0 / 2.
The vibe: one particular postgres table freezes the whole app on macOS every time β even when the table is empty β while every other table behaves. The reporter delivered debug logs within hours of being asked, two months ago. The logs are presumably still being read.
Credit: @TrungRueta reported it and sent the logs; @not-night-but asked for them.
SQLly: checked, not affected. Browsing a table in SQLly is a plain paginated query rendered by the virtualized grid β per-frame work is bounded by the rows on screen, never by the table's contents.
Opening SQLEditor crashes dbeaver DBeaver #42323
Age: opened 16 days ago (October 7, 2026). No vendor reply.
Reactions / comments: 2 / 6.
The vibe: open an SQL editor or console on Windows 11 and the whole IDE dies to java.lang.NoClassDefFoundError: Could not initialize class java.lang.management.ManagementFactory β a broken Java runtime underneath the workbench. When your SQL editor can be assassinated by a class-loading error, the editor is not the problem.
Credit: @ironbirdie posted the stack, @ducnguyen1909 hit the same wall, and @davestokes asked for log files.
SQLly: not applicable. There is no JVM under SQLly and no OSGi classloader; the editor is the same native code as the rest of the app.
Freeze in slow per-cell editor rendering in EditorTextFieldCellRenderer.paintChildren on DB result grid DataGrip DBE-26735
Age: opened about 3 months ago (July 29, 2026). JetBrains is actively investigating.
Reactions / comments: 102 automated freeze reports from 49 users.
The vibe: the IDE locks up painting the result grid's per-cell editors across DataGrip, GoLand, IDEA, PhpStorm and PyCharm. One patient user reproduced it with a synthetic CSV on two Macs and narrowed it to an external display, where the prime suspect turned out to be the JetBrains Runtime's own Metal flush (JBR-10638). Credit where due: this one is being hunted properly.
Credit: konstantin.hudyakov filed the report; Artur.Wronski did the heroic reproduction work; vladislav.protasov is running the investigation.
SQLly: checked, not affected. SQLly's grid paints cell text directly and only ever opens an editor for the one cell being edited β no per-cell embedded components, and no vendored runtime between the app and the GPU.
BUG: Dbgate crashed of redis(Maximum call stack size exceeded) DbGate #1256
Age: opened 11 months ago (November 13, 2025). No vendor reply, ever.
Reactions / comments: 0 / 0.
The vibe: two Redis databases, both connections fine β but switching to one of them crashes DbGate outright with a stack-overflow error. Data-dependent, reproducible, and fine in Tiny RDM. Eleven months later nobody has asked which data.
Credit: @wqk151 is still waiting.
SQLly: we had the bug class β fixed today. Checking this one, we found SQLly's XML tree builder recursed per nesting level with no depth cap, so a deeply nested XML value opened in Cell Details could overflow the stack the same way. The parser now refuses documents nested deeper than 256 levels and the viewer falls back to formatted text; JSON was already protected by its parser's own nesting limit, now pinned by a test. See the changelog.
Crasheo HeidiSQL #2602
Age: opened 1 month ago (September 18, 2026). No vendor reply, ever.
Reactions / comments: 0 / 0.
The vibe: create a simple table β SERIAL, VARCHAR, DATE β on an M3 Mac, click into it, crash. The whole report is three lines, and frankly the title says everything the body does.
Credit: @Igomez-97 kept it brief.
SQLly: checked, not affected. Creating a table in SQLly's structure editor and then browsing it runs the same engine-tested query path as any other table browse.
HeidiSQL crashes unexpectedly when performing record operations on a table (double-clicking or deleting a row) HeidiSQL #2500
Age: opened nearly 5 months ago (June 2, 2026). Vendor replied once, 3 months ago.
Reactions / comments: 0 / 1.
The vibe: double-click or delete a row in a PostgreSQL 16 table on an M2 Mac and HeidiSQL 12.17 can just die. The maintainer suggested checking the next release, which is the maintainer equivalent of "call me after the weekend."
Credit: @essuner reported it; @ansgarbecker proposed re-testing on v12.21.
SQLly: checked, not affected. Double-clicking a row in SQLly opens the row editor, and Delete only marks a staged deletion that you review before anything is saved β both covered by tests.
Firebird 2.5: SELECT on specific table causes FireDAC timeout and HeidiSQL crash HeidiSQL #2492
Age: opened nearly 5 months ago (May 27, 2026). No vendor reply, ever.
Reactions / comments: 0 / 0.
The vibe: Firebird 2.5 through the experimental driver: most tables browse happily, then select * from clientes gets a FireDAC timeout followed by a crash. One specific table, every time.
Credit: @pillareck named the table.
SQLly: not applicable. SQLly does not speak Firebird, so this particular dragon lives outside our map entirely.
Crash when creating/editing a table while having Cod CREATE as active tab HeidiSQL #2432
Age: opened 7 months ago (March 18, 2026). Vendor replied five times, last 5 months ago.
Reactions / comments: 0 / 10.
The vibe: crash while creating or editing a table with its CREATE-code tab active. The reporter kept refining the reproduction as the maintainer tried and failed to reproduce it, eventually earning the honest shrug: "I cannot fix things which I cannot reproduce." The crash remains unreproduced by anyone except its discoverer.
Credit: @CraftedRO refined the recipe four times; @ansgarbecker said the quiet part out loud.
SQLly: checked, not affected. SQLly's DDL viewer is read-only and the structure editor is a form β there is no live CREATE-code tab whose state can tangle with an edit in progress.
[Bug]: UI flickers when opening the side menu after changing the language Redis Insight #6480
Age: opened about 7 weeks ago (September 3, 2026). No vendor reply, ever.
Reactions / comments: 0 / 0.
The vibe: change the application language, open the side menu, and the entire UI flickers like a broken neon sign β helpfully captured on video, so nobody can say it didn't happen.
Credit: @Tasha1003Natasha brought receipts.
SQLly: not applicable. SQLly ships in a single language, so there is no language switch to flicker after β and the renderer paints complete frames rather than half-updated DOM trees.
Multiple tabs, different connections, crash Sequel Ace #2413
Age: opened 5 months ago (May 20, 2026). No vendor reply, ever.
Reactions / comments: 0 / 1.
The vibe: multiple tabs against different connections, crash. A commenter adds the telling detail: this has been around for five years or more, and running a query in one tab apparently tries to refresh the connection status of every other tab. Tabs sharing connection state is how one slow server takes down your whole afternoon.
Credit: @tiptronic85 reported it; @indreka explained it.
SQLly: checked, not affected. Every SQLly tab owns its own connection and engine session β a query in one tab never touches another tab's connection.
Open table in new tab crashes app Sequel Ace #2235
Age: opened 1 year, 6 months ago (May 2, 2025). No vendor reply, ever.
Reactions / comments: 0 / 2.
The vibe: "open table in new tab" crashed the app in 5.0.6, and when someone asked whether it was gone in 5.0.8/5.0.9, the answer came back: still there β a dead freeze requiring a trip to Activity Monitor. Old enough to walk, talk, and ask why nobody has answered it.
Credit: @stimpsonjcat filed it, @jsantos42 checked in, and @NickKirian confirmed it's still frozen.
SQLly: checked, not affected. Opening a table in SQLly is a paginated browse in an ordinary results tab β the standard flow exercised by the query-engine tests.
That's the batch: twelve open wounds, seven confirmed not ours, four that can't be ours, and one genuine catch β the XML depth fix β which made the whole exercise worth it before lunch. The issue pile shrinks; the ledger grows.