The Power of Simplicity
The standard data access pattern for modern, business, data-driven applications is this:
UI (browser client) → Fetch (Browser API calls) → Server Endpoint (Controller) → Service Layer → Repository → ORM → SQL (Automatic with ORM) → RDBMS
We do this so that we can mock the Repository and test logic in the Service. The problem with this approach is that once you realize how trivial it is to wire up database-aware tests - you can call them what you like, integration tests, database tests, whatever - once you realize that, you also realize you can collapse at least two layers:
UI (browser client) → Fetch (Browser API calls) → Server Endpoint (Controller) → ORM → SQL (Automatic with ORM) → RDBMS
This is much, much simpler. But then, as you become proficient with SQL and you realize you can do things that ORM can't generate, and in many cases faster and more efficient, you realize this can be even simpler:
UI (browser client) → Fetch (Browser API calls) → Server Endpoint (Controller) → SQL → RDBMS
And then you realize SQL actually has a rich type system - at least something mature and advanced as PostgreSQL does - and that type system can be used as a contract, and that Controller code is just boring glue code that can and should be automated:
UI (browser client) → Fetch (Browser API calls) → Automatic Server Endpoint (Controller) → SQL → RDBMS
But why stop there? If the controller can be automated, why not generate those Fetch calls as well? And that SQL can be stored in the RDBMS. Finally, this is what we have, basically:
UI → RDBMS

Now, if we all start doing software architecture like that, imagine how many tokens and energy we could save... That is what I call the energy efficiency. In a time of looming energy crisis, we could probably power a small country with the power of simplicity.
If you want to learn how to do this with PostgreSQL, check out the Quick Start Guide or dive into the Tutorials.