Competitor watch: big values and binary keys

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 big values and binary keys. I loaded thirty rows of 2.5 MB text and 20 KB blobs into one result, and built a SQLite schema keyed by 16-byte UUIDs with a foreign key between two tables, then tried each report against them. Ages are as of October 21, 2026. "Vendor" means someone the tracker marks as a member, collaborator or staff.

The twelve issues

Select-Statement on Table with Varbinary-Column crashes app HeidiSQL #2441

Age: opened 7 months ago (March 25, 2026). The one vendor reply came the same day, 209 days ago.

Reactions / comments: 0 / 1.

The vibe: a table of 1,110 rows with a logo image in a VARBINARY column. Leave the logo out and everything is fine. Select it and HeidiSQL sits on "sort rows" until the task manager gets involved, sometimes with an access violation for company. The reply was a shrug in sentence form: "Probably due to a large size of that blob column in the table, not sure." That was seven months ago, and nobody has been more sure since.

Credit: @soenkematz reported it with screenshots. @ansgarbecker replied.

SQLly: checked, not a problem we have. SQLly cuts any cell over 8 KiB down to a preview before it reaches the grid, and shows a binary value as its size (<8192 bytes> … [19.5 KiB]) rather than trying to draw it. The full value is read only when you ask for it. Our test query of thirty 20 KB blobs alongside thirty 2.5 MB texts finished in 0.03 s, and the grid never blinked. (changelog)

column LONGBLOB makes app not responsive HeidiSQL #2408

Age: opened 8 months ago (February 16, 2026). The vendor reproduced it on February 20, 242 days ago, and the thread has been quiet since.

Reactions / comments: 0 / 6.

The vibe: ten rows, two LONGBLOB columns, 20 KB per file. Small. The vendor got the sample data, reproduced it, and worked out the trigger: it only happens when binary columns are shown as text. The reporter's workaround is to keep looking at hex, and they were gracious about it. "Reproduced, nearly understood, still open" is a very specific kind of limbo.

Credit: @chiccomotta reported it, answered every question, and sent sample data. @ansgarbecker reproduced it.

SQLly: checked, not a problem we have. The same 8 KiB preview rule applies whatever the display, and a full value is fetched only when opened, up to a 32 MiB viewer limit. (changelog)

Application hangs when longtext field window is filled with more than about 650 characters HeidiSQL #2388

Age: opened 8 months ago (February 1, 2026). Last vendor reply 242 days ago.

Reactions / comments: 0 / 7.

The vibe: a crash at a suspiciously specific 650 characters, which the vendor remembered seeing in another report but couldn't find. A preview build, a new build with the syntax highlighter switched off for big cells, and then the reporter's last word: open a field with more than 15,000 characters and it still hangs. That was February. The 650-character mystery has been unsolved for longer than some sitcoms run.

Credit: @Chnutz reported it, tested two builds on a Sunday, and came back with the 15,000-character result. @ansgarbecker shipped the highlighter change.

SQLly: checked, not a problem we have in the grid: long text stays responsive because only an 8 KiB preview is ever drawn, which we confirmed with 2.5 MB values. (changelog)

ERROR TRYING TO EDIT LONGTEXT FIELDS HeidiSQL #2481

Age: opened 5 months ago (May 14, 2026). Last vendor reply 153 days ago.

Reactions / comments: 0 / 4.

The vibe: a 2.5 MB LONGTEXT that wouldn't open for editing, then wouldn't save. The reporter spotted an apostrophe in the text and suspected it. The vendor imported the exact table on MySQL 9.6 and could edit it fine. Everyone was very polite, and the issue stays open, as issues do.

Credit: @trthiagorafael reported it and found the apostrophe. @ansgarbecker tried it on MySQL 9.6.

SQLly: checked, not a problem we have. SQLly saves an edited value as a bound parameter, never by pasting it into the SQL text, so an apostrophe (or a thousand of them) cannot break the statement. (changelog)

Unable to filter by UUID on binary UUID field with a format override Sequel Ace #2068

Age: opened 2 years, 2 months ago (August 14, 2024). Last vendor reply 796 days ago, the day after it was opened.

Reactions / comments: 0 / 4.

The vibe: UUIDs stored as BINARY(16), shown nicely as UUIDs thanks to a format override, and then the filter finds nothing because it searches for the text, not the bytes. A contributor wrote up a careful hex workaround (no hyphens, please). It's now old enough to have been to two summer camps.

Credit: @mmplanet reported it. @luis- explained the cause and posted the workaround. @vuon9 offered to look, and @Jason-Morcos asked who'd take it.

SQLly: we had a version of this, and it's fixed today. Right-click a binary cell, pick "Add WHERE column = …", and SQLly wrote its own <16 bytes> label into the query as a string on PostgreSQL and SQLite, and quietly did nothing on SQL Server and MySQL. Our grid quick filter matched every 16-byte value at once, since they all display the same. Now the predicate compares the real bytes as the database's own hex literal (0x…, X'…', '\x…'). We checked it in the app on a SQLite table keyed by UUIDs, and it returned exactly the right two orders. (commit c8340bfc, changelog)

Following a UUID foreign key breaks filter Sequel Ace #2361

Age: opened 7 months ago (March 9, 2026), closed, then reopened. Last vendor reply 34 days ago.

Reactions / comments: 0 / 4.

The vibe: click the little arrow to follow a UUID foreign key and land on an empty table. A fix was announced for 6.0.0. The reporter installed the 6.0.0 beta that same afternoon and reported, with a screenshot, that it still happens. A month on, the arrow still points nowhere.

Credit: @Eligioo reported it, asked for the reopen, and tested the beta. @Kaspik pointed to 6.0.0.

SQLly: we had it, and then some. Open Referenced Row on a binary foreign key said "Cannot follow a NULL foreign-key value", about a value that very much wasn't NULL. Fixing that and trying it in the app turned up a worse one: on every engine that limits rows with LIMIT (PostgreSQL, MySQL, MariaDB, SQLite and friends), the generated query put WHERE after LIMIT, which is a syntax error, so following any foreign key failed there. Both are fixed. In the app, order 3 now opens user 2, with WHERE "id" = X'11EE0A…02' LIMIT 1. (commit c8340bfc, changelog)

Support for ULID Handling in Binary Fields with Format Override Sequel Ace #2148

Age: opened 1 year, 10 months ago (December 24, 2024). No vendor reply, ever.

Reactions / comments: 0 / 2.

The vibe: a Christmas Eve feature request. A contributor got the display working and then hit the hard part: filtering on a ULID prefix, which is base32 and doesn't line up with byte boundaries. The reporter followed up with a proper range-query design. The maintainers have not weighed in.

Credit: @pich asked for it and sketched the range-query fix. @luis- built the display part.

SQLly: a feature request we don't have yet: SQLly shows binary keys as their size, or as hex or Base64 on request, but not as UUID or ULID text. It's on our list for a yes or no.

FEAT: Export cell value to file (binary/blob columns) Beekeeper Studio #4655

Age: opened 2 months ago (August 17, 2026). No replies at all.

Reactions / comments: 0 / 0.

The vibe: a contributor wrote the whole feature request: the menu item, the save dialog, and a tour of which helpers already exist in the codebase. It's practically a pull request in prose, and it's been sitting for two months in total silence.

Credit: @JeanPaiva42 wrote it up.

SQLly: we already have this. Right-click a binary cell and choose Save to file… (and Load from file… goes the other way). (changelog)

Feature request: option to decode VARBINARY/BLOB columns as UTF-8 text Beekeeper Studio #4641

Age: opened 2 months ago (August 14, 2026). No replies.

Reactions / comments: 1 / 0.

The vibe: text stored in a VARBINARY column for storage reasons, and the only way to read it is to wrap every query in CONVERT(). The request offers three ways to solve it, from a config value to a per-column override. One thumbs-up, zero words back.

Credit: @nuntid15723 asked for it.

SQLly: partly. The value viewer can already show one binary cell as UTF-8 text, but there's no column-wide "show as text" option in the grid yet. That's a feature request waiting on a yes or no from us.

Out of memory on table select DBeaver #42274

Age: opened 3 weeks ago (October 1, 2026). Last vendor reply 12 days ago, asking how big the table is.

Reactions / comments: 0 / 2.

The vibe: double-click any PostgreSQL table and DBeaver runs out of Java heap, while other clients open the same tables fine. The reply asked for the table size and a diagnostic bundle. Still waiting on the answer, which might be "big".

Credit: @fid9 reported it with the stack traces. @SolovevAnton asked for the details, and @davestokes said thanks.

SQLly: checked, not a problem we have. Each result set keeps at most 64 MiB in memory by default (adjustable in Settings), and anything past that goes to a file on disk that the grid pages through. Big cells arrive as 8 KiB previews either way. (changelog)

Add Text Wrapping Feature for Cells with Long Text or JSON objects DBeaver #42336

Age: opened 2 weeks ago (October 7, 2026). No vendor reply yet.

Reactions / comments: 0 / 1.

The vibe: short and reasonable: cells full of paragraphs and JSON are hard to read on one line. The reply asks people to vote it up.

Credit: @milo-ap asked for it. @davestokes asked for votes.

SQLly: we already have this, in the Cell Details panel (the "Toggle Cell Details Panel" command). It follows the selected cell and shows the whole value: long text in full, JSON and XML as a tree. (changelog)

Hash field values with leading zeros (e.g. "00014") are stripped/displayed as numbers in Browser view Redis Insight #6269

Age: opened 3 months ago (July 23, 2026). No vendor reply on the tracker's terms; a contributor answered the same day.

Reactions / comments: 2 / 1.

The vibe: a product code "00014" shows up as 14. The answer: that's the JSON formatter doing its job, and switching back to Unicode shows it as stored. The same reply admits the real danger, that editing in JSON mode could save 14 back over 00014, and promises a fix. Three months later, the promised follow-up hasn't appeared.

Credit: @Kaushal672 reported it with a clean repro. @pawelangelow explained the formatter and confirmed the editing bug.

SQLly: checked, not a problem we have. SQLly shows Redis values byte for byte, and if you pick the JSON format for "00014" it keeps the text as written with a note, because leading zeros aren't valid JSON. We added a test so it stays that way. (changelog)

What changes in SQLly

Binary key values now work with the results grid's filter actions: "Add WHERE column = value" compares the real bytes as the database's own hex literal, a value shown only as a preview offers just the NULL tests, and Open Referenced Row follows binary foreign keys and builds valid SQL on every engine that uses LIMIT or FETCH FIRST. The details are in the changelog.