Is the separation of a database process from the main backend process really "good practice"?

In our current architecture, we have a React frontend communicating with a Rust backend via REST calls. We are considering introducing a PostgreSQL database, and my colleague suggests that we should separate the database access into a distinct Java/JPA API, resulting in the following architecture: React frontend --> REST calls --> Rust Backend --> REST call --> Java/JPA API --> PostgreSQL I believe that we could simplify our architecture by allowing the Rust backend to access PostgreSQL directly using a library like diesel.rs, thus avoiding the overhead of an additional microservice. What are the potential advantages and disadvantages of outsourcing database access to a separate Java/JPA API, as my colleague suggests? Is this really "good practice", or something he just thinks he is. Context: He is a university-trained programmer and used to lead teams, I am just a junior programmer trying to understand this. Our service is a small service used internally.

May 2, 2025 - 12:03

In our current architecture, we have a React frontend communicating with a Rust backend via REST calls. We are considering introducing a PostgreSQL database, and my colleague suggests that we should separate the database access into a distinct Java/JPA API, resulting in the following architecture:

React frontend --> REST calls --> Rust Backend --> REST call --> Java/JPA API --> PostgreSQL

I believe that we could simplify our architecture by allowing the Rust backend to access PostgreSQL directly using a library like diesel.rs, thus avoiding the overhead of an additional microservice.

What are the potential advantages and disadvantages of outsourcing database access to a separate Java/JPA API, as my colleague suggests? Is this really "good practice", or something he just thinks he is.

Context: He is a university-trained programmer and used to lead teams, I am just a junior programmer trying to understand this. Our service is a small service used internally.