SSH Tunneling is quite slow

[dawagner]

Bug description

My users were reporting that dashboards were taking a long time to load. It seems that for each SQL query, Superset open a new SSH connection. That can be quite costly and can even trigger rate-limiting or rejection from the ssh server.

I added a side-car container using autossh to my setup, removed tunneling from the database connection parameters and pointed the database connections to that container instead of the actual database. My "cache warmup" periodic task went from 10 minutes to 3 minutes and users report a day-and-night difference. In addition, the logs are much more readable now :)

Could the tunneling implementation be improved by pooling the ssh connection across requests?

(I'm using Superset 5.0.0 but I mentioned Superset 6.0.0 in the bug details because that was the closest available option)

Screenshots/recordings

No response

Superset version

6.0.0

Python version

I don't know

Node version

I don't know

Browser

Not applicable

Additional context

No response

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[rusackas]

It would be helpful to know if this is still an issue in 6.0 (the oldest currently supported version) and what repo steps we might be able to test this with... I think there were some optimizations made in this area between 5.0 and now. Perhaps @dosu can help us track down what's changed.

[dosubot]

Here's what I found regarding SSH tunneling changes between 5.0 and the current codebase:

Performance-related changes:

1. SQLAlchemy engine caching (PR test(database): regression test for sqla engine creation (#27897) #40237, May 2026) — adds module-level engine caching in Database._get_sqla_engine() to reuse engines per URL rather than recreating them on every invocation. This is particularly relevant to this issue since reusing engines means the associated SSH tunnel connections aren't torn down and rebuilt as frequently [1].

2. Avoiding unnecessary SSH tunnel creation (PR refactor(db): use Dialect instead of Engine in select_star to avoid SSH tunnels #35540, Feb 2026) — refactored select_star to use Dialect instead of Engine, preventing SSH tunnel connections from being established when only the dialect is needed for SQL generation [2].

However, the core concern raised in this issue — SSH tunnel connection pooling — has NOT been addressed. The current implementation still creates a new SSHTunnelForwarder instance per tunnel request without explicit session caching or pooling at the SSH layer [3]. The connection lifecycle is fully delegated to the underlying sshtunnel Python library.

So while the engine caching improvement reduces the frequency of new tunnel creation (by reusing SQLAlchemy engines that already have tunnel bindings), the fundamental architecture still opens a fresh SSH connection whenever a new engine is needed. For dashboards with many queries hitting the same tunneled database, this can still be costly — which aligns with @dawagner's observations.

Other notable changes since 5.0 (not directly performance-related but relevant to SSH tunneling):

• Server host key verification/pinning [4]
• ED25519 and ECDSA key support [5]
• Paramiko capped to <4.0 to prevent breakage [6]
• SSH tunnel architecture centralized on the Database model [7]

Bottom line: The engine caching in PR #40237 may partially mitigate this issue in 6.0 (since cached engines won't re-establish tunnels), but the sidecar approach @dawagner described remains a valid and likely superior workaround for heavy workloads, since there's still no dedicated SSH connection pooling layer.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[dawagner]

The engine-caching is worth investigating. I should definitely try again with 6.0 or later. Thanks, I'll keep you posted.