Competitor watch: connections, auth and SSL

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, or whose profile names the vendor as their company.

The twelve issues

macOS arm64 "Kerberos/Windows (ODBC) SQL Server auth error Beekeeper #4570

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

Reactions / comments: 0 / 0.

The vibe: a reporter doing the vendor's job for them: unixODBC installed, kinit run, valid ticket confirmed — and then he cracked the app bundle open and found the msnodesqlv8 native module simply isn't in the arm64 build, while every other native module is. A packaging omission, diagnosed down to the missing folder, filed in August, met with silence.

Credit: @SidToriggino reported it, root cause included.

SQLly: not applicable. SQLly is a compiled Rust binary with no Node native modules to forget, and on this build integrated/Kerberos auth is refused with a precise, actionable error rather than a missing-module crash — though honestly, if you need Kerberos on macOS, neither app gets you there today.

bug(snowflake): connection properties accumulate or fail on reconnect Chat2DB #2675

Age: opened 2 months ago (August 11, 2026).

Reactions / comments: 0 / 1.

The vibe: a contributor found that getConnection mutates the shared connection info, so reconnecting piles up properties or throws on immutable lists — and reproduced it with a capturing JDBC driver, no live service needed. A proper bug report. The only reply is from github-actions[bot], which at least read it before nobody did.

Credit: @HandSonic reported it.

SQLly: not applicable. SQLly has no Snowflake engine, so there's no shared connection-property bag to mutate.

DBeaver .dbp import aborts with BadPaddingException when credentials are encrypted with a non-default key Chat2DB #2631

Age: opened 2 months ago (August 6, 2026).

Reactions / comments: 0 / 1.

The vibe: set a master password in DBeaver, export the project, import it here: javax.crypto.BadPaddingException, and the whole import aborts. One unreadable credential file, total failure. The bot acknowledged it; no human has.

Credit: @tsonglew reported it.

SQLly: not applicable. SQLly's DBeaver import reads the workspace data-sources.json directly and never touches .dbp bundles or their encrypted credentials store — secrets in SQLly live in the OS keychain, so there's nothing to BadPadding.

Unable to change Master Password DBeaver #42282

Age: opened 3 weeks ago (October 1, 2026).

Reactions / comments: 0 / 7.

The vibe: change the master password in DBeaver EE and it keeps decrypting stored credentials with the old one. Then the runaround: support told him to file a website ticket, but his education license can't pick the Technical category, so he filed under Sales & General and said so, politely. The community manager is on the case now but can't reproduce it on his OS.

Credit: @tenbeh5 reported it and documented the ticket odyssey.

SQLly: checked — not affected. SQLly has no master password at all: connection secrets live in the OS keychain on macOS, Credential Manager on Windows, Secret Service on Linux, so there is no encrypted credentials file that a password change can strand.

Redshift IAM authentication fails through SSH tunnel DataGrip DBE-27152

Age: opened 5 weeks ago (September 17, 2026), after starting life as a community-forum post.

Reactions / comments: 4 comments.

The vibe: IAM auth to a private, provisioned Redshift cluster through a bastion fails with "To get cluster credentials, you must provide either the cluster identifier or the custom domain name". JetBrains replied on day 26, asked serverless-or-provisioned, got the answer, and opened an internal ticket — responsive by the standards of this list.

Credit: joefitz.1 reported it and uploaded repro logs on the issue.

SQLly: not applicable. SQLly has no Redshift engine, so its cluster-identifier derivation can't bite us; our AWS IAM support covers RDS PostgreSQL/MySQL — and, as of today, ElastiCache and MemoryDB too.

ClickHouse connection fails with 'Unknown and unmapped config properties: [sslmode]' when enabling 'Use SSL' DataGrip DBE-26742

Age: opened almost 3 months ago (July 29, 2026). No vendor reply.

Reactions / comments: 1 comment.

The vibe: tick "Use SSL" and the connection breaks outright, because the bundled ClickHouse JDBC v2 driver doesn't recognize the sslmode property the IDE insists on sending. The workaround is to untick the box and hand-write ?ssl=true in the URL — the checkbox is not just broken, it's a trap. A second user confirmed the 2026.2 upgrade "straight broke the CH integration" two months ago.

Credit: FeBe95 reported it with the workaround; sergeyivanychev confirmed on the issue.

SQLly: checked — not affected. In SQLly, TLS is a first-class connection mode, not a driver property we fumble: ClickHouse connections switch between HTTP and HTTPS from the profile, and the behavior is pinned by tests.

Cannot login with GSSAPI when group is used HeidiSQL #2626

Age: opened 13 days ago (October 9, 2026). No replies yet.

Reactions / comments: 0 / 0.

The vibe: map a MariaDB user to a Windows group (IDENTIFIED VIA gssapi AS 'GROUP:Administrators') and login fails — direct user mapping works, the group doesn't, and even mariadb.exe says no. A fiddly corner of Kerberos-on-MariaDB, freshly filed.

Credit: @chrpai reported it.

SQLly: not applicable. SQLly deliberately doesn't build the GSSAPI/Kerberos MySQL auth plugins — caching_sha2, mysql_native, sha256 and TLS client certificates only — so this code path doesn't exist for us. Watching it in case group-mapped GSSAPI ever becomes a must-have.

Azure Managed Redis Entra ID login fails with "network_error": fetch failed behind TLS-inspecting proxy Redis Insight #6472

Age: opened 7 weeks ago (September 2, 2026).

Reactions / comments: 1 / 1.

The vibe: behind Zscaler, every HTTPS call is re-signed by an enterprise CA that Windows trusts and Node.js does not — so Entra token requests fail with a fetch error while browsers work fine. Redis's own team confirmed the root cause the same day, which is genuinely good triage; the fix is presumably still cooking.

Credit: @erob93-jpg reported it; @pawelangelow confirmed it same-day.

SQLly: checked — not affected. SQLly's sign-in and token traffic verifies against the operating system's trust store, not a bundled list, so an enterprise root installed on the machine is trusted — and Redis connections can additionally opt into the OS keychain roots explicitly.

Rotating self-signed SSL certificates cannot be updated after a rotation Redis Insight #5179

Age: opened 11 months ago (November 12, 2025).

Reactions / comments: 0 / 2.

The vibe: twenty-plus Redis databases, self-signed client certs rotating every 30 days, and every rotation means copy-pasting three certificates per database into a GUI — over two thousand paste operations a year by my arithmetic. The certs keep the same filename and location, so file paths would fix it, but the app only stores pasted contents. "Planned for implementation," said the vendor — on January 30.

Credit: @adoramr reported it; @pawelangelow committed to it in January.

SQLly: already have it. SQLly references certificates as file paths — CA bundle, client cert, client key — and re-reads them every time a connection opens, so a rotation in place is picked up on the next connect with nothing to re-enter.

Add SSH Keepalive / Heartbeat option to prevent idle connection timeouts Redis Insight #6292

Age: opened almost 3 months ago (July 25, 2026). No vendor reply, ever.

Reactions / comments: 0 / 0.

The vibe: the SSH tunnel dies quietly during lunch and the first clue is a broken-connection error when you come back. A keepalive option would hold it open. Nobody answered.

Credit: @LmingXie asked for it.

SQLly: already have it. SQLly's SSH tunnels send a keepalive every 30 seconds by default and close the session after three unanswered ones — adjustable per connection, or off if you like living dangerously — and every SQL Server, PostgreSQL and MySQL socket sends TCP keepalives too. Idle lunch, live tunnel.

AWS IAM Authentication credentials provider Redis Insight #5693

Age: opened nearly 7 months ago (March 25, 2026).

Reactions / comments: 2 / 3.

The vibe: laid out precisely: ElastiCache IAM tokens are SigV4 pre-signed URLs with a 15-minute TTL, the app only accepts a static password, so every connection is a time bomb that fails its fifteenth minute. Another user needs the same for MemoryDB, and the vendor agreed to build it on September 17 — still open. Fair's fair: we didn't have it either.

Credit: @haydenhatcher specified it; @fbartonoctopus seconded it for MemoryDB.

SQLly: built today. AWS IAM is now a sign-in choice on Redis connections in SQLly: the token is signed fresh from your local AWS credentials at every connect and refreshed before it expires, for ElastiCache and MemoryDB alike. It's in today's changelog.

MCP server shares the tab's live MySQL connection Sequel Ace #2663

Age: opened 5 weeks ago (September 14, 2026).

Reactions / comments: 0 / 3.

The vibe: a proper audit: the MCP server runs its queries on the UI tab's live connection, so the assistant's results can be misattributed in the UI, session state leaks both ways, and the read-only guard is lexical-only — he demonstrated an EXPLAIN ANALYZE of a write slipping past it. The maintainer agreed a dedicated MCP connection per tab is the right fix and said he'd review the PR, which is the correct response to a report this good.

Credit: @kruegge82 audited it and found the guard bypass; @Jason-Morcos blessed the fix direction.

SQLly: checked — not affected. SQLly's MCP server is a separate process with its own connections, never the app's live ones; it runs read-only by default with per-connection modes, refuses Production connections outright, enforces the same parser-backed safety checks as the app, and writes an audit record for every tool call.

That's the connections batch: twelve settled, one new sign-in option shipped, and not a single keepalive dropped on our side. Tomorrow's pile is already waiting.