Sending database credentials to the browser btw may or may not make sense. It really depends on context. If the db is enforcing users' security (which would b

Sending database credentials to the browser btw may or may not make sense. It really depends on context. If the db is enforcing users' security (which would be the case if you want to share security logic across apps possibly written in different languages) and it is an internal app with limited numbers of users, this makes a lot of sense. For a public internet site, however, it makes very little sense (since you likely have lots of users with essentially the same permissions). In LedgerSMB, for example, we use app login credentials as db credentials for internal users, but for customer/vendor portals, we use a single user account for the portal. There are a lot of reasons for this but PostgreSQL is flexible enough one can (relatively easily) limit most users to the LedgerSMB app if one wants (via pg_hba.conf). The goal however is to allow non-web apps with the same credentials and security enforcement and we already have some of those. So it isn't necessarily a facepalm. It really depends on context. There can be valid reasons for it but those are not in the context of a public-facing web site. I.e. if you expect users only to access the db through a single app then you don't want to use it but if you want the db to be accessed through a group of apps then using the db as a SSO technology is actually pretty smart.