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

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.

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.

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}
.

Looker expressions are used for creating:
- custom dimensions
- custom calculated columns
- custom measures
- and custom filtering
…within the Looker explore interface.

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.

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.

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

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!

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.

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.

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.

Power BI outperforms Looker with chart options.
(Looker 1:5 Power BI)
With Power BI, you have more default charts to choose from.

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

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).

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.

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.


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."

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.

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.

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:
- In Looker, you start with Explores which enable interactive EDA using ad-hoc queries.

- You can then save the charts you build using these explorations as Looks – these **** are reusable and you can append them to any dashboard.

- These Looks including charts can after be puzzled together into Dashboards for a full overview of your key metrics.

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.

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.

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.