I'm admittedly bias, I love SQL. That said, I think having the database server worry about being a database is a good thing. In my career I've had a few projec

I'm admittedly bias, I love SQL. That said, I think having the database server worry about being a database is a good thing. In my career I've had a few projects that I've been too ambitious with; by trying to do too many things it failed to do any of them well. >Databases only talk custom binary TCP protocols, not HTTP. Not REST. Let's pretend that the database can now talk via HTTP/Rest. Is the database now responsible for handling business rules? Is it responsible for per row authorization/authentication? How does this impact performance? What if we want to export the data in another format, say into an excel spreadsheet, should it be responsible for that as well and the formatting? Where is the line drawn? >protect against SQL injection attacks. I mean, how would the database know the difference between a legitimate request that should be allowed and one that shouldn't? This is the point of parameterization. >Check for XSS I think it's plenty legitimate for a database to return some HTML data, how would the database know when it's malicious or not? ------------------- In full I think the grievances the author raises are with middleware, not a problem of the database.