> the idea of exposing queries from the client directly to the DB is totally bananas
I don’t necessarily disagree but going to play devil’s advocate here on this common foundational viewpoint. Why is this bad? In fact, why not expose the DB directly to the client?
“Additional layers” and “don’t explain DB structure” is security through obscurity. If a DB manages access control directly (field-level or partition-level granularity), any permissible query should run. To prevent pathological queries, add role-based resource quotas and back-off policies.
What about zero day vulns? Well these are going to be a problem regardless of the presence of various infra layers on top of the DB; you’ll have to monitor for data exfiltration to detect these types of attacks in either case.
There’s not a database I’m aware of that handles all of the above considerations, but oftentimes security issues exist in the overlooked gaps that arise between the complex interplay of many dependent systems. If you move the responsibility for security to the DB itself (other than authentication), you’ve removed a lot of the “confusion” that can be exploited, and overall security then depends on just a few factors: 1) correct assignment of DB access permissions, 2) valid external authentication, 3) quality of data exfiltration monitoring.
You might say you’re one simple DB misconfiguration away from disaster, but again, this is already a problem. The benefit of this alternative approach is that you have now shifted the bulk of the security work to one place: very careful rollouts of changes to DB access permissions. You would conduct static analysis to determine the “diff” of how data access has changed and perform sandbox tests. In exchange for this additional work, you can quit worrying about the security of anything downstream of the DB, assuming authentication is set up correctly.