Power BI no es la respuesta (aunque toda la industria lo pida)

Abrís LinkedIn y la mitad de las búsquedas de "analista de datos" o "ingeniero BI" piden Power BI. Lo piden contadores, lo piden gerentes, lo piden RRHH que ni saben qué es DAX. Es el default por inercia: Microsoft lo empujó dentro de Office 365, las consultoras lo certifican, y nadie se anima a cuestionarlo.

Voy a cuestionarlo.

Power BI es una herramienta cara, cerrada, lenta de evolucionar y diseñada para que nunca te puedas ir. No lo digo desde el resentimiento — lo digo con números, fuentes oficiales, y comparativas técnicas frente a stacks que ya están corriendo en producción en empresas más grandes que las que te están pidiendo Power BI.

Si sos developer, ingeniero de datos, contador con background técnico o founder de SaaS, este post es para vos.

El gancho: lo que cuesta hoy

El 1 de abril de 2025 Microsoft subió los precios de Power BI un 40% — el primer aumento global desde 2015. Estos son los números actuales, en USD, sacados directo del pricing oficial de Microsoft y de Azure Fabric pricing:

Producto	Precio	Notas
Power BI Pro	$14/usuario/mes (antes $10)	Imprescindible para autores y para que los viewers consuman cualquier contenido en capacity menor a F64
Power BI Premium Per User (PPU)	$24/usuario/mes	Habilita modelos hasta 100 GB
Microsoft Fabric F64 (= antiguo P1)	~$8,410/mes PAYG / ~$4,991/mes reservado	Único umbral que permite viewers gratis
Fabric F256 (= P3)	~$33,640/mes PAYG
Power BI Embedded A1 (legacy)	~$735/mes	~300 renders/hora

Lo que vale la pena entender es el "F64 cliff": por debajo de F64, cada viewer sigue necesitando una licencia Pro de $14/mes. 200 viewers internos = $2,800/mes solo en licencias antes de pagar capacity, almacenamiento o gateways.

Y para colmo, Microsoft dejó de vender los SKUs P en julio 2024: todos los nuevos clientes deben ir a Fabric F SKUs facturados via Azure. Si tu empresa estaba cómoda con un P1, ya no existe ese mundo.

A esto sumale la dependencia de tenant: Power BI requiere Microsoft Entra ID (Azure AD). Sin tenant Microsoft 365 no creás workspace, no compartís contenido, no autenticás usuarios Pro. Compartir externamente exige B2B guest invites en tu tenant Entra. No es una herramienta — es una correa.

DAX: el lenguaje que nadie eligió

Power BI se vende como "fácil porque las fórmulas son tipo Excel". Es mentira.

DAX (Data Analysis Expressions) es uno de los lenguajes con la curva de aprendizaje más empinada del mundo BI. Los conceptos centrales — row context vs filter context y especialmente context transition — son trampas silenciosas. CALCULATE y CALCULATETABLE transforman implícitamente row context en filter context, y las funciones de time-intelligence envuelven argumentos en CALCULATETABLE/VALUES generando context transitions que el desarrollador nunca pidió.

No lo digo yo. Lo dicen Marco Russo y Alberto Ferrari, las máximas autoridades mundiales de DAX, en SQLBI:

"Row context exists within an active iteration. No iteration, no row context… Many DAX novices erroneously think that the result of the calculated column should be the value of Unit Price in the current row only."

Su libro de referencia, The Definitive Guide to DAX, tiene 806 páginas, y los propios autores escriben en la portada: "If you are a casual user of DAX, then this book is probably not the best choice for you".

Comparado con SQL, Python o Polars, DAX no tiene:

• IDE/REPL real: DAX Studio es comunitario, Tabular Editor es de terceros.
• Package manager: no hay PyPI/npm/CRAN. Los patrones se copian a mano de daxpatterns.com.
• Framework de unit testing nativo.
• Imports: cada modelo reimplementa time-intelligence desde cero.
• Debugger paso a paso, breakpoints o EXPLAIN ANALYZE.

Estás aprendiendo un lenguaje propietario, sin tooling moderno, que no te sirve fuera del stack Microsoft. SQL te sirve en cualquier warehouse del planeta. Python te sirve en cualquier industria. DAX te sirve únicamente para que sigas pagando Pro.

Git no funciona con .pbix

Esto es lo que más duele cuando venís de programación seria.

Microsoft introdujo Power BI Project files (.pbip) en junio 2023, TMDL llegó a GA, y PBIR (Enhanced Report Format) sigue en Preview en 2026. Pasa a default en Power BI Service el 25 de enero de 2026 y en Desktop en marzo 2026, con GA esperada en Q3 2026. Tres años después de empezar, todavía es preview.

Limitaciones reales documentadas (2025-2026):

• Publicar PBIR a Power BI Service hoy es restringido o imposible según consultorías independientes (bitpeak.com).
• Conversión one-way: una vez convertido de PBIR-Legacy a PBIR no se puede volver atrás.
• Deployment Pipelines rompen con .pbip — usuarios reportan errores con GUIDs vacíos.
• Round-trip bugs en julio 2025: PBIX editados con TMDL no se podían descargar de vuelta del Service tras publish.
• Diffing pobre: Eraneos (consultora Microsoft Gold) admite literalmente que "reading JSON files is possible but not ideal".
• PPU NO soporta Fabric Git Integration para items no-Power-BI; necesitás un F SKU.
• No hay deploys transaccionales: las escrituras XMLA aplican inmediatamente a producción, sin staging, sin approval workflow, sin rollback automático. Un error en una measure DAX rompe reportes para todos los usuarios al instante.

Ahora compará con un stack dbt + Python + React: cada artefacto es texto plano, cada cambio es un git diff legible, cada PR ejecuta dbt test + tests unitarios + linters en CI, cada merge despliega a un entorno preview, todo es revisable línea por línea.

El .pbix es un ZIP con DataModel, Layout, Report/section.json y Connections propietarios — formato no documentado oficialmente. No hay PR review honesto sobre un binario.

Performance: VertiPaq pierde contra el OSS moderno

VertiPaq (xVelocity) es un columnar in-memory con dictionary encoding y RLE que logra ~10× compresión sobre datos tabulares. Está bien diseñado. Pero los límites son duros y bajos:

Tier	Tamaño máximo de modelo
Pro (shared)	1 GB
PPU	100 GB (con Large Semantic Model)
Premium F64	~25 GB default / 100 GB large model
F256/P3	hasta 400 GB
F2048	hasta 720 GB

Y DirectQuery no salva la situación: cada interacción es un round-trip SQL, muchas funciones DAX están prohibidas, hay límites de 1M filas por query response, y los many-to-many de composite models tienen footguns serios.

Mientras tanto, los engines OSS modernos hacen pelota a Power BI en cualquier benchmark público:

• DuckDB H2O.ai db-benchmark (2023): "DuckDB is the fastest library for both join and group by queries at almost every data size", incluso 1B-row group-by en una MacBook Pro de 16 GB.
• Polars PDS-H (mayo 2025): a SF-10 y SF-100, "Polars and DuckDB prove to be in a league of their own, being an order of magnitude faster than Dask and PySpark".
• Coiled TPC-H multi-engine: "If you want to perform SQL queries on 100 GB of local data, DuckDB is the clear winner".

Power BI no aparece en estos benchmarks porque VertiPaq no es un engine OLAP genérico — no se puede benchmarkear fuera del stack Microsoft. Eso solo ya te dice algo.

Embebido en SaaS: el camino más doloroso posible

Si sos founder de un SaaS y querés ofrecer dashboards a tus clientes, Power BI Embedded es probablemente la peor decisión técnica que podés tomar en 2026.

El flujo de auth tiene dos caminos, ambos malos:

1. Master user: una cuenta humana real Pro/PPU ($14-$24/mes) con username + password. Microsoft mismo admite en su blog oficial que es mala práctica: "demands a Power BI Pro license to be purchased… authentication is done with a password, an authentication method that isn't aligned with AAD best practices".
2. Service principal: registro de app en Entra ID, secret o cert, agregar a security group, agregar a cada workspace, habilitar a nivel tenant admin. Y después leés en la doc oficial: "You can't access Power BI service with a service principal" para muchas operaciones.

El embed token flow es: app autentica a Entra ID (token A, expira 1 h) → app llama GenerateToken REST API para mintar embed token (token B) → embed token al browser → JS SDK carga iframe.

Y la UI siempre es un iframe. Theme JSON limitado, sin acceso CSS, sin DOM access. Custom visuals deben estar Microsoft-certificados para export-to-PDF.

Comparalo contra embeber un dashboard custom con React + shadcn/ui + Recharts:

Dimensión	Power BI Embedded	React + shadcn/ui + Recharts
Control UX	iframe — siempre se ve a Power BI	DOM nativo, indistinguible del resto del SaaS
Costo	A1 ~$735/mes; F2 ~$263/mes	$0 OSS + hosting (Vercel/Cloudflare)
Branding	Theme limitado, iframe boundary visible	100% tu design system; white-label trivial
Auth	Entra apps + embed tokens + service principals	Lo que use el resto del SaaS (Clerk, Auth.js, Supabase)
Multi-tenancy	RLS via dataset roles, datasets separados por tenant	RLS app-native en tu DB, misma sesión
Lock-in	Microsoft + Azure + DAX	OSS, portable

El cálculo TCO a 12 meses contra Power BI Embedded es brutal. Y el resultado UX es objetivamente peor — tu cliente ve que el dashboard no pertenece a tu producto.

Análisis avanzado: el path se está estrechando

Si querés ML, stats avanzadas, o simulaciones, Power BI te tira en la cara los caps oficiales de Python visuals:

• 150,000 filas máximo — más se trunca silenciosamente.
• 250 MB input data; strings >32,766 chars truncados.
• 5 min timeout en Desktop, 1 min en Service; payload total <30 MB.
• 72 DPI fijo.
• Sandboxed: sin network access, sin DB drivers (sqlalchemy, pyodbc bloqueados).
• Imagen estática — sin cross-filter al resto del reporte.
• Library list curada — paquetes privados/custom no permitidos.

Y la noticia fresca: el feature update de noviembre 2025 anuncia que a partir de mayo 2026, Power BI Embedded ("Embed for your customers") deja de soportar R o Python visuals. Post-deprecation, los charts renderizan en blanco.

Si necesitás Monte Carlo, Microsoft Q&A admite literalmente: "Monte Carlo Analysis is unsupported in Power BI". Optimización (LP/MIP), survival analysis, Bayesian inference: cero path first-party.

Power BI no es un entorno de análisis — es una capa de visualización con scripting castrado.

El stack moderno que reemplaza Power BI

No estoy diciendo "no uses BI". Estoy diciendo que el BI moderno se desbundleó: dejó de ser una suite monolítica y se convirtió en piezas componibles que ganan en cada dimensión por separado.

El paradigma se llama BI as Code: dashboards, métricas, dimensiones y reportes son texto plano (Markdown, SQL, YAML, JSX) en Git, revisables por PR, validados en CI/CD, deployables como static sites o containers.

Capa de transformación

• dbt-core (12.7k stars, Apache 2.0): transformaciones SQL+Jinja en warehouse, con tests, docs y lineage. El estándar del modern data stack.
• DuckDB (~37.5k stars, MIT): "SQLite analítico", embedded OLAP, gana TPC-H y H2O.ai benchmarks.
• Polars (~38.3k stars, MIT): DataFrame en Rust, 5-30× más rápido que pandas.

BI tools OSS (alternativas directas a Power BI)

• Metabase (~47k stars, AGPLv3 + Commercial): el más fácil de instalar (un Docker), perfecto para SMB self-serve. Lo más cercano mentalmente a Excel/Power BI para un contador.
• Apache Superset (~70k stars, Apache 2.0): el más potente, enterprise scale. Lo usan Airbnb, Netflix, Lyft, ByteDance, Microsoft Bing.
• Lightdash (MIT open core): dbt-native, "BI as code", metric definitions en YAML.
• Evidence.dev (MIT): Markdown + SQL → static site (SvelteKit). Reportes versionados en Git, deploy a Vercel/Netlify.
• Rill Data (Apache 2.0): sub-second dashboards en parquet/S3 con DuckDB embebido.

Frontend para dashboards custom (SaaS)

El stack default 2025-2026 para dashboards SaaS:

Next.js 15/16 (App Router, RSC)
 + shadcn/ui     (Radix + Tailwind copy-paste)
 + Recharts      (vía shadcn/ui Charts o Tremor)
 + TanStack Table  (data tables)
 + TanStack Query  (client data layer)
 + Drizzle/Prisma + Postgres  (Neon, Supabase)
 + Clerk / Auth.js / better-auth  (auth)
 + Vercel        (hosting, edge)

shadcn/ui tiene >90k stars y es el sistema de componentes que están adoptando OpenAI, Sonos, Adobe. Tremor fue adquirida por Vercel en octubre 2024 y es ahora la "block library" de dashboards hermana de shadcn/ui — alimenta v0.dev y el Vercel Dashboard.

Vos sos dueño del código. Theming a una CSS variable de distancia. RSC + streaming + edge da TTFB <100ms. Y v0.dev / Cursor / Claude Code generan código directamente en este stack.

Observabilidad (incluyendo sistemas multi-agente)

Para sistemas de software — APIs, jobs, agentes IA — Power BI directamente no aplica. El refresh batch (max 8x/día Pro, 48x/día Premium) lo descalifica. No hay PromQL/LogQL/TraceQL. No tiene span model. No ingiere OTLP.

El stack canónico es LGTM + Prometheus + OpenTelemetry:

• Grafana (~72k stars): multi-source dashboards, alerting.
• Loki + Tempo + Mimir: logs + traces + metrics.
• OpenTelemetry: standard CNCF vendor-neutral.

Y para LLMs / agentes: Langfuse, Arize Phoenix, Pydantic Logfire. Todos OSS, todos OTel-compatibles, todos te dan trace tree de agentes, prompts versionados, datasets de evals.

Qué camino tomar (concreto, por caso)

Caso	Qué usar	Por qué
Dashboard interno rápido para un equipo no-técnico	Metabase (un Docker)	Cero código, UI familiar, self-host trivial.
Equipo Python que ya escribe scripts	Streamlit + DuckDB + dbt	De script a app en minutos, sin DAX.
Embeber dashboards en tu SaaS	React + shadcn/ui + Recharts/Tremor + Cube.dev	Control total de UX, mismo design system, sin iframe boundary, sin Entra ID.
BI as code con Git	Evidence.dev o Lightdash	PRs con git diff exacto, CI/CD estándar, preview environments por branch.
Big data con performance real	DuckDB + dbt + Superset, o Rill Data	Engines OSS que ganan benchmarks públicos contra todo.
Observabilidad de sistemas y agentes	Grafana + Prometheus + LGTM + OpenTelemetry, + Langfuse/Phoenix para LLMs	Vendor-neutral, real-time, trace correlation nativa.
Contador con background técnico	Metabase (visualización) + dbt (modelado SQL versionado)	Reemplaza Power BI sin perder nada que un contador necesite, y agrega versionado real.

Cuándo Power BI sigue teniendo sentido

Para ser justo: Power BI sigue siendo razonable para empresas que ya están all-in en Microsoft 365 con usuarios no-técnicos que viven en Excel, no tienen equipo de ingeniería, y no necesitan embeber nada. Si ese es tu contexto, Power BI te va a servir y este post no aplica.

El problema es que la industria usa Power BI por defecto incluso cuando ese no es el contexto. Lo piden empresas con ingenieros, con SaaS, con APIs, con datos en Postgres y warehouses serios — y ahí Power BI es la peor decisión disponible.

Cierre

Power BI es lo que pasa cuando una empresa con monopolio de productividad empuja una herramienta dentro de su suite y la industria la adopta sin preguntarse si es la mejor opción técnica. Spoiler: no lo es.

• Subió 40% el último año y va a seguir subiendo.
• Te ata a Entra ID, a Fabric, a DAX, a un formato binario.
• Su tooling Git todavía es preview tres años después.
• Pierde benchmarks públicos contra DuckDB y Polars.
• Su path para ML/Python se está achicando, no creciendo.

El stack alternativo es OSS, code-first, versionable, performante, embebible y portable. No es el futuro — está corriendo en producción hoy en Airbnb, Netflix, Cal.com, Resend, Vercel, Linear, OpenAI.

Si estás del lado del que pide Power BI, te invito a revisar el costo total. Si estás del lado del que lo implementa, te invito a aprender uno de los stacks de arriba — vas a programar BI de verdad, no fórmulas dentro de un binario.

La industria se va a mover. La pregunta es cuándo te movés vos.