多數 BI 專案失敗，不是因為圖表畫錯了。它們失敗的方式，就像一台共用硬碟被塞滿——一次一個小決定，慢慢堆積起來。有人先買了幾個 Power BI Pro 席位，某個團隊發布了一張儀表板，想看的人越來越多，結果一年之內，續約報價就比資料團隊的薪水還高。另一些人走得更遠，然後停滯：儀表板能用，但資料必須流進 Microsoft Fabric，而要把資料搬出來，感覺就像搬遷一整間辦公室。還有第三種人根本沒開始，因為重建兩年份的 DAX 量值，看起來就像要花上一整個季度的工作量。
Power BI 並不是爛產品。截至 2026 年 10 月，它可說是全世界使用最廣泛的語意層——微軟在 9 月下旬表示，每天有超過 2,200 萬個 Power BI 語意模型在被使用。但會去搜尋替代方案的人，通常都是被某個特定的問題逼出來的，而每個問題都有不同的解法。本指南就是依此架構編排的。
問題一：每一位檢視者都是一個付費席位
財務部門遇到的第一個意外，是 Power BI 沒有免費的分享層級。在本機建置報表是免費的，但只要同事一在服務中打開它，就需要授權。微軟的定價頁面（於 2026 年 10 月查核）列出 Power BI Pro 為每位使用者每月 $14，Premium Per User 為 $24，兩者皆按年計費；要閱讀共用報表，一般都需要 Pro 以上的層級。唯讀的檢視者可以透過 Fabric 容量來服務，但那是以運算量而非人數計價——對小型團隊來說，容量費用往往超過它所取代的席位。每一位只想看一個數字的經理，都會變成帳單上一筆永久性的支出。
解法是把 Power BI 綁在一起的兩件事拆開：撰寫儀表板，以及讓別人檢視它們。開源工具切斷了這個連結。Metabase 通常是起步首選——自架版免費且開源，它直接查詢你原本就在跑的資料庫（Postgres、MySQL、BigQuery、Snowflake 等等），並讓非技術背景的人用點選的方式建立問題，完全不必看到 SQL。它沒有按檢視者計費的計量器；成本就是伺服器，通常是一台小型執行個體。它付費的雲端方案，服務的是不想自架的團隊，但免費版是完整產品，不是被閹割的試用版。
Apache Superset 用開發者的口吻提出同樣的主張。它完全開源，由 Apache 軟體基金會託管，內建 40 多種視覺化類型，適合高度依賴 SQL 的團隊。如果抱怨的重點單純是授權會隨人數成長，那麼這兩套工具都能拿掉那個計量器。我們在 SPSS 替代方案 指南中，也為付費的學術軟體做過類似的主張。
你的資料一定得住在微軟的雲端裡嗎？
2026 年的 Power BI 不是一套獨立工具，而是 Microsoft Fabric 裡的一個介面。2026 年 9 月下旬在巴塞隆納舉行的 FabCon 與 SQLCon 主題演講把這件事正式化了：微軟將 Power BI 的「下一個篇章」描述為報表、應用程式、語意檢視與 Copilot 全都跑在 OneLake 上，而自然語言應用程式建置功能會率先提供給 Fabric 容量、Pro 與 Per User 客戶。這並非全都是綁定——微軟也承諾投入 Apache Ossie（孵化中），這是一項與 Snowflake 合作的社群計畫，旨在讓語意中繼資料能在不同 BI 平台之間攜帶，這顯示有一天量值定義或許能在不必重建的情況下搬移。但預設的拉力是向內的：你的資料、它的意義，以及你的 AI 功能越深入微軟的技術堆疊，就越難離開。
可自架的替代方案則反其道而行。Metabase 與 Superset 是就地查詢你既有的資料倉儲，而不是把資料複製到供應商的雲端——Superset 自家的說法是，它「不需要再一層資料匯入」，而且能連上任何 SQL 資料庫，從 Postgres 到 PB 級規模的引擎皆可。至於營運與時序儀表板，Grafana 是另一道逃生門：完全開源的自行架設，或使用 Grafana Cloud，其免費方案涵蓋 10,000 個作用中時序、保留 14 天，付費方案則從每月 $19 的平台費起算。
這些都不是毫無摩擦的。Looker Studio（現已併入 Google 的 Data Studio，並有連接器可連上超過 1,400 個來源）免費，且直接讀取 BigQuery 與 Sheets，但它讓你對 Google Cloud 的依賴更深。Grafana 的託管路徑，則讓你對 Grafana Labs 的依賴更深。沒有無重力的選項——只能選擇你接受哪一家供應商的重力，以及你讓多少東西留在自己掌控的基礎架構上。
移轉是 DAX 問題，不是拖放問題
這才是團隊留下的真正原因，而它跟圖表無關。Power BI 的建模語言 DAX，以及它的 .pbix 格式，都是專有的。你無法在 Metabase 或 Superset 中打開 .pbix。模型定義可以被匯出——微軟的 TMDL 與 PBIP 格式會把它以文字形式攤開——但量值與每一個視覺元素，都得對照來源資料庫以手工重建。一個累積了三年巢狀 DAX 的團隊，面對的是一整個季度，而不是一個週末。
所以，別全面移轉——選擇性地搬。挑出人們真正會打開的儀表板，在 Metabase（它會儲存可重複使用的模型，並讓你在問題變複雜時直接貼上 SQL）或 Superset 的 SQL Lab 中重建這些，其餘的長尾就先留在 Power BI 裡，直到續約再說。至於最耗時的部分——把 DAX 量值轉成資料倉儲的 SQL——通用型助理能幫上忙：貼上量值，請它給出等效的 SQL，然後拿新數字去跟舊儀表板核對，精確到分。把助理用來翻譯，絕不要用來計算。
Google 的 Gemini（圖片來源：Google）是你可以用來請它把 DAX 量值翻譯成 SQL 的助理之一——用來改寫很有用，當作真相來源則毫無用處。每一個數字都要跟你正在取代的那張儀表板核對過。
| 當問題是…… | 能解決它的工具 | 最適合 |
|---|---|---|
| 授權成本隨檢視者增加而攀升 | Metabase（免費自架）或 Apache Superset | 能跑一台小型伺服器、不想付按檢視者計費的團隊 |
| 資料不能離開你的資料倉儲 | 自架的 Metabase、Superset 或 Grafana | 受監管、歐盟或氣隙隔離的環境 |
| 得手工重建 DAX 與報表 | Metabase 模型 + SQL，或 Grafana 處理時序 | 只想搬幾張關鍵儀表板、而非整個資產的團隊 |
不必啟動移轉專案就能上手的三個步驟
把授權數跟檢視者數對一對。 拉出真正會打開報表的人員名單，把作者與讀者分開，再把讀者人數乘以 Pro 的價格。那個數字就是你正在保住的預算，通常也決定了這一切切換到底值不值得。
讓一張儀表板並行運作。 拿一個唯讀副本（絕對不要用正式環境）架起 Metabase 或 Superset，在 Power BI 仍照常運作時重建一張高流量的儀表板。一個月的並排數字，會告訴你團隊到底會不會用這套新工具。
搬前三大，其餘留著。 只重建檢視者最多的那幾張儀表板，把每個數字跟原始版本核對過，其餘的留到續約再說。如果你整體的技術堆疊也在移動，我們的 企業 AI 工具 彙整涵蓋了周邊的相關決策，完整的目錄則在 /tools/。
大家在切換前會問的問題
我可以在別的 BI 工具裡打開我的 .pbix 檔嗎？ 不行。這個格式是專有的，Metabase 與 Superset 都不會匯入它。你得對照來源資料重建，這就是為什麼搬幾份報表可行，而一次性大搬遷行不通。
Metabase 還是 Superset 是更好的第一步？ 如果報表建置者是偏好拖拉欄位的分析師，選 Metabase；如果是寧可寫 SQL 的工程師，選 Superset。
Looker Studio 真的免費嗎？ 報表工具免費，但 BigQuery 背後的儲存與運算，你還是得付錢給 Google。工具免費，資料倉儲要付費。
離開 Power BI 後，我會失去即時儀表板嗎？ 未必。Grafana 就是為了串流與時序資料而打造，在即時營運檢視上勝過 Power BI；你失去的是與 Microsoft 365 的緊密整合。
價格已於 2026 年 10 月上旬對照微軟的 Power BI 定價頁面、metabase.com、superset.apache.org、grafana.com 以及 cloud.google.com/looker-studio 查核；2026 年 9 月的「下一個篇章」細節來自微軟的 Power BI Updates Blog。價格與免費方案會變動——請以官方頁面為準。