Tor Database Hosting — PostgreSQL, MySQL & MongoDB on .onion

PostgreSQL is our recommended database for Tor hosting. It offers advanced features including JSONB columns, full-text search, row-level security, and excellent performance under concurrent load. We deploy PostgreSQL 16 with optimized settings for your server's resources — shared_buffers, work_mem, and effective_cache_size are tuned based on your plan's RAM allocation.

MySQL and MariaDB are fully supported for applications that require them, including WordPress, Drupal, and many PHP applications. We configure InnoDB as the default engine with buffer pool sized to your available RAM, binary logging for point-in-time recovery, and slow query logging for performance analysis.

MongoDB is available for applications that use document storage. We configure MongoDB with authentication enabled, WiredTiger storage engine, and encryption at rest. Redis is included on all plans for caching, session storage, and message queuing. All database engines bind to localhost only — they are never directly accessible from the network, even over Tor.

Database security on Tor hosting requires multiple layers of protection. At the storage layer, all databases run on encrypted filesystems using LUKS full-disk encryption. At the database layer, we enable authentication for all connections and configure role-based access control with least-privilege permissions for your application's database user.

Connection encryption is configured even for localhost connections, providing defense-in-depth against local privilege escalation attacks. PostgreSQL uses scram-sha-256 authentication and SSL connections. MySQL uses caching_sha2_password with TLS. These encryption layers ensure that even if another process on the server is compromised, it cannot intercept database traffic.

For sensitive data fields, we provide guidance on application-level encryption where individual columns are encrypted with keys that only your application holds. This means that even if the database files are somehow accessed, the encrypted fields remain unreadable without the application encryption key that is stored separately from the database.

Automated database backups run daily using native dump tools — pg_dump for PostgreSQL, mysqldump for MySQL, mongodump for MongoDB. These logical backups are compressed, encrypted with your public key, and stored on separate infrastructure from your live server. We retain 14 days of daily backups and 4 weeks of weekly backups.

Point-in-time recovery is available for PostgreSQL and MySQL through WAL archiving and binary log retention respectively. This allows you to restore your database to any specific moment in time, not just the last backup snapshot. This is invaluable for recovering from accidental data deletions or application bugs that corrupt data.

Restoration is straightforward: select a backup from the control panel and click restore. The system stops your application, restores the database, verifies integrity, and restarts your services. For less disruptive recovery, you can restore to a separate database instance and migrate data selectively. We also support downloading encrypted backup files for off-site storage.

Database performance is critical for .onion sites because Tor's latency makes every millisecond of server-side processing more noticeable. We optimize database configuration based on your workload profile. Read-heavy applications get larger shared buffers and connection pooling via PgBouncer. Write-heavy applications get tuned WAL settings and checkpoint configuration.

We provide database monitoring through your control panel showing active connections, query throughput, cache hit ratios, replication lag, and slow query logs. These metrics help identify performance bottlenecks before they impact your visitors. Our team can assist with query optimization, index recommendations, and schema design for complex applications.

For high-traffic .onion sites, we support read replicas that distribute query load across multiple database instances. The primary instance handles writes while replicas serve read queries, multiplying your database throughput. Replication is configured with streaming replication for PostgreSQL and binary log replication for MySQL, with automatic failover if the primary becomes unavailable.