Handling this on the application level feels like unnecessary complexity.
Any good reasons to go with the approach described in the blog post?
• You want easy administrative controls for impersonating a customer
• You want to run business queries across multiple customers
• You integrate authentication with your database, so you don't need a separate service to tell your application "which" database endpoints to use with your username.
• You want to simplify sysadmin job of managing a single database instead of thousands of databases.
And so on. Sometimes these things are worth giving up the "simple" isolation.
.. is actually a kind of "[h]andling this on the application level", with "this" being the Postgres' process management. Each database gets its own daemon and it is this per-database process that is responsible for launching a peer process for each connection.
There are likely legitimate use cases for multiple PG databases per node, but multi-tenancy is not one of them.