SQLlyCompetitor watch: fonts you can actually read
12 open font and display issues from five SQL clients, checked against SQLly: stuck sizes, blurry grids, light boxes in dark mode. Two were ours, fixed.
You picked a font, a size, and dark mode, and then one corner of the app ignored all three. So I read twelve open issues from Sequel Ace, HeidiSQL, DbGate, Redis Insight and DBeaver about fonts and display, and checked every one against SQLly.
SQLly had two of these bugs, both fixed today and shipping in the next release (changelog). One was a little embarrassing: a few panes asked for a font called "monospace", which no Mac has, so the SQL in them quietly rendered in Helvetica. Eight I checked and SQLly doesn't have, and two it already had.
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 fonts, sizes, and text you can actually read: settings that don't stick, layouts that come apart at a bigger size, blurry grids, and numbers that won't line up. It felt right for the day SQLly switched its default editor font to JetBrains Mono. 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
Incorrect font in procedure/function-window Sequel Ace #2125
Age: opened 1 year, 11 months ago (November 1, 2024). No vendor reply, ever. Labelled "PR Welcome" and "Low priority".
Reactions / comments: 0 / 0.
The vibe: you choose a font for your SQL, then right-click a procedure, open its CREATE syntax, and get the system font anyway. A precise report with numbered steps, plus a fair side request for a button to go back to the default font. Nobody has said a word in almost two years, which at least means nobody has disagreed.
Credit: @offvalley reported it.
SQLly: we had this one too, now fixed. SQLly's DDL viewer already used the editor font, but the Preview SQL tab (the SQL for staged row edits), command-line tool output, and two smaller panes asked for a family named "monospace". No system has a font by that name, so the text fell back to Helvetica on macOS. They now use the editor font you picked, and a test fails the build if a generic family name comes back. (commit 7754617c)
Use font settings for table content filter controls Sequel Ace #2280
Age: opened 1 year, 2 months ago (August 6, 2025). No vendor reply. Labelled "PR Welcome" and "Low priority".
Reactions / comments: 0 / 0.
The vibe: two sentences, both right. The filter controls are stuck in very small type, the font setting doesn't reach them, and Query Favorites and Query History have the same problem. The kind of report you only write after squinting for a while.
Credit: @jordanade reported it.
SQLly: we had a version of this, now fixed. SQLly's filter bar and query history already follow the interface font size, but the messages, empty states, and errors in the Redis views, the labels and headline on the Welcome page, and the device pairing code were pinned to one size. They now grow with the interface font, and look the same as before at the default size. A test now fails the build on fixed-size text unless it is a glyph drawn to fit a fixed box. (commit a7057035)
Tabular Figures for numbers Sequel Ace #2363
Age: opened 7 months ago (March 12, 2026). No vendor reply. Labelled "PR Welcome".
Reactions / comments: 0 / 0.
The vibe: a typographer's request, and a good one: turn on the font's tabular figures so that a column of numbers lines up digit by digit. The screenshot of wobbly numbers makes the case by itself.
Credit: @jojomi asked for it.
SQLly: we checked, and SQLly doesn't have this problem. The results grid uses the platform monospace by default (Menlo, Consolas, or DejaVu Sans Mono), where every digit has the same width, and numeric columns are right-aligned, so the ones line up under the ones. (changelog)
SQL are displayed in light mode despite using dark mode in the app Sequel Ace #2100
Age: opened 2 years, 1 month ago (September 25, 2024). Last vendor reply 2 years ago, linking an older issue.
Reactions / comments: 2 / 1.
The vibe: dark mode on, and the two SQL boxes in Table Info and Query stay bright white. The maintainer linked it to #145, which means the light boxes have been a known issue for even longer than this report. Two thumbs up have been waiting with their sunglasses on since 2024.
Credit: @bubokko reported it. @Jason-Morcos linked the related issue.
SQLly: we checked, and SQLly doesn't have this problem. Every SQL editor and viewer is drawn from the active theme, in all 24 light and dark themes, and a test checks each theme's text against its backgrounds for readable contrast. (changelog)
Content views display ENUM types with a top alignment vs middle Sequel Ace #2201
Age: opened 1 year, 7 months ago (March 20, 2025), and reopened. Last vendor reply 17 months ago.
Reactions / comments: 1 / 2.
The vibe: ENUM cells sit at the top of the row while the integers and strings beside them sit in the middle, and the whole grid feels squashed since version 5. The maintainer explained it wasn't on purpose: dropping old macOS versions changed Apple's default look. The reporter just misses the clean, centered rows.
Credit: @salvor-hardin reported it. @Jason-Morcos explained the cause and pointed to a pull request comment.
SQLly: we checked, and SQLly doesn't have this problem. The grid draws every cell through one text path that centers it vertically, whatever the column type, so an ENUM sits on the same line as its neighbors. (changelog)
GUI font size not applied on Linux (Qt6 build) despite correct settings.json values HeidiSQL #2588
Age: opened 7 weeks ago (August 31, 2026). No vendor reply.
Reactions / comments: 0 / 0.
The vibe: set a font, save, kill the process, start again: same old font. The settings file has the right values, so the setting saves but never gets applied. A tidy report that even checked the JSON.
Credit: @WilRoales reported it.
SQLly: we checked, and SQLly doesn't have this problem. The saved interface, editor, and results fonts are applied at startup, before the first window is drawn, and a test covers reading them back. (changelog)
Layout falls apart once GUI font is not 10pt HeidiSQL #2580
Age: opened 2 months ago (August 18, 2026). Last vendor reply 57 days ago. Labelled "needs-info".
Reactions / comments: 0 / 5.
The vibe: switch the GUI font from 10 to 14 and the preferences dialog falls over itself. The maintainer was candid: the font-size option is "a dumb thing" he'd like to remove, and Windows display scaling is the supported route. The reporter's answer, that he doesn't want to scale his whole OS for one app, is fair too. Both are right, which is why it's still open.
Credit: @alesvaupotic reported it and explained why OS scaling isn't the answer for him. @ansgarbecker replied and showed the 150% DPI result.
SQLly: we checked, and SQLly doesn't have this problem. Rows, tab strips, toolbars, the status bar, and controls take their height from the interface font, so raising it to 14 or 24 grows them instead of clipping the text. A bigger font without scaling the whole OS is exactly what that setting is for. (changelog)
High DPI issues in trees and statusbar HeidiSQL #2413
Age: opened 8 months ago (February 19, 2026), by the maintainer himself. No replies since; three to-do boxes unchecked.
Reactions / comments: 0 / 0.
The vibe: credit where it's due: this is the vendor filing his own bug, with a clear list. Tree fonts are the wrong size at 125%, the status bar is too short, and sizes keep growing as the window moves between monitors. The to-do list has been waiting eight months for its first tick.
Credit: @ansgarbecker filed it.
SQLly: we checked, and SQLly doesn't have this problem. Everything is laid out in points and redrawn at each display's scale, and when a window moves to a screen with a different scale it is redrawn at the new one, on macOS, Windows, and Linux. (changelog)
Blurry text in the data area on Linux KDE HeidiSQL #2507
Age: opened 4 months ago (June 10, 2026). Last vendor reply 93 days ago. Labelled "needs-help".
Reactions / comments: 1 / 5.
The vibe: sharp text everywhere except the data grid, which is blurry at 140% on KDE. The reporter ran every test the maintainer suggested (no luck at 200% either), and a second user found that the blur goes away under XWayland. The maintainer thanked them and said it is probably something deeper. The "needs-help" label is honest.
Credit: @ansnap reported it and ran the tests. @h8hr1pzdo3rmiqv5 found the XWayland workaround. @ansgarbecker suggested what to test.
SQLly: we checked, and SQLly doesn't have this problem. The results grid draws its text through the same renderer as the rest of the window, at the display's exact scale, including fractional scales on Wayland, so the grid can't be blurrier than the sidebar next to it. (changelog)
FEAT: Change data grid font DbGate #1356
Age: opened 8 months ago (February 12, 2026). Last vendor reply 247 days ago, asking why zoom isn't enough.
Reactions / comments: 0 / 4.
The vibe: zoom makes everything bigger, but people want their data in a monospace font while the rest of the app stays as it is. Three people turned up to say so, one adding that toggles for booleans would be lovely too. The question was answered in February; the feature is still waiting.
Credit: @fredericoregateiro asked for it and explained the use case. @marqu3s wants monospace too. @fbnlsr was surprised it wasn't there. @Stelinkaa asked about zoom.
SQLly: we already have this. Settings → Appearance → Display → Results Font sets the family and size for grids, pivots, and charts on their own, and the default is already the platform monospace. (changelog)
Redis Insight: Configurable/Monospaced font when viewing/editing keys/values Redis Insight #4896
Age: opened 1 year, 2 months ago (August 26, 2025). Last vendor reply 255 days ago: "Noted ✍️".
Reactions / comments: 0 / 5.
The vibe: only the JSON view gets a monospace font, so everything else looks like a word processor. In February a stale-issue sweep asked whether it still mattered, the reporter said yes, and the vendor noted it. Someone added #FreeMonospace, which we fully support as a movement.
Credit: @ddeml asked for it and confirmed it's still wanted. @captchaly asked how it isn't mono already. @zidokobik started the hashtag. @DimoHG ran the sweep.
SQLly: we already have this. Redis values show in the results grid, which uses the platform monospace by default and follows the Results Font setting, and the value detail and command panes use your editor font. #FreeMonospace, achieved. (changelog)
Can't change color on SQL in Data panel DBeaver #42324
Age: opened 2 weeks ago (October 7, 2026). A reply from DBeaver came the same day: thanks for the report.
Reactions / comments: 1 / 1.
The vibe: the SQL line in the data panel is green, and in dark mode that green is hard to read, with no color setting to fix it. The reporter even wrote the implementation note: add a color key. It's tagged "trivial", which is either very encouraging or very ominous.
Credit: @winternet-studio reported it. @davestokes thanked them.
SQLly: we checked, and SQLly doesn't have this problem. SQLly marks the statement behind a result with a faint wash behind the normal syntax colors rather than recoloring the text, and a test checks that line for readable contrast in all 24 themes. (changelog)
The score
Twelve issues: two font bugs fixed, eight already fine, two already built. Both fixes come with tests that fail the build if the problem comes back: one rejects generic font names like "monospace", and one rejects text pinned to a fixed size unless it is a glyph drawn to fit a fixed box. And #FreeMonospace has been adopted as house policy.