What are the merits/demerits of backend architectures with both API server and database server?

I recently got a recommendation to always build backend applications as a pair of two servers: an API server and a database server.

The API server exposes APIs to the mobile/web clients, but to get/create/update data it communicates - through, say, gRPC - with another server that accesses the database. The database server can only be accessed by the API server.

The merits of this method, as opposed to a single server setup, are that the database credentials are not stored on the server that is exposed publicly (the API server), so if a hacker gains access to the API server, they would not be able to access the database directly. Also, the two servers might potentially be built in different languages.

However, I see challenges with writing more abstractions (function definition in the database server, type definitions, function call in the API server) to process data - more code and more time spent.

What do you think about this? Do you use this two-server method? Are there other merits/demerits? Are there situations were it is absolutely necessary to do this? Or do you use other methods of securing your database?