PostgreSQL Database Over Tor Hidden Service

Traditional database security relies on firewall rules to restrict which IPs can reach port 5432. This is effective but requires maintaining accurate allowlists and exposes the host IP to network scanning. A Tor hidden service takes a different approach: the database port is bound only to localhost, and Tor creates an encrypted tunnel to a .onion address. No IP is exposed, no port is scannable from the internet, and connection attempts require knowledge of the .onion address plus authentication credentials. For multi-tenant applications, audit logging databases, and any workload handling sensitive records, this zero-exposure architecture is significantly stronger than firewall-based isolation. Application servers connect to the database via the same Tor network - the database traffic never leaves the Tor overlay. This is particularly valuable when the application server and database are in different physical locations, as the connection remains encrypted end-to-end through Tor circuits without requiring a VPN or dedicated network link.

Install PostgreSQL and immediately configure it to listen only on localhost: in postgresql.conf set listen_addresses = 'localhost'. This ensures that even before Tor is configured, the database port is not exposed. Install Tor and configure /etc/tor/torrc with a HiddenServiceDir and HiddenServicePort 5432 127.0.0.1:5432 mapping. After Tor starts, the .onion address appears in the hidden service directory's hostname file. From this point, the database is reachable only via the .onion address through Tor. Verify isolation: from any external machine, attempt to connect to the server's public IP on port 5432 - it must time out or be refused. Only connections routed through Tor to the .onion address should succeed. Create a dedicated PostgreSQL user for each application with minimal required privileges rather than using the superuser account. Enable pg_hba.conf host-based authentication to require passwords or certificates even for connections from localhost (which is where Tor delivers traffic).

PostgreSQL has a connection overhead per session that limits scalability under many concurrent connections. PgBouncer is a lightweight connection pooler that sits between clients and PostgreSQL, maintaining a pool of persistent connections and multiplexing client requests. Configure PgBouncer to listen on a different localhost port (e.g., 6432) and connect forward to PostgreSQL on 5432. Then create a second Tor hidden service mapping port 6432 as the client-facing endpoint. Application clients connect to the PgBouncer .onion address, which pools connections efficiently. PgBouncer supports three pooling modes: session pooling (one server connection per client session - most compatible), transaction pooling (server connection released after each transaction - most efficient for high concurrency), and statement pooling (most granular, least compatible with multi-statement transactions). For typical web application workloads, transaction pooling reduces database server load by 3-5x. PgBouncer configuration includes per-user limits, idle timeouts, and query logging - all running within the Tor-isolated environment.

Application clients need to route their PostgreSQL connection through Tor SOCKS5 proxy. Most PostgreSQL client libraries support SOCKS5 proxies, but the configuration method varies. For Python with psycopg2: use the PGSSLMODE environment variable and route via torsocks wrapper (torsocks python app.py), or configure a SOCKS5 proxy at the socket level using the socks library. For Node.js with pg library: use pg-proxy-client or configure SOCKS5 at the net module level. For Java JDBC: use the socksProxyHost and socksProxyPort JVM properties (java -DsocksProxyHost=127.0.0.1 -DsocksProxyPort=9050). For direct psql command-line: wrap with torsocks (torsocks psql -h youronion.onion -U dbuser -d mydb). Connection strings use the .onion hostname as the host parameter. Ensure Tor is running on the client machine with SOCKS5 on port 9050. Test connectivity with torsocks psql before deploying application code. SSL/TLS is optional over Tor (Tor already encrypts the connection) but adding it provides defense-in-depth and protects against misconfigured setups.

Backing up a Tor-isolated PostgreSQL database must maintain the isolation principle - backup transfers should not route through clearnet. Three approaches: (1) Local backup to encrypted disk: run pg_dump locally and encrypt with GPG before storing. Schedule this via cron and rotate backups. The backup files remain on the server, requiring out-of-band retrieval. (2) .onion-to-.onion backup transfer: set up a second hidden service on a separate server running an rsync or SFTP endpoint. Configure pg_dump to pipe directly to the remote .onion via torsocks rsync or torsocks sftp. (3) Encrypted backup to onion storage service: some privacy-focused storage services offer .onion upload endpoints. Regardless of method, encrypt backup files before transfer using symmetric encryption (AES-256 via gpg -c) or asymmetric encryption with a key pair where the private key is stored off-server. Never transfer unencrypted database dumps over any network. Verify backup integrity by periodically restoring a dump to a test instance and running a row count check against the production database.