Basically the framework is only responsible to provide a response to an http request (that includes handling the database as you said). But Rails isn't responsible to open a new thread (or in some implementations, a process) whenever a new http request arrives - this is done by the application server (such as Puma, Webrick, Unicorn etc). This is called concurrency (the ability to serve the app to multiple requests at the same time, in a nutshell) and is purely the job of the app server. Another thing is understanding (and parsing) the http request - Rails doesn't implement http, it receives a ready request from the app server who does implement http.
In ruby land the job of each part is defined by the rack protocol https://rack.github.io/. Rails, as a rack application, simply waits for "something" (the web application server) to 'call' it (with an http request), and it returns to it the response.
So to sum up: the application server needs to handle threading or multi processing to serve http requests to Rails (the app server is basically always listening on some socket for new requests, and provides concurrency either by forking processes, opening new threads or both. It depends on the app server). The app server therefore also needs to understand http (be able to parse an http request) so it can server that to Rails.
Rails, the web framework, only needs to handle an http request and return the response.
