I've worked on multiple true relational SQL and 'analytics' backends and they have all supported analytic functions of varying complexity. Everyone around me wa

I've worked on multiple true relational SQL and 'analytics' backends and they have all supported analytic functions of varying complexity. Everyone around me was using them as well because the queries were orders of magnitude faster, and smaller and more readable than using nested SELECT ... GROUP BY statements to achieve the same result. Note that for reporting and analytics workloads, 1) even batch queries can be much faster using analytics functions because the optimizer can do many of them for essentially free as part of the scan rather than requiring a subquery and 2) interactive workflows become much, much quicker in my experience. Data exploration is much less useful if running a query takes 5 hours rather than 30 seconds. Defining sqlite as the 'standard' SQL and refusing to use any other features available on your platform out of fear of confusing new developers is misguided. Sometimes analytics functions are the best tool for the task, and good engineers should judiciously weigh their utility against the risk of losing access to that tool. Keep in mind though that the cost of migrating your db backend is generally so high that if you are forced to do so, rewriting queries that depended on analytics functions will likely be a small rounding error within the total migration cost.