Back to Blog
Audience Specific 11 min read

TL;DR - Agencies managing 10+ client databases across different providers (AWS, DigitalOcean, Hetzner, shared hosting) lose hours weekly to connection setup, credential juggling, and firewall rule updates. - Local tools like MySQL Workbench and DBeaver don't sync across team members, scatter credentials across laptops, and require per-machine setup for every new hire. - A centralized agency database management approach using a browser-based tool like DBEverywhere lets any team member open a browser, pick a client connection, and start working — from any device, with one static IP that every client whitelists once. - Saved connections (paid tier) organize access by client. SSH tunnels are built in. No local installs, no SSH key distribution, no VPN configuration. - Free tier: 5 sessions/month with 20-minute timeout. Paid: $5/mo per user for unlimited sessions, saved connections, SSH tunnels, and 8-hour timeouts.

Table of Contents

The Agency Developer's Guide to Managing 10+ Databases Across Clients

If you run or work at a web development agency, agency database management is one of those problems that doesn't feel like a problem until it consumes half your Monday. Client A is on DigitalOcean Managed MySQL. Client B has a self-hosted PostgreSQL instance behind a bastion host on AWS. Client C is on Hetzner with a firewall that only allows two IP addresses. Client D is on shared hosting with an ancient phpMyAdmin install that nobody wants to touch. Client E just migrated to PlanetScale and you haven't updated the connection details anywhere yet.

You are not managing one database. You are managing a portfolio of databases across providers, engines, firewall configurations, and credential stores — and every developer on your team needs access to a different subset of them. This guide is about fixing that workflow.

The Agency Database Problem at Scale

Freelancers deal with multiple databases. Agencies deal with multiple databases multiplied by multiple team members. The complexity scales non-linearly.

A 2023 Upwork study found that agencies and small development shops typically maintain 8-20 active client projects simultaneously. Each project means at least one database — often staging and production, so double it. A 15-client agency with staging and production environments is looking at 30 database connections that someone on the team needs to access on any given day.

The JetBrains 2023 Developer Ecosystem Survey found that 57% of developers work with more than one database engine. In an agency context, that number is functionally 100% — you don't get to choose your clients' tech stacks. One client uses MySQL, another uses PostgreSQL, a third uses MariaDB, and the WordPress client is on whatever the managed host provides.

Each of these connections has its own: - Hostname and port (and sometimes a non-standard port for security) - Credentials (username, password, sometimes a certificate) - Network access rules (IP whitelist, VPN requirement, SSH tunnel) - Database engine (which determines which tool you even use) - Access scope (which developers should see which clients' data)

Managing this across a team is the problem. And it only gets worse as the agency grows.

Why Every Client Means a Different Setup

The reason managing databases across clients is painful is that there's no standardization. Every client made different infrastructure decisions, and you inherit all of them.

Here's what a typical agency's Monday morning looks like:

Client A (DigitalOcean Managed MySQL): Developer opens MySQL Workbench, finds the connection from two weeks ago, enters the password. Connection refused — the developer is working from home today, and their residential IP changed over the weekend. They log into DigitalOcean, add their new IP to trusted sources, wait for it to propagate.

Client B (AWS RDS behind a bastion host): Same developer needs to check a migration. Opens terminal, hunts for the SSH key (~/.ssh/clientb-bastion.pem? ~/.ssh/aws-clientb.pem?), runs a port-forward command they copied from a Notion doc six months ago. The bastion host's security group doesn't have their IP. They message the DevOps lead, who's in a different timezone.

Client C (Hetzner VPS, self-managed MySQL): A different developer SSHs directly into the server and runs mysql -u root -p. The root password is in a shared 1Password vault, except someone changed it last month and didn't update the vault entry. Twenty minutes of Slack archaeology follows.

Client D (shared hosting, cPanel): The junior developer needs to check a WordPress database. They log into cPanel with credentials from an onboarding email, open phpMyAdmin, and discover it's version 4.9.7, which doesn't support the JSON column functions they need.

Time spent before anyone writes a useful query: 30-60 minutes across the team. Multiply that by 5 days a week, and an agency with 5 developers is losing 10-25 hours per week to connection overhead. At an average agency billing rate of $125/hour — based on Clutch's 2024 agency pricing survey — that's $1,250-$3,125 in lost productivity every week.

The Credential and Access Control Mess

Agencies have a credential problem that solo freelancers don't face: multiple people need access to the same databases, but not the same databases.

The frontend developer working on Client A's React dashboard needs read-only access to Client A's production database. The backend developer on Client B needs full access to Client B's staging environment but should never touch production. The senior developer floats across projects and needs access to everything.

In practice, agencies solve this one of four ways, all of which are bad:

  1. Shared credentials in a password manager. Everyone on the team has the same password. No audit trail. No way to revoke access for one person without changing the password for everyone.

  2. Per-developer credentials scattered everywhere. Each developer sets up their own connections on their own machine. Credentials live in MySQL Workbench configs, .env files, SSH key directories, and shell history. When someone leaves the agency, good luck finding every place their access is cached.

  3. A shared document or wiki page. Connection details for every client in a Google Doc or Notion page. Updated inconsistently. Accessible to people who shouldn't see certain clients' credentials.

  4. Verbal handoff. "Hey, the password for Client C's database is..." via Slack DM. That message now lives in Slack's history indefinitely.

GitGuardian's 2025 State of Secrets Sprawl report found that 12.8 million secrets were exposed in public GitHub repos in 2024. The private equivalent — credentials in internal repos, Slack, email, and shared docs — is estimated to be at least 10x that number. Agencies are disproportionately exposed because they handle credentials for many organizations, not just their own.

What Breaks When You Hire Developer Number Five

The first three or four developers at an agency can brute-force the database access problem. Everyone knows where the credentials are. SSH keys get passed around informally. Firewall rules get updated ad hoc.

Developer number five breaks everything:

  • Onboarding takes a full day just for database access. Install MySQL Workbench, DBeaver, pgAdmin. Set up SSH keys for each client. Get added to each client's firewall whitelist. Copy connection details from a wiki that's partially outdated.
  • Every client's firewall needs another IP. If you have 15 clients with IP whitelists, that's 15 firewall rules to update. For every new developer. And again every time someone's IP changes.
  • Credential distribution is manual. Someone has to sit with the new developer and walk through which password manager vault has which client's credentials, which SSH keys go where, and which clients require a VPN.
  • Offboarding is worse. When developer number five leaves six months later, you need to remove their IP from 15 client firewalls, revoke their access to credential vaults, confirm they've deleted local SSH keys and connection configs, and hope they didn't save any passwords in a browser autofill.

A browser-based agency developer database tool eliminates most of this. Onboarding becomes "log in, here are your assigned connections." Offboarding becomes "disable their account." One IP for every client's firewall — it never changes because it belongs to the service, not the developer.

One Tool, One IP: How Browser-Based Access Simplifies Everything

The core value proposition for agencies is consolidation. Instead of each developer maintaining their own local toolchain for each client's database, everyone uses one browser-based interface.

Here's what that looks like with DBEverywhere:

  1. Any team member opens a browser. Chrome, Firefox, Safari — whatever is on their machine. No install step.
  2. They pick a saved connection (organized by client on the paid tier) or enter connection details directly.
  3. The gateway connects. DBEverywhere routes the connection through its static IP, handles SSH tunnels if the database is behind a bastion host, and serves the database interface (phpMyAdmin for MySQL/MariaDB, Adminer for PostgreSQL and everything else).
  4. They work. Full query execution, schema browsing, data export/import — the same phpMyAdmin or Adminer experience, but without local setup.

The static IP is the critical piece for agencies. Instead of maintaining a list of developer IPs in every client's firewall, you tell every client the same thing: whitelist this one IP address. It doesn't change when developers switch networks, hire new team members, or work from a different country. Learn more about how static IP whitelisting works for database connections.

For a 15-client agency with 5 developers, that replaces 75 firewall rules (15 clients times 5 developer IPs, all of which change) with 15 rules (15 clients times 1 static IP that never changes).

Managing firewall rules for a growing team? DBEverywhere gives every team member the same static IP for all database connections. Free to start.

Local Tools vs. Browser-Based: Agency Comparison

Local Tools (Workbench, DBeaver, pgAdmin) Browser-Based (DBEverywhere)
Onboarding a new developer Install tools, distribute SSH keys, add IP to each client's firewall, share credentials Create account, grant access to client connections
Offboarding a developer Remove IP from each firewall, revoke vault access, confirm local credential deletion Disable account
IP whitelisting per client One IP per developer per client (changes frequently) One static IP for all developers, all clients
SSH tunnel management Each developer configures tunnels locally per client Built into saved connections, configured once
Works across devices No — per-machine install and config Yes — any browser, any device
Multi-engine support Different tools for MySQL vs. PostgreSQL vs. others phpMyAdmin (MySQL/MariaDB) + Adminer (all others) in one interface
Credential storage Scattered across developer machines Centralized, encrypted (AES-256-GCM), opt-in
Cost for 5 developers Free-$25/mo per tool per developer $25/mo total ($5/user)
Firewall rules for 15 clients 75+ rules (5 devs x 15 clients, dynamic IPs) 15 rules (1 IP x 15 clients, static)

Organizing Connections by Client

On the paid tier, saved connections become the backbone of multiple database management for agencies. Instead of a flat list of hostnames, you organize connections with names that make sense for your team:

  • Acme Corp — Production MySQL
  • Acme Corp — Staging MySQL
  • Globex — Production PostgreSQL
  • Globex — Bastion → Private RDS
  • Initech — Shared Hosting MySQL

Each saved connection stores the host, port, database engine, and optionally the credentials and SSH tunnel configuration — all encrypted at rest with AES-256-GCM. Credentials can be omitted if your policy requires developers to enter them per session.

This isn't a replacement for a secrets manager on a large team. But for a 3-8 person agency, it's a significant upgrade over "check the wiki and hope it's current." For how this compares to other approaches, see our comparison of browser-based database tools.

The practical benefit: when a client calls at 4:30 PM with a production issue, your developer doesn't spend 15 minutes reconstructing a connection. They click the saved connection and they're in. That's the difference between a 20-minute response and a 5-minute response — and clients notice.

FAQ

Does every developer on my team need their own DBEverywhere account?

Yes. Each team member has their own account and their own login session. This provides individual audit trails — you know who connected to which client database and when. On the paid tier at $5/month per user, a five-person team costs $25/month total. Saved connections are per-account, so you can control which developers see which client connections.

Can DBEverywhere handle both MySQL and PostgreSQL clients?

Yes. DBEverywhere routes MySQL and MariaDB connections through phpMyAdmin and all other engines — PostgreSQL, SQLite, MS SQL, Oracle — through Adminer. You do not need separate tools for different database engines. This is especially valuable for agencies where each client may use a different engine. See our phpMyAdmin vs. Adminer comparison for details on what each interface supports.

What happens if a developer leaves the agency?

Disable or delete their account. Since all database access goes through DBEverywhere, there are no local SSH keys to revoke, no connection configs cached on their laptop, and no IP address to remove from client firewalls. If they used per-session credentials (never saved), there is nothing to clean up at all. If they used saved connections, deleting the account removes their access to those connections immediately.

Is one static IP secure enough for client database access?

The static IP is one layer in a defense-in-depth model. It restricts the network surface — only connections from that IP reach the database port. But it is combined with per-user authentication (your database username and password), TLS encryption in transit, and session timeouts. An attacker would need the static IP, valid database credentials, and a valid DBEverywhere session. For more on layered database security, see our guide on secure database access for remote teams.

How does pricing compare to setting up a VPN for the team?

A VPN like Tailscale or a WireGuard-based solution costs $5-15 per user per month, requires client software on every device, and needs ongoing maintenance (certificate renewal, client updates, split tunnel configuration). DBEverywhere's paid tier is $5/user/month with no client software and no maintenance. For a five-person agency, that's $25/month versus $25-75/month for a VPN — and the VPN still requires you to install and configure database tools on each machine separately.

Conclusion

Agency database management doesn't have to be a tax on every developer's day. The core problem — many clients, many providers, many engines, many team members, many firewall rules — is a multiplier problem, and the solution is consolidation.

A browser-based approach collapses the toolchain to a single interface. One tool for MySQL, PostgreSQL, and everything else. One static IP for every client's firewall. One place to manage connections, organized by client. No per-machine setup, no SSH key distribution, no IP whitelisting treadmill every time someone's ISP rotates their address.

DBEverywhere is built for this workflow. The free tier gives you 5 sessions per month to test it against your actual client databases. The paid tier at $5/mo per user unlocks saved connections, SSH tunnels, 8-hour timeouts, and unlimited sessions — everything an agency team needs to manage databases across clients without the operational overhead.

Start free at dbeverywhere.com — no credit card, no installation, no onboarding ritual.

Try DBEverywhere Free

Access your database from any browser. No installation, no Docker, no SSH tunnels.

Get Started