That means that your web app could act like "psql" and open a direct TCP socket connection to "postgresql://user:pass@host:5432/db", which would change everything
You'd no longer need a backend just to middleman SQL requests, assuming you have proper RLS implemented.
(Whether or not this is a good idea/applicable to all cases is debatable, but it at least becomes possible if I'm reading right)
Connecting browsers directly to databases is generally a bad idea for other reasons.
Wouldn't they be accessible to anyone reading the front end source files or plugins installed in the browser context?
You could just pass a single auth token to the database if it supported it for public data only and fetch it that way. Kinda like a bearer token, etc...
Therefore having direct access to the database from the client side only for public data.
This would be very beneficial to the web as a whole as a lot of the data is public data.
Then the separation of privilege/access has to happen directly at the database level which is totally possible.
Would be a nice addition to the web to treat public data differently.
data_access: private|public data_scope: single|composite data_exempt: age|gender|otherpiifield
Somewhat protecting PII by not allowing querries which would infringe PII rules when selecting multiple sensitive fields.
However that db backend is still listening for logins, it does not know who the client is.
What happens today imho is that you have access to pieces of the data tables not the whole database at once to run queries at will.
When you fill out an html form or click a button that runs business logic code which might run sql queries based on a token/id you passed.
That token/id does not have access to the whole database.
Temporary database wide sessions are still a risk in the browser context.