Table of Contents [expand]
Last updated June 10, 2026
Postgres connections persist across requests to improve app performance and reduce the impact and costs of re-establishing a connection for every invocation. In forked environments, you must establish connections after the fork completes so that each process has its own connection.
Forked Environments
Frameworks and libraries that fork processes require you to establish Postgres connections after the fork completes. This process makes sure each forked process has its own connection, avoiding common connection errors such as no connection to the server, SSL SYSCALL error: EOF detected, and SSL error: decryption failed or bad record mac.
The sections in the rest of the article provide connection configuration best practices for common frameworks and libraries.
Database Connection Pools
When using a fork-based server, each fork receives its own database connection pool. For this reason, most apps using fork-based web servers perform best when you set the app-level connection pool (Rails, Sequel, Django) to size 1, or disable it entirely.
Using too many database connections can result in performance degradation and out-of-memory errors from the database servers. The database server also starts rejecting new connections when you reach your database’s connection limit.
Apps that require multiple simultaneous transactions within a single HTTP request are an exception to this guidance.
Configure Ruby on Rails
See Concurrency and Database Connections in Ruby with ActiveRecord for more details.
Configure Unicorn
Unicorn is a Rack HTTP server that uses forked processes to handle incoming requests. Configure the database connection behavior in the unicorn.conf configuration file.
See Concurrency and Database Connections in Ruby with ActiveRecord for configuration details.
Configure Resque
Resque uses forking to create new worker processes. Disconnect the main process connection before forking to avoid consuming unnecessary resources, and establish a worker connection after the fork occurs. See the Resque hooks documentation for more details.
Include the following configuration in the initializer configuration to clean up and re-establish the connections:
Resque.before_fork do
defined?(ActiveRecord::Base) and
ActiveRecord::Base.connection.disconnect!
end
Resque.after_fork do
defined?(ActiveRecord::Base) and
ActiveRecord::Base.establish_connection
end
Sidekiq
Sidekiq uses threads to handle many jobs at the same time in the same process. To prevent sharing of connections, you must configure the Sidekiq server to establish its own connection correctly.
You can specify this behavior by cleaning up and re-establishing connections in a Sidekiq initializer.
See Concurrency and Database Connections for Background Workers for details.