en
Database Optimization for Tor Hidden Services
Database performance is often the critical bottleneck for content-rich onion services. While Tor circuit latency is fixed at roughly 200-600ms per round trip, slow database queries add variable latency that compounds circuit overhead and makes response times unacceptable. Optimizing your database layer - query execution plans, indexing strategy, connection pooling, and caching - yields the largest performance improvements for most hidden service operators. This guide focuses on PostgreSQL and MySQL optimization specifically for the query patterns common in onion service applications.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
PostgreSQL Configuration for Onion Services
PostgreSQL's default configuration targets conservative memory usage suitable for shared systems. For a dedicated onion service database server, increase shared_buffers to 25% of system RAM. Set effective_cache_size to 75% of total RAM - this hints to the query planner how much memory is available for caching, improving index selection decisions. Increase work_mem to 64-256 MB per connection for complex sort and hash operations. Enable parallel query execution with max_parallel_workers_per_gather = 4 for servers with 8+ cores. Set random_page_cost = 1.1 for NVMe storage (down from the default 4.0) to encourage index usage over sequential scans.
Connection Pooling with PgBouncer
Each PostgreSQL connection uses approximately 5-10 MB of RAM for connection state. An application receiving 500 concurrent Tor connections creating individual database connections would require 2.5-5 GB of RAM for connection overhead alone. PgBouncer in transaction pooling mode reduces this by sharing a pool of 50-100 connections across hundreds of application threads. Install PgBouncer and configure pool_mode = transaction in pgbouncer.ini. Set max_client_conn = 1000 to accept the application's connections and default_pool_size = 25 per database user.
Index Strategy for Hidden Service Query Patterns
Analyze slow queries using the pg_stat_statements extension which tracks execution counts and total time per query. The top 10 queries by total_time are your optimization targets. For each slow query, run EXPLAIN (ANALYZE, BUFFERS) to view the execution plan, buffer cache hits, and actual vs. estimated row counts. Missing indexes on foreign keys are a common issue in ORM-generated schemas. Create composite indexes for multi-column WHERE clauses and use partial indexes (WHERE clause) to dramatically reduce index size for filtered queries.
Redis Caching for Read-Heavy Onion Services
Read-heavy onion services (news sites, forums, markets) benefit from Redis caching of frequently accessed database query results. Implement application-level caching by serializing query results to Redis with appropriate TTLs: cache user profile data for 300 seconds, cache listing pages for 60 seconds, and cache session data with sliding 3600-second windows. Use Redis key namespacing for organized cache management. Implement cache-aside pattern: check Redis first, fall back to database on miss, populate Redis with the result. Monitor cache hit ratio via redis-cli INFO stats. Target 80%+ hit ratio for high-value cached objects.
Monitoring and Slow Query Analysis
Enable PostgreSQL's slow query log with log_min_duration_statement = 100 (log queries over 100ms) in postgresql.conf. Review slow query logs daily during the first weeks after deployment to identify optimization targets. Use pgBadger to parse PostgreSQL logs and generate HTML reports showing slowest queries, most frequent queries, and lock wait statistics. Monitor connection pool statistics with PgBouncer's admin interface. Alert if avg_wait_time exceeds 100ms, indicating pool exhaustion. Combine database metrics with Tor circuit metrics in Grafana to correlate slow response times with their root cause (circuit latency vs. database latency vs. application processing).
Related Services
Why Anubiz Host
100% async — no calls, no meetings
Delivered in days, not weeks
Full documentation included
Production-grade from day one
Security-first approach
Post-delivery support included
Ready to get started?
Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.