MVC is an architectural pattern that focuses on separation of concerns. This means, every component in your application should do only one task and do it well. It is this concern that helps identify the components as Models, Views and Controllers.
Usually, a resource (typically a record in a DB) is represented as a Model. Say, you have a table for users in a website. A corresponding model named something like
UserModel would expose all the relevant APIs to Create, Retrieve, Update and Delete a user from the DB.
The Controller would typically be the gateway to your application. The logic of delegation would reside here. For example, if you needed to bulk edit users, a request to a controller (perhaps named as)
BulkUserController would expose an API to edit multiple users. This controller in turn would delegate the edit task for each user in request to the
UserModel. Note that the Controller just handles delegation here.
Now, coming back to the question about interfacing with the DB. Since the models represent the resource, they are the ones that interact with the DB. This means, controllers such as
SingleUserController (for lack of imagination) would interact with
UserModel which in turn interacts with the underlying instance of the DB interface. Typically the instance of the DB interface would manage a connection pool to the DB for executing parallel queries on the DB.