I did exactly what you are suggesting on a project some time ago - deferred to the database to do the password hashing and comparison to the stored hash. Unfortunately, the server query logs contained the query parameters. So did some of the database logs when running at elevated log levels. We quickly decided that was unacceptable, and moved the hashing process into the web server.
The webserver framework I was using at the time logged all its queries to the database at the normal log level. It couldn't log an actual query string because we used prepared statements, but it reconstructed the query and substituted the parameters in.
Enormously helpful for debugging an issue, when you can just copy and paste a query out of the serverlogs. Although I would probably have preferred that it not do that at the normal log level.
Curiously, it never logged the http request string/parameters. When I wanted that I had to add my own code to the request handler.
Or you can do the bcrypt() inside your (PostgreSQL) database and add an extra layer of security by not directly exposing the hash (or even the whole password table) to the web server process (i.e. write a password check SQL function and allow only calling it, no direct table/column access).