Speaker 1 Microsoft changed how paginated reports handled data volume limits. It used to slow down. Now it fails The docs say it explicitly, change to failure by design. Speaker 2 Just stops? No partial render? Speaker 1 Aborted. And whether it hits you depends on something in the report definition that most teams have never checked. Speaker 2 Architecture decisions for Microsoft Fabric. This is the Fabric Architecture Podcast. We're talking about a format from 2004, the SSRS era. that's still a first class fabric item in 2026. And it's quietly gotten stricter. I want to know what changed underneath. and who's about to find out the hard way. Speaker 1 Almost everything about paginated reports traces back to one design decision. The RDL carries no data model. A Power BI report sits on a semantic model with Vertipak, with caching, with DAX. A paginated report has none of that. Every dataset inside the definition is a query that executes against the source at render time. Speaker 2 Every time someone opens it? No caching layer at all? Speaker 1 The Power BI service doesn't support dataset caches for paginated reports. SSRS had them on-prem. The service doesn't. Parameter queries run sequentially. Cascading parameters rerun when a preceding value changes, and all of it hits the live source. The official guidance says point your parameter queries at a semantic model. The model becomes your cache. Speaker 2 That reframes where the intelligence belongs Every aggregation, every filter, if you're doing it inside the report definition, you're pulling everything to the render engine first and throwing most of it away I keep running into reports with millions of rows flowing into a tablics that sums them into a dozen lines That group by belongs in the query, full stop. Speaker 1 That no-model design is also why a single RDL can embed up to 250 data sources. Without a unifying model, mixing sources inside the report is the only way to combine data. The docs list data integration across different sources as a paginated report-only capability. Speaker 2 250 sounds impressive on paper, but the typical report uses 304. Here's the test I keep coming back to. Is the deliverable a document or an insight? A document is something someone keeps, files, prints, sends to an auditor. An insight is an answer someone acts on and then forgets. That question answers itself and it tells you which tool to reach for. Speaker 1 Microsoft's own migration guidance uses that framing. For teams sitting on SSRS estates, and SSRS goes back to 2004, they say sort by intent. An RDL that produces a document, migrate it. An RDL that was only a report because SSRS was the only tool available. That dashboard-shaped thing with 12 parameters Redevelop it as a Power BI report. Speaker 2 Migrating that faithfully just preserves a compromise nobody wanted. Speaker 1 Someone in the fabric community asked, how does the paginated visual help with a lot of data? This comes up constantly, and it's usually someone who just hit the wall. A standard Power BI visual caps its Excel export at 150,000 rows The paginated report visual pushes that ceiling to 1 million rows. Formatting preserved. That's why people find this feature. They need the data out. Speaker 2 That's essentially the whole user base, people who hit an export wall. Speaker 1 But the visual carries a second number If any field feeding it has more than 30,000 distinct values, a data reduction algorithm drops the rows above the limit. The docs say the report may show incorrect results due to missing data from report parameters. It renders, it looks complete, and the numbers are wrong. Speaker 2 A bigger export ceiling with a smaller correctness ceiling and no warning. Speaker 1 Silent And the visual isn't subscribable, doesn't update through deployment pipelines. The docs actually recommend If it's the only element on the page, use the paginated report directly. Speaker 2 Alright, back to the top. Failure by design. What actually decides whether a render succeeds or crashes? Speaker 1 Every paginated report runs in one of two execution environments, standard or optimized The optimize path roughly doubles your data volume ceiling, from about a million rows to around two million, and the report processor assigns the environment based entirely on the expressions in your RDL. You can't override it. Speaker 2 What kind of expression kicks you out? Speaker 1 Weekday. The VB. NET weekday function. One expression. If weekday of sales date is greater than 5, show relax. Else, show work. And the entire report drops to the standard environment. Your data ceiling halves. And the change Microsoft made is that exceeding that ceiling used to mean slow rendering. Now the query aborts at about 2 gigabytes, and the render just fails. Speaker 2 So someone tested this two years ago, it ran slow, but it finished, and now the exact same report on the exact same data just dies. Speaker 1 And there's a diagnostic for it. Every rendered paginated report has a diagnostics button that shows the execution environment Optimized or not, and list the exact expressions blocking you. It exists. Almost nobody clicks it Speaker 2 Of course they don't. Speaker 1 On capacity costs, every render eats CS. The hardcap is 500 concurrent renders per capacity workload. Beyond that, HTTP 429 and exports count against the same budget. 100 reports rendering plus 200 exports leaves you 200 render slots. Speaker 2 What do the actual user numbers look like on an F64? Speaker 1 Microsoft published them. An F64 with a small workload, a hundred row aggregation, supports about 2,500 users. A medium workload, 100,000 rows, drops to around 1900. A quarter million rows, you're down to 1,300. And that's under their 5% peak concurrency assumption Speaker 2 The number I'd lose sleepover isn't the user count, it's timing. A subscription that fans out to 200 people at 8am Monday is 200 concurrent renders hitting your capacity at once. The docs call that report bursting. On an F64, if your report takes 4 CPU seconds, your concurrent render limit is about 60. That Monday morning subscription alone blows past it by a factor of three. Stagger the schedule It costs nothing and it saves you the morning where nobody can open anything. Speaker 1 The honest countercase. If your team lives in Power BI desktop and nobody needs a physical document, you can stay interactive. Export to Excel handles most needs under 150,000 rows. You keep cross-filtering, bookmarks, custom visuals. A paginated report surrenders all of that for a page break engine. Speaker 2 That's fair. If nobody's printing, filing, or mailing a PDF to a regulator, you don't need the page break engine. The honest question isn't which report type, it's whether your deliverable is a document at all. And sometimes it genuinely isn't. Speaker 1 One risk worth flagging. For an Azure Analysis Services source, switching from SSO to OAuth 2 is irreversible and tenant-wide. It applies to every report using that source in every workspace. And row level security only works with SSO. So on that one source type, a single drop-down change can silently disable RLS across an entire tenant's paginated reports. Speaker 2 That's a compliance incident wearing a drop-down menu. The transferable piece. Speaker 1 A report format without a data model means every performance question, every security decision, every capacity problem traces back to the query. The query is the architecture. Speaker 2 Show me the query pattern. If the aggregation's in the right place, the report scales. If it isn't, no capacity tier saves you. That's the decision that actually matters. Speaker 1 Somewhere right now, a Monday morning subscription is carrying a weekday expression nobody remembers, heading for a ceiling that used to be a slope and is now a cliff. Speaker 2 And the diagnostics button nobody's pressed is sitting there, ready to explain why. If you've inherited an RDL estate and you're deciding what to migrate versus rewrite, DM me on LinkedIn. Find me as Matthias Falland. Speaker 1 Press diagnostics first. Speaker 2 This was the Fabric Architecture Podcast. This podcast was generated by AI. New episode every Friday.