Direct SQL from the client definitely isn't for everyone, but these problems aren't insurmountable. Caching: This is true of any API allowing, for example, adv

Direct SQL from the client definitely isn't for everyone, but these problems aren't insurmountable. Caching: This is true of any API allowing, for example, advanced search. If you can get by without it, great, but it's often a requirement. Dialect: I don't think it's a terrible idea to bet on one (ideally stable and FLOSS) database, it's just a risk to be managed, and I think it can provide benefits in some cases. Or you could be fancy and use jOOQ's SQL dialect translator (this could also be used to create a "custom dialect" without some features). Multiple data sources: You could use PostgreSQL's Foreign Data Wrappers. An unorthodox solution, but it allows seamless access with fast joins. Complex SQL features: I don't think it's really a problem, in complex analytics code I think some users would actually appreciate having all these features. It can be a code quality challenge, but I think that's better solved on a personal level. This approach does have real problems, like it being hard to prevent DoS attacks, but I don't think there are as many problems as it seems on first glance.