Request a 30-minute demo

Our product expert will guide you through our demo to show you how to automate testing for every part of your workflow.

See data diffing in real time
Data stack integration
Discuss pricing and features
Get answers to all your questions
Submit your credentials
Schedule date and time
for the demo
Get a 30-minute demo
and see datafold in action
///
August 24, 2023

Looker vs Tableau: A battle of the ages

This post is about the good and the not-as-good of Looker and Tableau, so you feel empowered to choose the tool that will best serve your use cases and users.

No items found.
Kira Furuichi

Looker and Tableau. Giants in the world of business intelligence (BI). And if you’re reading this, you’re likely at a standstill between these two giants: struggling to identify which BI tool will best serve the needs of your data, data team, and business users.

We’ll start this article off by saying: there’s no such thing as a perfect BI tool. Repeat it with me: there’s no such thing as a perfect BI tool. There are aspects that make Looker appealing, features that make Tableau stand out, and things about both of them that make you want to shake your fist at the sky.

This post is about the good and the not-as-good of these tools, so you feel empowered to choose the tool that will best serve your use cases and users. In addition, we’ll talk about the fundamental gap that has always existed between data transformation work (a la dbt) and your BI tools, and how Datafold is helping close that gap.

So, let’s dive in!

Overview of Looker and Tableau

Looker

Looker is a BI tool that is part of the Google Cloud Platform and was one of the first widely adopted modern BI tools to integrate code-based and version controlled business logic through the use of their LookML layer. Looker has four core parts of its platform: Explores, Views, Looks, and Dashboards.

In a typical set-up, data teams or technical business users will manipulate the underlying LookML to create Explores—commonly used datasets typically containing joined tables—that business users can then explore the data from. Non-technical business users typically rely on pre-made Looks or Dashboards for their regular reporting, but will dive into Explores when needing to perform ad hoc analysis.

Tableau

Tableau is another BI tool that is part of Salesforce (formally acquired in 2019 as well) that is known for its robust data visualizations. Tableau has gained considerable popularity across enterprise markets because of the variety of visualizations offered and out-of-the-box support for certain data analyses.

Unlike Looker, where your business logic is controlled in a central git repository (your LookML project), Tableau reporting is typically built upon custom SQL queries written directly in Tableau or pre-defined datasets.

Tableau supports different flavors of its application for different use cases and needs, such as Tableau Cloud, Tableau Desktop, or Tableau Server.

Looker vs Tableau: Comparing the features that matter

Below, we’ll unpack how Looker and Tableau compare across five core dimensions: data analysis, data visualization, data governance, pricing, and accessibility and collaboration.

Data analysis

Looker enables accessible and easy-to-use analysis features via its Explores and navigable Looks/dashboard elements. Within an Explore, business users and analysts can select the dimensions and metrics they’re interested in and simply run the Explore to receive insights. Within that result, they can toggle with data visualizations, manipulate pivots, and create custom table calculations—creating a very solid baseline for data analysis. For more technical users, Looker also supports their SQL Runner, where users can write SQL queries against database objects—without needing to be in the database itself. Looker has also newly supported (within the last few years) simplistic forecasting for more predictive analytics work.

In terms of data analysis, Tableau strongly supports the use of complex or advanced data visualizations to enable this. For users who want to perform investigative row-by-row data analysis or quickly perform ad hoc queries against the data, Tableau is not as strongly built-out for this use case. Both BI tools, however, allow for quick downloads to Excel or CSV format for additional analysis to be completed.

Data visualization

Looker supports a variety of standard data visualizations—column, bar, scatterplot, tables, pie charts, maps, funnels, and even word clouds. Users are able to customize the colors, fonts, axis, and labels using Lookers visualizations, as well as add in automatic trend lines or reference lines. Looker’s visualization offerings form a solid foundation for analytics and analysis, but may not meet complex visualization needs or use cases.

Data visualizations is where Tableau really comes out to play; Tableau is incredibly well-known for its complex and extremely customizable data visualization offerings—everything from detailed geospatial maps to Gantt charts. Colors, axis, and labels are all customizable in Tableau, allowing users to great some really amazing data visualizations. For teams that want (or need) clean, highly customizable, and complex visualizations, Tableau is a strong option for them.

Data governance

Because business logic is defined as code and version controlled in a git repository using LookML, Looker enables strong governance for data teams. Anytime there is an underlying change to the structure of an Explore, or a metric definition (within Looker) changes, those updates must be a) tracked in version control and b) merged in following a PR process. Typically, data teams will conduct automated testing in CI for their LookML changes using Spectacles and require peer review before merging them in. In addition, Looker easily supports the use of descriptions for Explores, dimensions, and metrics, so users can easily understand how key data is defined in plain language (versus reading the SQL/LookML). Most importantly about Looker’s git-based set-up is that *end data consumers only see the data the data team wants them to see—*making governing data straightforward to do in Looker.

Tableau’s data and business logic are usually not contained in a single repository or space; oftentimes, Tableau dashboards are a mix of custom SQL and pulls from pre-defined datasets. As a result, data governance in Tableau can be more complex. To overcome this, data teams will often highly restrict who can access or write custom SQL and have business users rely solely on reports that are pre-made for them.

Both BI tools (and most BI tools in general) often struggle with governing BI tool assets (in this case, Tableau reports and Looker Dashboards) at scale. As business users create reports at-will, it can be difficult to trace how your data is being used, where it’s being used, and by whom it’s being used in your BI tool.

Pricing

BI tools are…typically not inexpensive. And likely (definitely) not the cheapest tool in your data stack.

And it makes sense—these tools are often the bloodline for decision making in your business and require many business users and data analysts must have access to them. Both Looker and Tableau have pricing models that, in general, correlate to the number of users (including user types), deployment types, and overall complexity, and usually run on an annual or time-based subscription.

Accessibility and collaboration

In terms of accessibility, we specifically mean the ability to develop and use the BI tool. Looker, for example, supports an “Explore from here” functionality that allows users to select a specific dashboard element and further explore it for analysis—same filters, dimensions, and metrics applied as the one they originally were looking at. Looker also easily exposes the LookML layer, so more technical users can see how certain metrics may be defined or if there’s business logic applied to a dimension or metric. To further develop or edit LookML, Looker also supports “Development Mode” and intuitive branching strategies, so users less familiar with git practices can more easily contribute to the repository. We often see Looker being talked about as a strong platform for “self-service analytics.”

Looker, however, has a very real adoption curve. The concepts of dimensions and metrics may often confuse users, and navigating through Explores can be challenging if you don’t have either a strong idea of where the data may live or poor naming conventions for data assets.

To develop in Tableau typically requires stronger technical skills (a la SQL) and a deep understanding of the underlying data structure, but using and interacting with Tableau visualizations can be quite intuitive for business users.

Both BI tools leverage the concepts of folders to help store and organize dashboards, so data teams can hopefully keep reports in the right place and end users can quickly find what they’re looking for.

Automated data lineage in Looker and Tableau with Datafold

We hinted at it earlier, but one of the greatest struggle in any BI tool is understanding where your data is being used. In Looker, you typically have finer grained control because the data team specifies the data models exactly, but you lose the ability to track where each Explore or data asset is being used in downstream Looks and Dashboards. In Tableau, it can be a bit of the wild west with the use of custom SQL throughout worksheets. And this problem only continues to grow as your team and business grow to hundreds…then thousands of dashboards.

That’s where Datafold Cloud’s robust column-level lineage comes in.

With Datafold Cloud’s Looker and Tableau integrations, you have a complete understanding of where your data is used, and which BI tool assets are potentially impacted by your upstream dbt code changes. Specifically:

  • Datafold’s Column-Level Lineage shows not only the lineage between your dbt models and data warehouse objects, but also Looker Explores, Views, Looks, and Dashboards
  • Datafold Cloud’s CI comment in your PR automatically detects BI tool assets that contain data that is changed in the proposed PR

These two features together allow data teams to not only know how their data moves through one of the most important tools of their business, but proactively notify potentially impacted end users if their reports will be changed as a result of a dbt code update.

In real terms, this translates to: Finding data quality issues before your stakeholder finds them.

Looker and Tableau represented in Datafold Cloud's column-level lineage

Which one’s right for your team?

So the million dollar question remains: how do I know which BI tool is best for my team and organization? And as we said earlier, there’s no such thing as a perfect BI tool. Some will over index on their collaboration features; others will lack the more complex technical needs your data and business users have. But at the end of the day, your decision will be made by knowing what’s important to you (and finding the happy medium). Factors to consider for your decision:

  • The technical level of your end users—are they comfortable writing their own SQL? Or do they need considerable guardrails in place?
  • Your primary use cases—do you have skilled data analysts creating complex analysis and reports on a regular basis? Or is standard reporting enough for your team?
  • The comfort level you have with users writing their own queries—is this something you’d rather have finely controlled by your data team?

Whether your team ends up choosing Looker or Tableau, never lose control or knowledge of how the data is being used with Datafold Cloud’s column-level lineage and automated impact analysis. When your team is making upstream changes to the core tables of your business, impact to BI tools is no longer kept in the dark. Your business is no longer kept in the dark.

Want to see Datafold Cloud's Looker integration in action? Join us for our live Datafold Cloud Demo Day where we'll highlight how integrating lineage in your BI tools is a game-changer for governing your data work.