Last time we tried to use it there were real problems with date filtering in SQL based DBs and it’s a must for big datasets that span over time (this looks like the most common use case to me). Basically metabase would generate WHERE condition that would like `date(date_column) BETWEEN ... AND ...` (or if you were filtering by minutes or years this would be something else). This prevents DB from being able to use an index on date_column and don’t even get me started on why adding indexes for all sorts of `date(...)`, `year(...)` etc expressions is not an optimal solution. I ended up fixing this in metabase and opened a PR https://github.com/metabase/metabase/pull/9860 Which was initially welcomed but then was ignored for a few months (we were using our forked version in my company in the meantime), after which was closed because they’ve fixed it differently and sure enough they did and it was a neater fix architecture-wise. Just that it didn’t actually fix the majority of use cases so there’s now new isssue opened with the same problem described https://github.com/metabase/metabase/issues/11502 And surely it’s ignored. Since then we migrated to a relatively simpler Redash, we’ve found that none of the people at our company who were supposed to benefit from GUI query builder never actually used it and only engineers were building dashboards, and for us it’s obviously easier to write SQL. One benefit of Redash I’ve noticed was that it allows you to schedule dashboard queries to run for example every 10 minutes which means that amount of users of the dashboard doesn’t add any load to the DB because they get cached results and those results are relatively fresh at the same time.