TL;DR - SSH tunnels are the default advice for remote database access, but they are not the only option — and often not the simplest one. - Four alternatives: (1) direct connection with IP whitelisting + TLS, (2) VPN, (3) browser-based database tools, (4) cloud provider console. - IP whitelisting works when your database has a public endpoint. According to cloud provider documentation, every major managed database service (AWS RDS, DigitalOcean, Google Cloud SQL, Hetzner, Linode) supports IP-based access control. - You genuinely need SSH when the database has no public endpoint — it sits on a private subnet reachable only through a bastion host. - DBEverywhere lets you access MySQL and PostgreSQL databases from a browser with a static IP for whitelisting. Free tier: 5 sessions/month. Paid tier ($5/mo): unlimited sessions, saved connections, and SSH tunnels for private databases.

Table of Contents

• Why Developers Default to SSH
• Method 1: Direct Connection with IP Whitelisting
• Method 2: VPN into the Database Network
• Method 3: Browser-Based Database Tools
• Method 4: Cloud Provider Console
• Comparison: All 4 Methods vs SSH Tunnels
• When You Genuinely Need SSH
• FAQ
• Conclusion

How to Access Your Database Without SSH: 4 Methods That Actually Work

If you search "how to connect to a remote database," nearly every result tells you to set up an SSH tunnel. The advice is so universal that many developers assume SSH is the only way to access a database without SSH being some kind of compromise. It is not. SSH tunnels solve a specific problem — reaching a database on a private network through a bastion host — but a large percentage of remote database connections do not require one. According to a 2024 Percona survey, over 72% of MySQL and PostgreSQL deployments now run on managed services that provide public endpoints with built-in access controls.

This article covers four methods for database access without an SSH tunnel, explains the tradeoffs of each, and clarifies exactly when you still need SSH.

Why Developers Default to SSH

The SSH tunnel habit comes from a time when most databases ran on bare-metal or self-managed VPS instances. The database listened on 127.0.0.1 only, and SSH was the sole way in. That muscle memory persists, but the landscape has shifted. Managed database services now dominate. DB-Engines tracks over 400 database systems, and the top providers — AWS, Google Cloud, Azure, DigitalOcean, PlanetScale — all offer public endpoints with firewall rules built in.

Despite this, developers still reach for SSH because:

1. Tutorials are outdated. The top Stack Overflow answers for "connect to remote MySQL" were written in 2012-2016 when self-hosted was the default.
2. Habit. If you've always used SSH tunnels, trying something different feels less secure — even when it isn't.
3. Confusion about what SSH provides. Many developers believe SSH adds encryption the database connection lacks. In reality, TLS has been standard in MySQL since 5.7.11 (2016) and in PostgreSQL since version 8.0 (2005). The encryption argument for SSH tunnels is largely obsolete.

Let's look at what you can use instead.

Method 1: Direct Connection with IP Whitelisting

The simplest way to connect to a remote database no SSH required: connect directly to its public endpoint and restrict access by IP address.

How It Works

1. Your managed database has a public hostname (e.g., db-abc123.db.ondigitalocean.com).
2. You add your IP address to the database firewall's allowlist (called "Trusted Sources" on DigitalOcean, "Security Groups" on AWS, "Authorized Networks" on Google Cloud SQL).
3. You connect with your database client using the public hostname, port, and credentials — over TLS.

That's it. No tunnel, no bastion host, no intermediate server.

Provider-Specific Setup

Every major provider supports this:

• AWS RDS: Edit the VPC Security Group to allow inbound traffic on port 3306 (MySQL) or 5432 (PostgreSQL) from your IP.
• DigitalOcean Managed Databases: Add your IP under Trusted Sources in the database dashboard.
• Google Cloud SQL: Add your IP under Authorized Networks. TLS is enforced by default.
• Hetzner Cloud: Configure firewall rules on the database project to allow your IP.
• PlanetScale: Add IP restrictions in the database branch settings. All connections use TLS.
• Linode/Akamai: Add your IP to the database access controls in the Cloud Manager.

For a detailed walkthrough per provider, see How to Whitelist an IP on Your Database Provider.

The Catch: Dynamic IPs

If your ISP assigns a dynamic IP — common with residential connections — your IP may change daily or weekly. You have two options:

1. Update the allowlist manually when your IP changes. Tedious but workable for solo use.
2. Route through a static IP. This is what services like DBEverywhere provide — a fixed IP that connects to your database on your behalf. You whitelist that one IP and never update the firewall again, regardless of what network you are on.

According to FCC broadband data, roughly 65% of US residential connections use dynamic IP assignment — making static IP gateways practical for the majority of developers working from home.

Method 2: VPN into the Database Network

A VPN places your device on the same network as the database. Once connected, you can reach the database using its private IP address, just as if you were physically in the data center.

When This Makes Sense

• Your organization already runs a VPN for other purposes (SSH into servers, internal tools, monitoring). Adding database access costs nothing extra.
• You need access to multiple private-network services, not just the database.
• Compliance requirements mandate VPN-level access controls (SOC 2, HIPAA).

When This Is Overkill

• You only need database access. A VPN gives you the entire network, violating the principle of least privilege.
• You work from multiple devices — every one needs a VPN client installed.
• You want quick access. VPN connection adds 10-30 seconds of overhead, and according to a Zscaler 2023 VPN Risk Report, 56% of organizations experienced a VPN-related security incident in the past year.

For a deeper comparison, see VPN vs Static IP vs SSH Tunnel: Which Is Best for Database Security?.

Method 3: Browser-Based Database Tools

Browser-based tools let you manage your database from a web interface without installing anything locally. The tool runs on a server, connects to your database server-side, and serves the UI over HTTPS.

Options in This Category

• Cloud provider consoles: AWS RDS Query Editor, Google Cloud SQL Studio, DigitalOcean's database console. Built in, free, but limited in functionality (often read-only or restricted to simple queries).
• Self-hosted web tools: phpMyAdmin, Adminer, CloudBeaver. Full-featured but require you to deploy and maintain a server.
• Hosted web tools: DBEverywhere, which runs phpMyAdmin (for MySQL/MariaDB) and Adminer (for PostgreSQL, SQL Server, SQLite, Oracle) as a managed service.

Why Browser-Based Works for "Database Access Without SSH Tunnel"

The key advantage: the server connects to your database, not your laptop. Your laptop's IP, network restrictions, and installed software are irrelevant. You just need a browser and an internet connection.

With a hosted tool like DBEverywhere, the server has a static IP address. You whitelist that IP in your database firewall once. From that point on, you can access your database from any device — laptop, tablet, a borrowed machine — without SSH keys, VPN clients, or tunnel commands.

This also solves the "new team member" problem. Instead of provisioning SSH keys and walking someone through tunnel commands, you share a URL. Onboarding drops from 30-60 minutes to under 2 minutes.

Self-Hosted vs Hosted Tradeoffs

Running phpMyAdmin or Adminer yourself is free but means maintaining Docker, security patches, and TLS certificates — and phpMyAdmin is one of the most commonly targeted applications on the internet. A hosted tool like DBEverywhere handles that. The tradeoff is a monthly fee and trusting a third party with credentials during the session. See phpMyAdmin Docker Is Painful — Here's a Better Way.

Method 4: Cloud Provider Console

If your database runs on a major cloud provider, that provider likely offers a built-in query interface.

• AWS RDS Query Editor: Available for Aurora MySQL/PostgreSQL. SQL queries in the AWS console, limited to 1 MB result sets.
• Google Cloud SQL Studio: Supports MySQL and PostgreSQL queries from the GCP console.
• Azure Data Studio (web): Web version for Azure SQL alongside the desktop client.
• DigitalOcean: Basic SQL console in the managed database dashboard.

Limitations

Cloud consoles handle quick lookups and simple queries. They are not full database management tools — you typically cannot import/export large datasets, manage users visually, or run multi-statement transactions. For full management without SSH, browser-based tools (Method 3) are more practical.

Comparison: All 4 Methods vs SSH Tunnels

	SSH Tunnel	IP Whitelist + Direct	VPN	Browser Tool	Cloud Console
Setup time	5-10 min per device	1-2 min (one-time)	15-60 min	Under 1 min	Already available
Client software	SSH client	Database client	VPN app	Browser only	Browser only
Works from any device	No	Only if IP is static	No	Yes	Yes
Private databases (no public IP)	Yes	No	Yes	Yes (with SSH tunnel support)	Limited
Full DB management	Yes (with local GUI)	Yes (with local GUI)	Yes (with local GUI)	Yes	No
Ongoing maintenance	Bastion host + key management	Firewall rule updates	VPN server + client updates	None (if hosted)	None
Monthly cost	Free (if bastion exists)	Free	$5-50/mo	$0-5/mo	Free
Connection reliability	Drops on idle	Very stable	Usually stable	Very stable	Very stable

Key takeaway: SSH tunnels are the only free option that handles private databases. But for databases with public endpoints — which is the majority of managed database deployments — IP whitelisting and browser-based tools are simpler, more reliable, and work from any device.

When You Genuinely Need SSH

SSH tunnels are not obsolete. There are scenarios where they remain the right tool:

The database has no public endpoint. It sits inside a VPC on a private subnet with no public hostname. The only way in from outside is through a bastion host on that network. An SSH tunnel through the bastion is the standard solution.

Your provider does not offer IP whitelisting on a public endpoint. Some older or self-managed setups only allow local network connections. SSH is your bridge in.

You are on a restricted network that blocks database ports. Corporate firewalls sometimes block ports 3306 and 5432 but allow port 22. A tunnel routes database traffic through SSH. (Browser-based tools on port 443 also solve this, since HTTPS is almost never blocked.)

Compliance requires bastion-host-mediated access. Some security frameworks require all database access to route through a jump box with session logging.

If your database does require an SSH tunnel but you do not want to manage it locally, DBEverywhere's paid tier ($5/mo) handles tunnel creation server-side. Provide the bastion address and SSH credentials, and the gateway opens the tunnel from its static IP.

FAQ

Is it safe to connect to a database without SSH?

Yes, if the connection uses TLS and the database firewall restricts access by IP. TLS encrypts traffic using the same cryptographic standards as SSH. The MySQL documentation recommends TLS for all remote connections. Adding SSH on top of TLS encrypts already-encrypted traffic — no meaningful security gain.

Can I use phpMyAdmin without an SSH tunnel?

Yes. phpMyAdmin connects to your database from whatever server it runs on. If that server's IP is whitelisted in your database firewall, no tunnel is needed. The challenge is running phpMyAdmin itself — you need a web server, PHP, and TLS configured. DBEverywhere runs phpMyAdmin as a hosted service so you do not need to manage any of that. See phpMyAdmin Without a Server for more detail.

What if my IP address keeps changing?

This is the most common obstacle to IP whitelisting. Three solutions: (1) Ask your ISP for a static IP (some offer this for $5-10/month). (2) Use a VPN with a fixed exit IP so your traffic always comes from the same address. (3) Use a static IP gateway like DBEverywhere, which provides a fixed, published IP that you whitelist once — then access your database from any network through the browser.

Does IP whitelisting work with AWS RDS?

Yes. AWS RDS uses VPC Security Groups for access control. You create an inbound rule allowing TCP traffic on your database port from your IP address (or a static gateway IP). If the RDS instance has a public endpoint enabled, this is all you need — no SSH tunnel, no VPN. See How to Connect to AWS RDS from a Browser for a step-by-step guide.

What about databases behind a private subnet on AWS or GCP?

If the database has no public endpoint, you cannot connect with IP whitelisting alone. You need a path into the private network — either a VPN, an SSH tunnel through a bastion host, or a gateway service that supports SSH tunnels. DBEverywhere's paid tier handles this: you provide bastion host credentials, and the gateway opens an SSH tunnel server-side. You still use a browser; the SSH complexity is handled for you.

Conclusion

SSH tunnels are a good tool for a specific problem: reaching databases on private networks through a bastion host. But for the majority of remote database work — connecting to managed databases with public endpoints — they add setup time, maintenance burden, and connection fragility without meaningful security benefit over TLS with IP whitelisting.

If your database has a public hostname, whitelist your IP (or a static gateway IP), connect over TLS, and skip the tunnel. If your database is on a private network, SSH tunnels remain necessary — but you do not have to manage them yourself.

DBEverywhere gives you phpMyAdmin and Adminer in the browser with a static IP for whitelisting. Free tier: 5 sessions/month, 20-minute timeouts. Paid tier ($5/mo): unlimited sessions, 8-hour timeouts, saved connections, and SSH tunnel support for private databases. No Docker, no bastion hosts, no terminal required.

Try DBEverywhere free ->