The world’s leading publication for data science, AI, and ML professionals.

My Experience Switching From Power BI to Looker (as a Senior Data Analyst)

What you need to know before you switch from Power BI to Looker.

⚠️ Note: This article is comparing Power BI with Looker (NOT Looker Studio).

Transitioning from Power BI to Looker (source: own production)
Transitioning from Power BI to Looker (source: own production)

When I started using Looker at my current job, I was surprised at how little useful information there was about it online.

Search for "Looker," and you’ll mostly find content about Looker Studio, which is an entirely different tool.

I was not able to find an authentic and practical review comparing Power BI with Looker (not Looker Studio), so I decided to create one based on my experience with both.

Having the experience using Power BI in a previous role at Zensai (formerly LMS365) and having transitioned to Looker in my current role at Trustpilot, I wanted to document some of the most important technicalities you need to be aware of when you perhaps make this shift yourself in the future too.

In this article, I’ll:

  • discuss the main differences between Power BI and Looker,
  • talk about the strengths and weaknesses of each tool,
  • share tips for a smooth transition between the two platforms to make it less painful,
  • highlight Looker’s unique features that I love,
  • and mention whether I prefer Power BI or Looker as a Senior Data Analyst for Commercial & Marketing.

Looker’s integrated table view under visualizations saves time.

(Looker 1:0 Power BI)

One feature I really appreciate in Looker is the integrated data table displayed beneath your visualizations during the exploration phase.

Data table is under your visualization at all times (source: own production)
Data table is under your visualization at all times (source: own production)

I can’t count how many times I’ve had to switch back and forth between the report view tab and the data view tab in Power BI when constructing charts, debugging, and checking columns.

In Power BI, you can display a visualization as a table – you click on the three dots and select "show as a table." But here’s the catch: the table isn’t what you’d call fully interactive. You can’t edit it, pivot, or customize it like you can in Looker. It’s more like a snapshot than a tool. If you want to make changes, you have to go into Power Query. You can’t see the visual while you’re making edits – it’s a disconnected process.

The table in Power BI is not customizable like it is in Looker (pivoting, calculating new columns, measures, dimensions, hiding columns, etc.) (source: own production)
The table in Power BI is not customizable like it is in Looker (pivoting, calculating new columns, measures, dimensions, hiding columns, etc.) (source: own production)

Having a customizable table view at all times right there under the visualization in Looker saves a lot of time and really is a practical feature you will get used to very quickly.

Looker expressions lack the power and functionality of DAX formulas.

(Looker 1:1 Power BI)

However, I don’t like Looker expressions.

Compared to DAX (Data Analysis Expressions), they aren’t as developed in terms of the number of different functions.

DAX provides a rich library of functions for complex calculations and time intelligence, which is critical for advanced analytics.

My favourite DAX function in Power BI is definitely the =CALCULATE function. CALCULATE changes the filters to give you the result you want – it makes it super useful for things like time-based or category-specific calculations:

Previous_Month_Gross_Volume = 
CALCULATE(
    [gross_volume], 
    DATEADD(dim_date[Date], -1, MONTH),
    dim_product[Category] = "Electronics",
    dim_region[Region] = "North America"
)

While Looker offers a range of expressions for data manipulation that they call Looker Expressions (sometimes referred to as Lexp), they don’t match the depth and versatility of DAX in Power BI.

Looker’s expressions are less widely adopted compared to DAX and have a smaller presence in online forums, documentation, and educational resources. This is also due to the fact that DAX is also used in Analysis Services, and Power Pivot in Excel.

I’ve also noticed that generative AI models will sometimes struggle with the exact structure/formulas of Looker’s expressions as they have been introduced later than DAX – even when setting up the right context and additional parameters for the model to take into account.

One additional thing to keep in mind is that Looker expressions are not the same as LookML language – which is where do confusion might happen for some.

Looker expressions are used to perform calculations and they use the fields you define in LookML.

For example, when you add a field to an expression, Looker uses the field’s LookML identifier, which looks like ${view_name.field_name} .

Creating a new calculated column in Looker (source: own production)
Creating a new calculated column in Looker (source: own production)

Looker expressions are used for creating:

  • custom dimensions
  • custom calculated columns
  • custom measures
  • and custom filtering

within the Looker explore interface.

Calculated columns can be created by only using the fields that are present in your data table - later you can hide them if you don't want to show them on your chart (source: own production)
Calculated columns can be created by only using the fields that are present in your data table – later you can hide them if you don’t want to show them on your chart (source: own production)

This seems easy – but if you incorporate multiple dimensions, measures, calculated columns, and pivot the data, you can end up with a very powerful data table.

Pivoted data table when creating cohorts using multiple dimensions, measures, and calculated columns (source: own production)
Pivoted data table when creating cohorts using multiple dimensions, measures, and calculated columns (source: own production)

Power Query Editor in Power BI enables easy data manipulation.

(Looker 1:2 Power BI)

Power BI has the Power Query Editor, similar to the one in Excel.

Launch the Power Query editor in Power BI (source: own production)
Launch the Power Query editor in Power BI (source: own production)

You can create calculated columns, remove first rows, set the first row as a header, and so much more with a few clicks.

Power Query editor in Power BI (source: own production)
Power Query editor in Power BI (source: own production)

This Power Query Editor does not exist in Looker – although you can create custom measures, custom dimensions, and custom calculated columns very easily in your Explore in Looker.

However, for other transformations that come in handy in Power BI/Excel, you need to write LookML code.

As you’ll discover later in this article, this is also a big positive of Looker due to data centralization.

Looker is only web-based.

(Looker 1:3 Power BI)

I like that Power BI comes as a desktop application, which allows me to work offline using local datasets and take advantage of my local machine’s processing power!

Power BI comes as a desktop app, Looker does not (source: own production)
Power BI comes as a desktop app, Looker does not (source: own production)

Looker doesn’t come as a desktop app – it’s only web-based. If you prefer Mac, web-based is an advantage – especially considering Power BI’s desktop app is Windows-only.

One thing I must say I like in Looker is that you can very easily navigate through your changes back and forward using the back and forward buttons on your browser. This is because each change in a Looker explore creates a new unique URL link. As you modify your queries or adjust settings, the URL updates to reflect the current state of your explore. This goes hand-in-hand with Looker’s caching that allows you to visit your query and visuals again – without spending on running them again, so they load instantly (the default cache retention policy is one hour).

While Power BI Service – where users upload and edit reports, collaborate, and create Apps, is also web-based, Looker’s fully browser-based approach eliminates operating system restrictions altogether.

Power BI simplifies star schema modeling, whereas Looker requires learning LookML.

(Looker 1:4 Power BI)

Modeling and creating your star schema is super easy in Power BI’s Modeling tab.

Star schema in Power BI using the Modeling Tab (source: own production)
Star schema in Power BI using the Modeling Tab (source: own production)

You enjoy a very big canvas with all your imported tables and can use FKs and PKs to link your tables using many-to-one relationships between the fact table and your dimension tables.

For example, leads coming to your business can be stored in the fact table, while region, contact forms, lead sources, and channels are your separate dimension tables with unique values.

This helps to query your fact table very fast and efficiently. Additionally, it’s very easy to adjust the relationship with Power BI’s click-and-choose feature.

By double-clicking on the relationships line, you can adjust your relationship with a few clicks (source: own production)
By double-clicking on the relationships line, you can adjust your relationship with a few clicks (source: own production)

In Looker, this isn’t as easy as clicking and building your relationships with a few clicks.

You need to learn LookML to join your different views (= views mirror the tables loaded from your data warehouse to Looker) within explores and define your relationships and keys using LookML language.

Star schema in Looker is done using LookML code (source: own production)
Star schema in Looker is done using LookML code (source: own production)

Power BI outperforms Looker with chart options.

(Looker 1:5 Power BI)

With Power BI, you have more default charts to choose from.

Intelligent charts in Power BI, including triple exponential smoothing forecasting (Holt-Winters) and key influencer chart (source: own production)
Intelligent charts in Power BI, including triple exponential smoothing forecasting (Holt-Winters) and key influencer chart (source: own production)

I’m definitely missing the key influencer chart that basically builds a simple regression model for you in one visual!

Perform a simple segmentation with the "Top Segments" visualization in Power BI (source: own production)
Perform a simple segmentation with the "Top Segments" visualization in Power BI (source: own production)

The good thing though is that there is a marketplace for charts in Looker too, although many are not an officially supported Google product.

Looker is basically a big and transparent SQL runner machine.

(Looker 2:5 Power BI)

I love that Looker always runs and easily shows you the BQ SQL queries to create the table you see under your visualization and then uses it to create your visualization on top (although if not handled properly, running these queries can easily become costly).

SQL tab shows you the query ran against your data warehouse right under the visual (source: own production)
SQL tab shows you the query ran against your data warehouse right under the visual (source: own production)

You can very easily click on the SQL tab in Looker and see the exact query that is ran against your data warehouse, which is super helpful for debugging and seeing which tables in your data warehouse are being used to build the visualization.

My tip for debugging is to copy the SQL query for your visual, and use generative AI (like Claude or ChatGPT) to ask questions about the potential problems.

In Power BI, accessing the underlying queries requires additional steps, such as using Performance Analyzer or external tools like DAX Studio.

Formatting charts is a little tedious in Looker.

(Looker 2:6 Power BI)

The formatting options for how your charts look aren’t as strong as with Power BI.

Microsoft has been upping their game in terms of customization of the charts you create in Power BI, with a lot of different click-and-choose drop down menus you set up for your charts when you build them pretty much for anything you can think about.

Editing any chart in Power BI is simple with click-and-choose drop down menus (source: own production)
Editing any chart in Power BI is simple with click-and-choose drop down menus (source: own production)

I’m not saying that what you can do in Power BI, you can’t in Looker – rather that in Power BI, the conditional formatting, targets, goal setting, axis, fonts, headers, and basically all aspects of any visual can be adjusted with a simple drop-down menu.

You can also adjust the look of a specific metric in your Power BI visualization without changing the appearance of the entire chart or table – this allows you to make precise edits to just the metric you’re focusing on.

Conditional formatting, targets, and goal setting can be simply edited with drop-down menus in Power BI (source: own production)
Conditional formatting, targets, and goal setting can be simply edited with drop-down menus in Power BI (source: own production)
Conditional formatting, smooth lines, gridlines of all types like dashed, dots, or full lines can be edited in Power BI easily as well (source: own production)
Conditional formatting, smooth lines, gridlines of all types like dashed, dots, or full lines can be edited in Power BI easily as well (source: own production)

For Looker, I had to write down a JSON code snippet {"backgroundColor": "#code"} to change the background color of the chart—which then also resulted in this notification shown in Looker:

"⚠️ Changes have been made in the Chart Config Editor. Editing visualization settings may cause unexpected behavior."

Error when adjusting the background of the chart in Looker using json code snippet (source: own production)
Error when adjusting the background of the chart in Looker using json code snippet (source: own production)

Looker’s git version control is built-in and easy to use.

(Looker 3:6 Power BI)

I love the built-in version control in Looker, as it’s very intuitive and easy to use – you don’t have to leave Looker.

If you decide to model, edit, or create new dimensions and measures, you start with turning on the Development Mode – this will allow you to set your own development area so you won’t impact anything in production.

You then create your own personal (or shared) branch directly in Looker and work on your LookML code.

Git-version control in Looker is built-in and easy to use (source: own production)
Git-version control in Looker is built-in and easy to use (source: own production)

After that you can simply publish your branch to your remote repository (Github) and then create PR for merging your new branch to the main one.

Data modeling with LookML ensures consistent measures and dimensions across the organization.

(Looker 4:6 Power BI)

Looker is amazing, and I like its approach to centralized data modeling using the proprietary LookML language.

LookML code allows you to be consistent with your definitions across your organization. What this means in practice is that because we all write everything in one language as data analysts/scientists, we all end up using the same measures and dimensions that are defined and approved by our team. In simple terms, Looker lets you build content on top of pre-modeled data in your data warehouse.

Dimensions and measures in your views (=tables) are defined with LookML which ensures one definition accross different models (source: own production)
Dimensions and measures in your views (=tables) are defined with LookML which ensures one definition accross different models (source: own production)

Your average employee won’t be able to define the data model inside, but will be able to use this data freely. This is suppose to create the single source of truth everybody in the organization wants.

Technically, when you change a definition of a metric in your business, you should be able to edit your LookML in one place, and all explores, looks, and dashboards where that metric is used will auto-update too.

What I also like about Looker is that you can make SQL edits using the sql: parameter in LookML when you create your views (views mirror the tables loaded from your data warehouse to Looker).

Looker’s workflow promotes data exploration before building dashboards.

(Looker 5:6 Power BI)

Although the comparison is not 1:1, Power BI’s development flow stages:

  • Reports → Dashboards → Apps

…would be the ones resembling Looker’s as following:

  • Explores → Looks → Dashboards.

I find Looker’s approach more intuitive because it allows for better exploration of data before building your dashboards:

  1. In Looker, you start with Explores which enable interactive EDA using ad-hoc queries.
Explore example in Looker - in the "Explore" section you can decide whether you save your view as a Look or directly into your dashboard (source: own production)
Explore example in Looker – in the "Explore" section you can decide whether you save your view as a Look or directly into your dashboard (source: own production)
  1. You can then save the charts you build using these explorations as Looks – these **** are reusable and you can append them to any dashboard.
Look example in Looker - the Look is the building block for any dashboard (source: own production)
Look example in Looker – the Look is the building block for any dashboard (source: own production)
  1. These Looks including charts can after be puzzled together into Dashboards for a full overview of your key metrics.
Simple dashboard example in Looker (source: own production)
Simple dashboard example in Looker (source: own production)

I love Explores in Looker because they give anyone in the organization the superpower to dive deep into the data without knowing SQL. When you as a Looker developer prepare an Explore for consumption, it enables finance specialists, marketing managers, revenue directors – really anyone – to interact with the prepared views within that specific Explore. They don’t need technical expertise or knowledge of SQL – they can ask their own questions and get immediate answers by pivoting, slicing, and filtering.

This layer that exists in Looker before the dashboards are put into production is definitely a big plus for Looker compared to Power BI.

In Power BI, while users can interact with reports and apply filters, creating new analyses often requires building new reports or having more advanced skills.

The ad-hoc exploration option for anyone when using Looker is a very useful tool to have at your organization.

Power BI is free to use – Looker is not.

(Looker 5:7 Power BI)

Although there is a free tool called Looker Studio, it differs significantly from the full-featured Looker enterprise BI platform – and this makes it quite challenging to learn Looker.

However, what I found helpful for gaining hands-on experience with Looker were the interactive Google Cloud Labs (these allow you to try Looker in simulated, time-limited sessions – plus, completing these labs can earn you a Google badge!).

Power BI Desktop can be downloaded totally for free as a standalone desktop app, and its paid enterprise version is more cost-effective compared to Looker where costs can spiral as your analytics team grows.

Gartner says Power BI is the choice at the moment.

(Looker 5:8 Power BI)

According to Gartner’s 2024 Magic Quadrant for Analytics and Business Intelligence Platforms, Microsoft‘s Power BI stands out for its integration within the Microsoft ecosystem, functionality, and affordability.

Magic Quadrant for Analytics and Business Intelligence Platforms crowns Microsoft as a leader (source: own production; scoring from Gartner, Inc 2024; link here)
Magic Quadrant for Analytics and Business Intelligence Platforms crowns Microsoft as a leader (source: own production; scoring from Gartner, Inc 2024; link here)

My preference as a Senior Data Analyst.

I’ve been a heavy Power Bi user for 4–5 years, and I think it’s a fantastic tool. It’s easy to use, packed with features, and great for people who want to jump in and start building. Functionality-wise, I prefer Power BI.

But now that I’ve transitioned to Looker and spent time understanding how it works, I’m starting to see how Looker could potentially become my #1 BI tool I’ll be using in the future.

Why would I say that if I scored Power BI functionally better? It all comes down to the company’s context (as Gartner research says as well).

If more companies start adopting BQ and its cloud market share grows, it creates a kind of lock-in effect. Even if you change jobs, you’re likely to encounter Looker again. So your #1 BI tool will be decided for you (the same thing can be of course said the other way around for Azure and PowerBI).

Before this, I used to work at Zensai (formerly LMS365), where we relied heavily on the Microsoft ecosystem – even our product was built into Microsoft. But now at Trustpilot, Looker makes more sense because we’re on Google Cloud Platform (GCP) – you can read more on how we use GCP here.

If your company is already using GCP and BigQuery, Looker integrates beautifully. It simplifies everything – from exploring data and creating charts to debugging issues. It’s not perfect (I could do without the lack of customization options, random errors, slowness from being web-based, and the need to write LookML code for pretty much everything), but in a Google Cloud environment, I think Looker is a great option as it turns into a very SIMPLE tool for creating charts, EXPLORING your data PRIOR to building your dashboards, as well as DEBUGGING very quickly – qualities I prioritize the most in any visualization tool.

That said, the choice between Power BI and Looker really depends on what your company uses for its 1) data warehouse, 2) human resources, 3) previous employee experiences, and your 4) financial resources.


PS: Here’s a decision-making framework table with a checklist format to guide you on choosing between Power BI and Looker.

Check whether you should get Power BI or Looker at your organization (source: own production)
Check whether you should get Power BI or Looker at your organization (source: own production)

Thank you for reading. If you enjoyed this review or learned something new, please clap and follow me for more. Feel free to connect and reach out to me on LinkedIn.


Related Articles