The Deska blog
Tailscale vs OpenVPN: Securing Database Access for a Distributed Team
Tailscale vs OpenVPN for internal database access: compare setup, security model, performance and ops burden, and pick the right VPN for your dev team.
· 9 min read
Choosing between Tailscale and OpenVPN for internal database access is one of those infrastructure decisions that feels small until the day a Postgres port ends up exposed to the public internet. Both tools can get your distributed team onto the same private network as your databases, but they embody two very different philosophies: a traditional hub and spoke VPN versus a modern WireGuard based mesh. This post compares them honestly, covers the security model of each, and gives you a concrete decision guide for securing database access for a remote engineering team.
The problem: your database should not be on the internet
The default posture for any internal database, whether it is Postgres, MySQL, Redis or MongoDB, should be simple: no public listening address, no open port on a security group, no IP allowlist that someone has to babysit. The moment a developer works from home, a coffee shop or a coworking space, you need a private path from their laptop to the host running the database.
There are three common ways teams solve this:
- SSH tunnels, which work well for one person but become unmanageable across a team
- A traditional VPN concentrator like OpenVPN, where everyone connects to one gateway
- A mesh overlay network like Tailscale, where every device connects peer to peer
SSH tunnels are fine as a stopgap, but they do not scale with people, and they leak into shared knowledge that lives in a wiki page nobody updates. So the real decision for a growing team is usually Tailscale vs OpenVPN.
How OpenVPN handles it
OpenVPN is the veteran. It has been production hardened for two decades, runs almost anywhere, and nearly every network engineer has configured it at least once. The architecture is hub and spoke: you run an OpenVPN server (or a managed access server) on a host inside your network, and every client establishes a tunnel to that server. Traffic from a developer laptop to the database flows through the concentrator.
Its strengths are real:
- Mature and battle tested, with a huge ecosystem of guides, appliances and integrations
- Works over TCP port 443, so it almost always gets through restrictive firewalls and hotel networks
- Fine grained control over routing, pushed DNS, and per client configuration
- Self hosted by default, so no third party coordination server ever sees your metadata
The costs show up in operations. You manage a PKI: certificate authority, server certificates, per client certificates, revocation lists. Rotating a leaked client cert means touching the CRL and restarting or reloading the server. Onboarding a new hire means generating and securely delivering credentials. And the concentrator itself is a single point of failure and a bandwidth chokepoint, since all database traffic hairpins through one box.
How Tailscale handles it
Tailscale is a mesh VPN built on WireGuard. Every device runs the Tailscale agent, gets its own stable IP in the 100.64.0.0/10 range, and connects directly to other devices in your tailnet whenever NAT traversal allows it. Instead of a concentrator, there is a coordination server that exchanges keys and helps peers find each other; the actual data path is end to end encrypted between devices.
For database access specifically, this model is appealing:
- Each developer machine and each database host is a first class node with its own identity
- Access control lists are defined centrally as policy, mapping users and groups to hosts and ports
- MagicDNS gives every node a readable name, so connection strings stay stable even when machines move
- You can restrict access to exactly port 5432 on exactly one host, rather than granting broad network access
The trade offs matter too. The coordination plane is a hosted service, which means you are trusting a third party with your node metadata and identity layer, though not with your traffic contents. You can self host the control plane with Headscale if that is a hard requirement. And WireGuard only speaks UDP, which can be a problem on networks that block it, though Tailscale falls back to relay servers when direct connections fail.
Head to head comparison
| Aspect | OpenVPN | Tailscale |
|---|---|---|
| Topology | Hub and spoke | Peer to peer mesh |
| Crypto and protocol | TLS over TCP or UDP | WireGuard, UDP only |
| Identity | Client certificates | SSO and device keys |
| Access control | Server config and firewall rules | Central ACL policy |
| Setup effort | PKI, server config, client provisioning | Install agent, log in with SSO |
| Control plane | Fully self hosted | Hosted, or Headscale |
| Single point of failure | Concentrator | Coordination server (control only) |
| Offboarding | Revoke cert, reload CRL | Remove device or user |
One honest caveat: raw throughput and latency depend far more on your network path than on the protocol in most real deployments. OpenVPN in UDP mode is fast enough for database workloads, and Tailscale direct connections are typically excellent. Where teams differ in approach is operational overhead, not benchmark numbers.
Security considerations that matter more than the tool
Whichever VPN you pick, the VPN itself is not the security boundary. A few practices matter more than the choice:
- Keep the database listening on a private interface only. The VPN gets you reachability, not authorization.
- Enforce authentication at the database layer: strong passwords or client certs, per developer accounts instead of a shared role, and TLS for the connection itself.
- Scope access tightly. With OpenVPN, use firewall rules on the server side so VPN clients can only reach the database host on the database port. With Tailscale, write ACLs that do the same thing declaratively.
- Log connections. Both Postgres logging and VPN logs give you an audit trail when someone asks who touched production at 2 a.m.
- Offboard fast. The day someone leaves, their access should die in minutes, not in the next certificate rotation cycle. This is where identity based meshes genuinely have an edge, because disabling a user in your SSO provider cascades immediately.
It is also worth saying what OpenVPN still does well: if your organization requires a fully self hosted stack with zero third party dependencies, or you need TCP 443 traversal through hostile networks, OpenVPN remains a defensible, even preferable, choice.
Where your workspace fits into this picture
A VPN solves reachability, but developers still need a sane place to actually work with that database once they can reach it. This is where your local tooling matters, and where Deska earns a mention as one honest option among many.
Deska is a free desktop app for Mac, Windows and Linux built around an infinite canvas where you arrange panels however you like. For the database access workflow, the relevant piece is that your machine is the node on the tailnet or the VPN client, and everything you run stays local. A terminal panel can hold your psql or mysql session through the VPN. A code editor panel holds the migration you are about to run. A browser panel shows the admin dashboard that only resolves inside the private network. Because Deska is local first, your files, sessions and credentials stay on your machine rather than transiting someone else's cloud.
Two features pair especially well with a secured network setup:
- The terminal panels persist your sessions on the canvas, so the SSH tunnel or VPN connected psql session you set up yesterday is still where you left it, zoomed out next to your notes and editor.
- The mobile app connects to your desktop through a secure relay with direct device pairing and no exposed ports, which means you can check on a long running migration from your phone without punching another hole in the very firewall rules you just tightened. See remote access for how that pairing works.
None of this replaces the VPN decision. It complements it: the VPN gets bytes safely to your machine, and the workspace decides whether those bytes are scattered across eleven app windows or arranged in one view you can actually reason about. If you are evaluating setups, the getting started guide takes a few minutes and the workspace itself is free.
FAQ
Is Tailscale more secure than OpenVPN for database access?
They differ in approach rather than in fundamental strength. OpenVPN relies on certificates and a hardened concentrator you fully control. Tailscale relies on WireGuard's modern cryptography, short lived node keys and identity tied to your SSO provider. In practice, security outcomes depend more on your ACLs or firewall rules, database authentication and offboarding speed than on the tunnel protocol.
Can I use Tailscale without trusting Tailscale's servers?
Yes, with a caveat. The coordination server only handles key exchange and peer discovery; your database traffic is end to end encrypted between devices. If you want to remove the hosted control plane entirely, Headscale is an open source, self hosted implementation of the coordination server that works with the same clients.
Do I still need to secure the database itself behind a VPN?
Absolutely. A VPN controls who can reach the port, not who can log in. Keep strong per user database credentials, enable TLS on the database connection, restrict which network interface the database binds to, and log sessions. Treat the VPN as one layer, not the whole defense.
Try a workspace built for this kind of work
If your team is tightening internal access and you want a local first workspace where terminals, editors and AI coding agents live on one canvas, give Deska a try. It is free for Mac, Windows and Linux, and your code and sessions never leave your machine. Download Deska and see how it fits your setup.