5 ms·

Also see metabase: https://www.metabase.com/ https://www.metabase.com/ We use this to embed some nice dashboards & run queries to great effect. A very powerfu

• Jommi 6y ago
  How does this fair with something like Cluvio?
• te_chris 6y ago
  Metabase is great, I just wish it would support BigQuery properly as currently you need to connect to each dataset individually. Still, it’s the best OSS software tool I’ve used, I think. Deploy the container to whatever, give it be creds, done.
  • sfsylvester 6y ago
    Is there a recommended tool for BigQuery? Both this and Falcon look great, but my company's pretty wedded to BigQuery for the moment.
    • seektable 6y ago
      SeekTable also can use BigQuery as a data source, however it is more about reports sharing and quick ad-hoc queries - to make this possible data source should be configured first.
    • te_chris 6y ago
      All the commercial ones support it, but most of them are expensive. Mode has a free plan which allows you to connect to BQ, run queries and then analyze the result sets in Jupyter. It's pretty cool for smaller stuff https://mode.com/compare-plans/ https://mode.com/compare-plans/
      • deleted 6y ago
        [deleted]
    • tlarkworthy 6y ago
      We used Redash and BQ together at Firebase
      • te_chris 6y ago
        Hadn't seen redash, thanks!
• nikita2206 6y ago
  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 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 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.
  • throwaway_pdp09 6y ago
    It's usually easier to write SQL than drag/drop it. For complex joins having a graphical view of the join structure (list? tree? star?) is very helpful if you're new to it, otherwise no. And drag/drop tools don't cover complex stuff like recursive CTEs, and often, simpler stuff too. IME, YMMV. Maybe better graphical tools exist than the ones I have seen.