How rails database connection pool works

Purpose:
Database connections are not thread safe; so ActiveRecord uses separate database connection for each thread.

Limiting factor:
Total database connections is limited by the database server you use (e.g Posgres: default is typically 100 or lesser), by your app server's configuration (number of processes/threads available) and Active Record's configuration : Connection Pool defaults to 5 .

Pool size:
Active Record's pool size is for a single process. A thread uses a connection from this pool and releases it automatically afterwards. (unless you spawn a thread yourself, then you'll have to manually release it). If your application is running on multiple processes, you will have 5 database connections for each of them. If your server is hit by 1000 requests concurrently, it will distribute the requests among these connections, when it gets full, rest of the requests wait for their turn.

Read more at:
https://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/ConnectionPool.html

Yes, from the docs:

A connection pool synchronizes thread access to a limited number of database connections. The basic idea is that each thread checks out a database connection from the pool, uses that connection, and checks the connection back in. ConnectionPool is completely thread-safe, and will ensure that a connection cannot be used by two threads at the same time, as long as ConnectionPool's contract is correctly followed. It will also handle cases in which there are more threads than connections: if all connections have been checked out, and a thread tries to checkout a connection anyway, then ConnectionPool will wait until some other thread has checked in a connection.

source: http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/ConnectionPool.html

If you use something like unicorn as http server:

In Unicorn each process establishes its own connection pool, so you if your db pool setting is 5 and you have 5 Unicorn workers then you can have up to 25 connections. However, since each unicorn worker can handle only one connection at a time, then unless your app uses threading internally each worker will only actually use one db connection.