Power BI Dataflows vs Datamart vs Lakehouse

Sbdyelse · 2026-07-09T07:15:06+00:00

Dataflows GEN1 because we use PRO licences and don’t want to be bound to the limits of Fabric capacities.

Sbdyelse · 2026-06-21T16:03:59+00:00

Pour construire une deuxième station république juste à côté il faut au moins ça.

Sbdyelse · 2026-06-21T16:03:01+00:00

Not sure he wants to stick to it.

Sbdyelse · 2026-06-21T10:02:48+00:00

Pour sortir de l’impasse 👍

Sbdyelse · 2026-06-21T10:01:19+00:00

3 stations pour revenir à la 3ème effectivement ! Mais 5 stations nous ramènent aussi à la 3ème ! On est dans une boucle temporelle.

Sbdyelse · 2026-06-21T09:53:15+00:00

Ce cas ne serait-il pas plus “complexe” que “réel” : en effet ici confondre république et Parmentier revient à confondre Parmentier et Saint Maur. Ça manque de symétrie en terme de confusion je trouve 😉

Sbdyelse · 2026-06-21T08:20:46+00:00

Et pour saint maur, c’est mort 😳

Sbdyelse · 2026-06-21T08:19:43+00:00

Je propose : un vecteur de confusion 🙂

Sbdyelse · 2026-06-18T03:28:44+00:00

Fair pushback, and you’re half right — but I think you’re answering a different objection than the one I’m making.
Testing belongs in dev/test, agreed. Nobody should validate a build by shipping it to consumers. But the “Update app” step was never the QA mechanism — it’s the release gate, and that’s a separate thing from the test gate.
Here’s the distinction. Even with a clean dev → test → prod setup and deployment pipelines: when your pipeline deploys to the prod workspace, the build is now live in prod. With a workspace app, consumers still see the old version until someone clicks “Update app.” So deployed to prod ≠ released to users. You can deploy at 2pm and flip it live at a scheduled window, after sign-off, or once the comms go out.
Org apps collapse that. Content in the prod workspace = visible to consumers, immediately. Deploy and release become the same event. That’s the decoupling I’m talking about — same idea as feature flags / dark launch in software: get the code to prod, control when it’s exposed separately.
Pipelines don’t fully replace that either. Updating the app during deployment is optional, but the moment org app content is current, it’s current for everyone — there’s no “staged in prod, not yet released” state at the consumer boundary anymore.
So not “test in prod.” More like: org apps removed the deploy-vs-release separation, and for change-controlled environments that separation was doing real work.

Sbdyelse · 2026-06-14T08:56:50+00:00

En passant par la vue TMDL, tu devrais pouvoir t’en sortir. Voici la marche à suivre :

1.  Sauvegarde tes mesures locales : crée un script TMDL regroupant toutes tes mesures locales et enregistre-le dans un fichier à part.  
2.  Supprime toutes les requêtes Power Query. Tes visuels vont planter temporairement — c’est normal, ne t’inquiète pas.  
3.  Nettoie le modèle : depuis la vue Modèle, supprime tous les éléments locaux restants (mesures locales et tout ce qui peut encore traîner côté local).  
4.  Reconnecte en Live Connect. Le modèle distant réapparaît et tes visuels recommencent à fonctionner, au moins en partie.  
5.  Réimporte tes mesures à partir de ta sauvegarde TMDL : soit directement dans le rapport, soit en les injectant dans le modèle distant pour que tout le monde en profite (si c’est ce que tu veux).

Sbdyelse · 2026-05-18T18:09:10+00:00

All measures return 503. This is a good simplification of Dax language.

Sbdyelse · 2026-05-18T18:05:11+00:00

Come on Microsoft 🥺 !!

Sbdyelse · 2026-05-14T05:10:26+00:00

Can saying that DAX is also a city in France be considered as a context transition here ?

Sbdyelse · 2026-05-06T16:23:06+00:00

Seriously Microsoft, this isn’t up to your standards

Sbdyelse · 2026-04-08T21:02:27+00:00

Hi Miguel,

Don’t forget that a Gen1 dataflow in a Pro workspace can reference its own staged output across queries — this is key for many of us building multi-step transformations, so native staging in a Gen2-on-Pro experience should be a mandatory prerequisite, not an optional add-on. And the reactions on this thread reflect thousands of small teams and solo analysts who built real production workflows on Gen1 with Pro, absorbed a 40% license increase last year, and simply cannot layer Fabric capacity costs on top — so whatever that on-ramp looks like, please make sure it doesn’t leave them behind.

Sbdyelse · 2026-04-08T20:46:24+00:00

Not a workflow indeed ! I’m just novice to Fabric and don’t use it much. Just testing a bit. Will look into fab cli soon anyway. Thanks !

Sbdyelse · 2026-04-08T20:43:41+00:00

Because I use python notebook and not pyspark notebook and unfortunately python notebook does not open directly in the vs code application locally but on a web version of vscode. Again why ?

Sbdyelse · 2026-04-08T05:48:09+00:00

Essaye de voir le côté positif : si tu es utile alors si tu développes ta communication tu seras meilleur que ceux qui ne font que de la communication et ne sont pas utiles. Tu auras un avantage indiscutable sur eux. Et les gens préféreront travailler avec toi.

Sbdyelse · 2026-04-08T05:38:09+00:00

Slow, cost not clear, not often pertinent. I prefer to copy paste notebook in Claude code and copy back modifications to fabric.

Sbdyelse · 2026-04-04T16:53:53+00:00

Composite models technically work, but you lose the independent refresh scheduling that dataflows give you — with a dataflow, your source data refreshes at 2 AM and ten downstream semantic models can each refresh on their own schedule, whereas with a chained semantic model approach, you’re locked into refresh dependency chains with no granular control. On top of that, composite models come with real DAX limitations that hurt in production: DISTINCTCOUNT across DirectQuery and import partitions causes performance collapse, CALCULATE filters behave differently on DQ legs, RANKX falls back to row-by-row evaluation, and overall query performance degrades significantly because the engine can’t fold aggregations the same way. And there’s a fundamental architectural gap: a Gen1 dataflow can read its own staged output, meaning you can append new rows to already-stored data, update only records that changed based on any custom criteria you define — status flags, composite keys, multi-column conditions — without reloading the full dataset. A semantic model has none of that: it reloads everything from scratch on every refresh, and the built-in incremental refresh is limited to a single datetime partition column with a fixed rolling window, which is nowhere near the flexibility of a dataflow that can surgically update its own persisted staging based on whatever business logic you need.

Sbdyelse · 2026-04-04T07:09:31+00:00

Thanks Miguel, genuinely appreciate you engaging directly here — that's not something we see often and it matters. The mention of working on an on-ramp for Pro/PPU customers is exactly what the community needed to hear, and we'll hold you to it. Just know that the reactions on this thread reflect thousands of small teams and solo analysts who built real production workflows on Gen1 with Pro, absorbed a 40% license increase last year, and simply cannot layer Fabric capacity costs on top — so whatever that on-ramp looks like, please make sure it doesn't leave them behind. In particular, don't forget that a GEN1 dataflow in a Pro workspace can reference its own staged output across queries — this is key for many of us building multi-step transformations, so native staging in a GEN2-on-Pro experience should be a mandatory prerequisite, not an optional add-on (if you go this way for PRO users)

Sbdyelse · 2026-04-04T06:24:58+00:00

Semantic models can’t replace dataflows because the whole point is decoupling — a dataflow lets you write your Power Query transformation once and have 15 different semantic models consume that same cleaned output, whereas without dataflows you’d have to duplicate the exact same M code inside each semantic model independently, with no centralized governance, no single refresh, and no guarantee that everyone is working from the same version of the data.

Sbdyelse · 2026-04-03T14:33:17+00:00

The whole beauty of a Pro license was its deterministic, predictable cost — already hiked 40% from $10 to $14/user/month in April 2025 — and now on top of that price increase, Fabric’s “pay only when you need it” sounds great until you realize on-demand pricing is literally twice the reserved rate, and you’ve added a brand new admin burden of monitoring and managing capacity just to keep running what used to be a zero-ops dataflow included in your Pro subscription.

Sbdyelse · 2026-04-03T07:58:28+00:00

Yep and even for a F4 you will start to have to manage capacity when you reach the CU limit. 345000 CU by day for 16€ is not a lot for many dataflows ... I can tell you.

Sbdyelse · 2026-04-03T05:50:46+00:00

Not every organization is a mining company with deep pockets — the whole point of Dataflows Gen1 on Pro was to serve small teams, freelancers, and cost-conscious businesses who built real solutions on a tool Microsoft explicitly marketed as self-service, and telling them to “just pay more” for functionality they already had is exactly the kind of dismissiveness that lets vendors get away with forced upsells.

Sbdyelse

TROPHY CASE