Database / BetterDB Interview questions
Explain the known limitation of SSH tunnels with cluster topologies?
SSH tunnelling in BetterDB Monitor only covers the single connection you explicitly configure.
For Valkey Cluster or Sentinel deployments, BetterDB discovers the other nodes by calling CLUSTER NODES or querying Sentinel, and then connects to those nodes directly using the addresses they themselves advertise – not through the tunnel.
If those other nodes are only reachable via the bastion – a common situation with ElastiCache or MemoryDB sitting in a private subnet – their per-node views simply won't load, even though the primary connection you tunnelled works fine.
The documented workaround is to use SSH tunnels only for single-node or primary monitoring, and for full cluster visibility either place the monitor somewhere it can reach every node directly, or use the outbound-WebSocket-based @betterdb/agent instead.
More Related questions...