Power BI đã chết? Chiếc xe của bạn đã trả lời câu hỏi này rồi.

English | Tiếng Việt

Cứ vài tháng, lời tuyên bố này lại quay lại: dashboard đã chết. Việc gì phải xây báo cáo khi bạn có thể hỏi thẳng AI về số liệu của mình? Có người còn nói mạnh hơn: “Power BI đã chết.” Đó là một tiêu đề hay và một lời khuyên tồi. Bằng chứng mạnh nhất chống lại nó đến từ chính các hãng công nghệ — và từ chiếc xe của bạn.

Các hãng đang thực sự làm gì

Nếu chat thay thế được BI, thì Microsoft và Databricks đã phải thu hẹp mảng BI của họ. Điều ngược lại đang diễn ra.

Microsoft đang đưa Copilot vào trong Power BI: “Chat with Your Data” là trải nghiệm hỏi đáp trả lời câu hỏi về một báo cáo hoặc mô hình ngữ nghĩa — nó đứng trên nền BI, không đứng cạnh để thay thế. Tính năng Q&A cũ đang được cho nghỉ hưu để nhường chỗ cho Copilot, và chính tài liệu của Microsoft nói thẳng điều gì làm cho chat trả lời tốt: một mô hình ngữ nghĩa được chuẩn bị kỹ, cấu trúc sạch, tên gọi rõ ràng, có mô tả. Databricks đi cùng một hướng với Genie: câu hỏi bằng ngôn ngữ tự nhiên được trả lời trên dữ liệu đã được tuyển chọn, có quản trị, kèm ngữ cảnh kinh doanh.

Nói cách khác: ngành này không thay dashboard bằng chat. Họ xây chat trên cùng một nền móng mà dashboard đang dùng.

Phép thử chiếc xe

Hãy nghĩ về cách bạn lái xe.

Xe của bạn có bảng đồng hồ: tốc độ, xăng, nhiệt độ máy, áp suất lốp. Bạn không bao giờ phải hỏi những thứ này. Bạn liếc mắt. Bảng đồng hồ tồn tại chính xác để những câu hỏi bạn luôn luôn có được trả lời trước khi bạn hỏi. Dashboard sinh ra để làm việc đó: nó bỏ đi gánh nặng phải hỏi đi hỏi lại những câu tiêu chuẩn. Chỉ số cứ nằm sẵn ở đó.

Giờ tưởng tượng điều ngược lại: một chiếc xe mà mỗi lần muốn biết tốc độ, bạn phải hỏi thành tiếng “tôi đang chạy bao nhiêu km/h?”. Không ai mua chiếc xe đó. Mà đó chính là điều “bỏ hết báo cáo, chỉ cần chat” đang đề xuất.

Nhưng bảng đồng hồ có giới hạn, và bạn cũng biết điều đó từ việc lái xe. “Với chỗ xăng còn lại, tôi có lên được Đà Lạt không?” Không bảng đồng hồ nào có kim cho câu hỏi đó. Đó là câu hỏi tình huống: phụ thuộc ngữ cảnh, và bạn hiếm khi hỏi. Đây chính là chỗ lớp hỏi đáp tỏa sáng — bạn hỏi bằng lời của mình, và nhận câu trả lời tính riêng cho tình huống của bạn.

Hai giao diện, một bộ cảm biến:

  • Dashboard trả lời các câu hỏi thường trực: hai mươi chỉ số bạn xem mỗi ngày, giống nhau cho mọi người, không tốn công để đọc. Doanh thu tháng này, khách chưa trả tiền, tồn kho, sản lượng.
  • Chat với dữ liệu trả lời phần đuôi dài: câu hỏi một lần, đào sâu, “sao con số này khác tháng Ba năm ngoái?” Bạn không bao giờ xây sẵn một trang báo cáo cho từng câu như vậy; chúng quá nhiều.

Dùng chat cho chỉ số hằng ngày là hỏi xe “tôi chạy bao nhiêu km/h”. Nhét hai trăm biểu đồ vào một báo cáo để trả lời trước mọi câu hỏi có thể có là in cả cuốn hướng dẫn sử dụng lên bảng đồng hồ. Mỗi công cụ có việc của nó.

Tiêu đề thật sự: mô hình ngữ nghĩa quan trọng hơn bao giờ hết

Đây là phần mà phe “dashboard đã chết” bỏ sót. Cả hai bề mặt — báo cáo và chat — đều đọc từ cùng một mô hình ngữ nghĩa: lớp định nghĩa “doanh thu” nghĩa là gì, các bảng liên kết ra sao, chỉ số nào là chính thức.

Trong xe, đồng hồ tốc độ và máy tính quãng đường đọc cùng một bộ cảm biến. Cảm biến hỏng thì cả hai cùng nói dối bạn. Dữ liệu cũng vậy: nếu mô hình lộn xộn — logic trùng lặp, tên gọi khó hiểu, không có mô tả — dashboard đánh lừa bạn một cách im lặng, còn chat đánh lừa bạn một cách đầy tự tin. AI trả lời trên một mô hình tồi không nói “mô hình của bạn không rõ ràng”; nó đưa cho bạn một câu trả lời trôi chảy, nghe hợp lý, và sai.

Vì vậy mọi hướng dẫn nghiêm túc về AI trong BI đều nói cùng một điều: chuẩn bị mô hình. Star schema sạch. Mỗi định nghĩa kinh doanh một chỉ số. Mô tả và metadata trên bảng, cột, chỉ số, để cả người lẫn AI hiểu mọi thứ nghĩa là gì. Mô hình được chứng nhận, có quản trị, thay vì mỗi phòng ban một file xuất riêng.

Cho nên cả chồng công nghệ không teo lại; nó xếp lại thứ tự. Mô hình ngữ nghĩa đi từ một chi tiết kỹ thuật thành tài sản dữ liệu giá trị nhất mà công ty sở hữu. Xây một lần, xây cho tốt, và nó nuôi cả hai bề mặt — mọi báo cáo hôm nay, và mọi tính năng AI ngày mai.

Điều này nghĩa là gì trong thực tế

Với doanh nghiệp vừa và nhỏ, thứ tự thực tế là:

  1. Bắt đầu bằng báo cáo. Đưa toàn bộ doanh nghiệp — tài chính, bán hàng, vận hành — lên một bộ báo cáo rõ ràng, đáng tin, xây trên một mô hình ngữ nghĩa sạch. Giá trị tức thời nằm ở đây, và nó buộc phần nền móng phải đúng.
  2. Thêm chat như bước tiếp theo. Khi mô hình đã đáng tin, thêm lớp hỏi đáp ngôn ngữ tự nhiên lên trên chỉ là một bước vừa phải, và câu trả lời thừa hưởng chất lượng của mô hình — kể cả bằng tiếng Việt.
  3. Cảnh giác với lời chào “chat trước đã”. Nếu ai đó hứa “cứ hỏi dữ liệu của bạn bất cứ điều gì” mà không nói về mô hình bên dưới, hãy hỏi họ: khi hai bảng cho hai con số doanh thu khác nhau thì sao? Giao diện chat là 10 phần trăm nhìn thấy được; mô hình là 90 phần trăm quyết định câu trả lời có đúng hay không.

Dashboard không chết. Nó có thêm một đồng nghiệp. Và cả hai cùng phụ thuộc vào một thứ: một mô hình ngữ nghĩa xứng đáng với niềm tin bạn đặt vào nó.

Synnoia xây báo cáo quản trị và lớp hỏi đáp AI trên cùng một mô hình ngữ nghĩa có quản trị — báo cáo trước, chat là bước tiếp theo. Cuộc trò chuyện đầu tiên là miễn phí.

Is Power BI dead? Your car already answered that question.

English | Tiếng Việt

Every few months the claim comes back: dashboards are dead. Why would anyone build reports when you can simply ask an AI about your data? Some go further: “Power BI is dead.” It is a good headline and bad advice. The strongest evidence against it comes from the vendors themselves — and from your car.

What the vendors are actually doing

If chat were replacing BI, you would expect Microsoft and Databricks to be winding their BI stacks down. The opposite is happening.

Microsoft is building Copilot into Power BI: “Chat with Your Data” is a chat experience that answers questions about a report or semantic model — it sits on top of the BI stack, not beside it. The old Q&A feature is being retired in favor of this, and Microsoft’s own guidance is blunt about what makes the chat good: a well-prepared semantic model, with clean structure, clear names, and descriptions. Databricks follows the same pattern with Genie: natural-language questions answered over curated, governed data with business context attached.

In other words: the industry is not replacing the dashboard with chat. It is building chat on top of the same foundation the dashboard uses.

The car dashboard test

Think about how you drive.

Your car has a dashboard: speed, fuel, engine temperature, tire pressure. You never ask for these. You glance. The dashboard exists precisely so that the questions you have all the time are answered before you ask them. That is what a dashboard is for: it removes the cognitive load of asking the same standard questions again and again. The KPI is just there.

Now imagine the opposite: a car where you must ask, out loud, “how fast am I going?” every time you want to know. Nobody would buy that car. That is what “replace all reports with chat” actually proposes.

But the dashboard has a limit, and you know it from driving too. “With the fuel I have left, can I still make it to Đà Lạt?” No dashboard has a gauge for that. It is an ad-hoc question: it depends on context, and you ask it rarely. This is exactly where a conversational layer shines — you ask, in your own words, and get an answer computed for your situation.

Two interfaces, one set of sensors:

  • The dashboard answers the standing questions: the twenty KPIs you check every day, identical for everyone, zero effort to consume. Revenue this month, unpaid invoices, stock level, production output.
  • Chat with your data answers the long tail: the one-off, the drill-down, the “why is this number different from last March?” You would never pre-build a report page for each of those; there are too many.

Using chat for your daily KPIs is asking the car for your speed. Cramming two hundred visuals into a report to pre-answer every possible question is printing the whole owner’s manual on the dashboard. Each tool has its job.

The real headline: the semantic model matters more than ever

Here is the part the “dashboards are dead” crowd misses. Both surfaces — the report and the chat — read from the same semantic model: the layer that defines what “revenue” means, how the tables relate, which measure is the official one.

In a car, the speedometer and the range computer read the same sensors. If a sensor is broken, both lie to you. It is the same with data: if the model is messy — duplicated logic, unclear names, no descriptions — the dashboard misleads quietly, and the chat misleads confidently. An AI answering questions over a bad model does not say “your model is unclear”; it gives you a fluent, plausible, wrong answer.

That is why every serious guide to AI-in-BI says the same thing: prepare the model. Clean star schema. One measure per business definition. Descriptions and metadata on tables, columns, and measures, so both a human and an AI know what things mean. Certified, governed models rather than one export per department.

So the stack does not shrink; it re-orders. The semantic model moves from a technical detail to the most valuable data asset a company owns. Build it once, build it well, and it feeds both surfaces — every report today, and every AI feature tomorrow.

What this means in practice

For a small or medium business, the practical order is:

  1. Start with the reports. Get your whole business — finance, sales, operations — onto one clear, trusted set of reports, built on a clean semantic model. This is where the immediate value is, and it forces the foundation to be right.
  2. Add chat as the next level. Once the model is trustworthy, a natural-language layer on top is a modest step, and the answers inherit the model’s quality — including in Vietnamese.
  3. Be suspicious of chat-first offers. If someone promises “just ask your data anything” without talking about the model underneath, ask them what happens when two tables disagree about revenue. The chat interface is the visible 10 percent; the model is the 90 percent that decides whether the answers are true.

The dashboard is not dead. It got a colleague. And they both depend on the same thing: a semantic model that deserves the trust you put in it.

Synnoia builds business reporting and AI question layers on one governed semantic model — reports first, chat as the next level. The first conversation is free.

Microsoft Fabric vs Databricks in 2026: An Honest Place to Start

Two names come up in almost every data conversation we have: Microsoft Fabric and Databricks. This is the first part of a short series where we compare them the way we actually see them on projects, with no vendor spin. We start with the basics: what each one is, where Power BI fits, and why so many teams are stuck on the choice.

The question we keep hearing

“Should we build on Microsoft Fabric or Databricks?” We hear it from finance directors, from IT managers, and from founders who have just been told their Excel files are holding the company back. It is a fair question, and the honest answer is that it depends on your data, your team, and your budget, not on which brand is louder this year.

This series is our attempt to answer it properly. We build on both platforms, so we have no reason to sell you one over the other. In this first part we set the scene. In the next parts we go deep on each platform’s strengths and weaknesses, on how the two are converging, and finally on a simple way to decide.

What Microsoft Fabric is

Microsoft Fabric is a single, unified data platform. It brings data engineering, data storage, modelling, and reporting into one place, on top of shared storage called OneLake. Crucially, Power BI is now a part of Fabric, so the reports your business already knows live in the same platform as the pipelines that feed them.

Fabric is new. Microsoft launched it in November 2023, which makes it about two and a half years old as we write this. That youth cuts both ways, and we will be specific about it in part two. What matters here is the shape: one platform, low-code and professional-code side by side, with the best business-intelligence experience on the market built in.

What Databricks is

Databricks is older and was built from a different starting point. It was founded in 2013 by the creators of Apache Spark, and it grew up serving serious data engineering and machine-learning teams. It is a lakehouse platform: open data formats, large-scale processing, and a deep set of tools for engineers and data scientists who want full control.

If Fabric’s instinct is “make it approachable for everyone”, Databricks’ instinct is “give the engineers real power”. Both instincts are valuable. They just serve different rooms.

Where Power BI fits, and why it is not a third option

This trips people up, so we will be blunt. Power BI is not a third platform competing with Fabric and Databricks. Power BI is the reporting layer, the thing that turns modelled data into dashboards people actually open. It is very popular, and rightly so. But on its own it is not a data platform, and it cannot do the engineering work underneath.

The clean way to see it: there are two platforms, Microsoft Fabric and Databricks, and one shared reporting surface, Power BI, that can sit on top of either. When we say “Microsoft Fabric”, Power BI is already included. When we build on Databricks, we usually still put Power BI on top for the reports.

Why the choice feels hard

The choice feels hard because both platforms are good, and because they are moving toward each other. Databricks is adding stronger reporting and operational features. Fabric is adding stronger engineering features. Both are racing to embed artificial-intelligence agents directly into the platform so that more of the building can be described in plain language. We will spend a whole part of this series on that convergence, because it changes the honest answer.

For now, hold three simple ideas:

  • Fabric is the most approachable and the cheapest to start, and it is unbeatable if your world is already Microsoft and Power BI.
  • Databricks is the most powerful for heavy, complex engineering and machine learning, and it scales without flinching.
  • You do not always have to choose. A hybrid, Databricks underneath and Fabric for the last mile and the reports, is a real and increasingly common shape.

How we will decide, later in this series

By the last part we will give you a short checklist: how much data, how complex the pipelines, how much machine learning, how Microsoft-aligned your team is, and how tight the budget is. Those five questions settle most cases. If you cannot wait for the series, that list is also the fastest way to start a conversation with us.

In part two, we look hard at Microsoft Fabric on its own: what it is genuinely great at today, and where its youth still shows.

This is part one of a five-part series. Synnoia builds on both Microsoft Fabric and Databricks, and delivers reporting through Power BI. The first conversation is free.

How to connect Power BI Dataflows to Excel

Power BI dataflows (PBI dataflows) is a powerful data prep tool for you to transform data and reuse them in other places downstream. At the same time, while Excel is very popular among business users, there is still, at the time of writing this post, no out-of-the-box connector to import PBI dataflows to Excel. This post aims to solve that pain point.

This post also proposes an alternative to the existing PBI dataflows connector to Power BI Desktop to push the users’ access control to the table level, instead of workspace level like the current connector.

Continue reading “How to connect Power BI Dataflows to Excel”

The Excel Connectors in Power BI

Like it or not, Excel is one of the most popular data sources to build Power BI reports. Surprisingly, except for when you want to connect to an Excel file that is located on your local laptop or a shared network drive, there is no easy way for users to connect to an Excel file that is hosted on cloud services via the Power BI’s user interface (UI).

This blog post will provide you with a universal M script, which you can use to connect to Excel files hosted on not only on-prem sources but also cloud environments, such as OneDrive for Business, SharePoint, and Google Sheets (both public and private). You can download the pbit file in my GitHub repository for a quick start.

Continue reading “The Excel Connectors in Power BI”

Power BI dataflows to store historical data

Power BI dataflows is a nice capability of Power BI. It’s actually not a new Microsoft product. If you use Excel and Power BI long enough, there is a big chance that you’ve already used Power Query at least once. And basically, to keep things simple, it’s just Power Query, but you have to edit it on a web-browser, in Power BI Service.

Pro license is your entrance ticket to use this nice capability. Although Premium licenses (per capacity or per user) provide more advanced features, many applications of Power BI dataflows are already available with Pro license. One of them is to store historical data, and of course, to show them in reports.

In this blog post, I will briefly introduce Power BI dataflows (with some useful links if you want to learn more). Next, I’ll share how to store historical data in your own storage account and show both current and historical data in a Power BI Report (with ready M scripts, and a pbit file posted on my GitHub repository), so you can roll up your sleeves and start right away with your own use case!

Continue reading “Power BI dataflows to store historical data”

Difference between Power BI Service and Power BI Report Server

To my surprise, I’ve met many non-tech people and even some from IT who are confused between the two “same same but different” versions of Microsoft Power BI: Power BI Service (cloud version) and Power BI Report Server (on-premise version[1]) .


In this post, I’ll share some tips for non-BI people to identify which version they are using. Then, I’ll provide a holistic comparison of the two versions, hoping to make you more informed of choosing the version that suits your situation best.

Continue reading “Difference between Power BI Service and Power BI Report Server”