[oxfordmale]

I hate Tableau with a passion. The main bugbear is that viewers can't see the SQL code the dashboards execute. I am no fan of Looker, but the "Explore here" allows other users to see the SQL and tweak it if needed. Most intermediate data stakeholders are confident enough to modify the where clause to suit their custom needs, allowing them to self-serve.

The licensing costs are prohibitive, too. It is almost unaffordable to share Tableau dashboards with your customers and, instead, have to send them static PDFs of your dashboard.

Beyond that, the Tableau infrastructure feels like something from the last century. Data is cached on the server using data extracts rather than following a more modern caching infrastructure.

[petepete]

I try to avoid these tools wherever possible, given the choice I'd always go for tools like Blazer.

https://github.com/ankane/blazer

No such luck in my current role, Looker and PowerBI are both in use by different bits of the org and nobody has the ability to delve into the underlying figures.

[WhrRTheBaboons]

Blazer sounds cool, thanks for the link!

[doctor_eval]

The whole instacart oss list is quite amazing. Some amazing tools there!

https://www.instacart.com/opensource

[cpsempek]

I also hate Tableau for this reason. However, it's a bad pattern to be storing custom SQL in a BI tool IMO. Better to create tables or views which hold your report logic and are stored in git. That way you're decoupling defining metrics and business logic from your BI tool, making that information queryable in your warehouse by users or other tools (and easily viewable!).

[data-ottawa]

It's a best practice yes, but in practice when you produce any data mart you end up getting questions to power deep dives and that's where custom SQL ends up coming from. There's usually a right way to answer the question, and a fast way with custom SQL, and with ad-hocs the fast way wins every time.

Here's an example, you do a customers rollup and an orders rollup, but a user asks for average order value of return customers buying product X. In SQL, that's a semi join of order line items, on your orders table and an inner join on daily customers to determine if they're a new customer. But no BI tool I've ever used has semi joins, so when you join in the tool your order values are multiplied and you're back to custom SQL to fix it.

It's that or build a whole new mart to answer this one question.

[TrackerFF]

Apache superset has a good SQL support. Toying around with it, and while it has its learning curve - it looks pretty damn decent IMO.

[KingOfCoders]

Looker is obscenely expensive compared to Tableau. Also the UI is bad.

The caching of Tableau is a huge money safer and huge performance boost if you e.g. use it with BigQuery (cut our BG costs by 80%).

As with every data tool, you need strong data governance, or everyone will define their own metric for revenue and then you have endless discussions about "why the data is wrong" (it isn't).

The biggest benefit to me is every marketing person knows Tableau and with a self explaining table structure (e.g. DBT on top of BigQuery) is self serving.

The only good thing with Looker is their data journeys, which Tableau doesn't have.

The worst (for EU/GDPR at least) feature of Looker is how people can send emails from a query (circumventing corporate email infrastructure, blacklists, data protection etc.). Can you say "Intern sends spam mail to millions of customers because they thought this was a good idea".

[aaronharnly]

We use both Looker and Tableau. It’s astonishing to me how Looker has stagnated since being acquired by Google. It’s really moribund.

[dswalter]

Before they were acquired by Google, looker had a bunch of really engaged community support people, and the docs were great for what the product did. There were learning paths for different types of users and tutorials linked to references in a way that made sense. I learned a lot about effective documentation (and looker!) from going through what they had.

Google laid off their US-based community support team (https://www.reddit.com/r/Looker/comments/t5jpwk/google_cloud...) and in the time since, those docs links have rotted/disconnected.

Even if 100 US-based community support folks were making $300K in total comp, why would you not spend $30MM to keep your $2.6B acquisition humming along? A bit mystifying.

[anon84873628]

One wonders why Google bothers acquiring companies if it's impossible to integrate them into the monolith.

[ianburrell]

I think they should keep acquisitions under Alphabet and separate from Google. What is the point of having umbrella corporation if not going to use it?

[KingOfCoders]

Yes, I thought the same.

[oxfordmale]

I am not recommending Looker either, but data extract stored on the server? That is a last-century solution. We often hit data limits in Tableau online as colleagues get overzealous.

Beyond that, it is also a major GDPR headache in Europe. If someone uses their personal account, with elevated access, you suddenly have a data extract on the Tableau Online server that contains personal data, with no way to enforce retention periods.

[te_chris]

I really like mode. It strikes a decent balance between being sql/notebook first but also has the memory engine for diving into things by non-tech.

[data-ottawa]

My problem with Mode is you often end up with a ton of copy and pasted SQL and no visibility or capability of changing it with updates in the underlying data. It really hurts data governance over the long run.

I like the notebooks feature, the integration of output cells with reports is so so, but it's the best balance between exploratory and reporting tool I've seen.

I found the parameterized code powerful but creating a basic report with lots of filters and a few parameters was very slow.