Postgres + Tailscale – A database you can trust with a simple VPN
If you are like us, Tailscale was an obvious tool to add to our network — as soon as we saw it, we knew we needed it. For those who haven’t tried Tailscale yet, it’s best described as a programmable, re-sizeable, distributed private network mesh. Yes, it’s that great. The better part is that Tailscale is fairly simple, and because it’s simple, it is easy to get correct.
When we set out to build Crunchy Bridge we wanted to ensure you could build safely from day one. This included features such as isolated VPCs for every cluster, built-in platform audit logs, SQL audit logs, and much more. Securing your cluster with VPC peering is a great step to keeping it locked down and secure, but you lose a bit on the developer experience side having to jump through a bastion host or open up firewall rules to connect from your local machine.
Today, we’re launching Tailscale integration with Crunchy Bridge to allow you to continue to be safe, but not have to compromise on the developer experience you’ve always wanted for your database. If you’re already familiar with Tailscale you may be as excited as we are for this launch. But, if you’re new to Tailscale or wondering what this may mean for you there are really two use cases.
For the major infrastructure providers we support VPC peering, but if you’re on another provider such as Fly.io you may still want to lock down your database so it’s not accessible to the public internet. With Tailscale you can setup your Fly.io app directly to your Crunchy Bridge database, then remove all public internet access. See more about setting up Fly replicas with Crunchy Bridge too.
If you are on one of the major cloud providers, we hope you’ve already setup VPC peering with your app. But sometimes you need to simply connect to your database from your local machine. Tailscale gives you a convenient mechanism for this without mucking with firewall rules or bastion hosts.
How it works
First jump over to Tailscale and generate an authkey
:
For production environments, we recommend using a tagged auth key, so that you can configure permissions ahead of time, and these will be used when adding access. Ephemeral keys can be useful if you anticipate one off short lived access, but in most cases we recommend non ephemeral keys that will retain your connection even after a failover. Additionally, make the auth key reusable will help should Crunchy need to retry connection logic - if a connection fails, and you’re not using a reusable auth key, any retry logic will fail.
Next, add the generated authkey
to Crunchy Bridge cluster settings under Network -> Tailscale.
Then, after the Tailscale connection initializes in the Tailscale UI, you’ll be able to connect:
Find the Tailscale IP address for the new machine’s Tailscale connection, then connect to your Postgres via that IP address. And you're off!
Next steps
Haven't setup a Bridge database yet? Wondering everything you can get including Fly integrated to your own apps? Try this sample app which connects to Crunchy Bridge with Fly.io including leveraging PgBouncer for connection scaling, Tailscale for private networking, geo-replicas for low latency.
Docs are at Bridge and Tailscale.
Give Crunchy Bridge a try today and see the database developer experience you've been missing.
Related Articles
- Sidecar Service Meshes with Crunchy Postgres for Kubernetes
12 min read
- pg_incremental: Incremental Data Processing in Postgres
11 min read
- Smarter Postgres LLM with Retrieval Augmented Generation
6 min read
- Postgres Partitioning with a Default Partition
16 min read
- Iceberg ahead! Analyzing Shipping Data in Postgres
8 min read