PostgreSQL row-level security policies seem to be sufficient for access permissions most of the time (I'm also finding them easier to manage safely than custom restrictions), while its constraints can deal with validation. Timeouts (and/or per-user time quotas) in front of a DBMS can be used if one is worried about users abusing a database.

As mentioned in another reply, there seems to be quite a reluctance to use/accept plain SQL, and SQL injections are usually treated as vulnerabilities, though I doubt that it's necessarily worse (that is, more of a potential vulnerability) than an average web back end.

Users (not as in "API users", but as in "service users") usually aren't familiar with SQL, and it's not great to write queries manually each time (even if there are views and stored procedures with predefined ones), but SQL being exposed to clients ("API users") is reality, even if uncommon. Coincidentally, I worked on a project like that just this week, and on others taking such an approach in the past.