[dllthomas]

While I largely share your broader concerns,

> ensuring that queries that should read only read

seems to be the purview of the DBMS, setting appropriate account permissions. The bit you quoted said "a database user account that has only read access".

[WesolyKubeczek]

On MySQL, you can run SLEEP() or BENCHMARK() as a read-only user to your heart's content. You cannot restrict access to these functions, and letting the wide internets play with them will bring your server to its knees by clogging up all connections and hogging up its CPUs.

[dllthomas]

I wasn't contradicting the bits about DOS attacks, which remain very much a concern, even when no one is malicious.

[derision]

Solution: Don't use MySQL

[WesolyKubeczek]

PostgreSQL's SQL is Turing-complete. Imagine the possibilities!

[eloff]

All rdbms have similar issues with built-in functions. Plus you can easily create pathological queries that do the same.

[isbvhodnvemrwvn]

This assumes you only deal with non-sensitive data (e.g. user profiles).

Never mind that, how do you prevent denial of service attacks? I can run any allowed query on that database. Including 50 times cross join of the table I can read, sorted by random.

[dllthomas]

> This assumes you only deal with non-sensitive data (e.g. user profiles).

Not really. You can do row or column level permissions. Details very much depend on your DBMS.

> Never mind that, how do you prevent denial of service attacks?

I have no real answer, and I never suggested that I would. Denial of service attacks (deliberate or accidental) are one piece of the "broader concerns" that I very much share.

In theory, a sufficiently advanced DBMS might be able to assign users quotas, and if your users are stable that may be sufficient for some use cases, but I am skeptical.