In a previous post, we explored how PowerTable takes applications to where data lives rather than copying data to applications. That foundational approach raises natural questions: which data architecture should you choose within Microsoft Fabric, and how do the different options affect PowerTable applications?
After decades of database specialization, we're witnessing something remarkable: transactional and analytical systems are converging again, but this time with architectural intent rather than compromise.
You probably noticed a string of acquisitions pointing in the same direction. First, Microsoft acquired Citus Data in 2019 to bring distributed PostgreSQL capabilities to Azure. More recently, Databricks acquired Neon for $1B in May 2025 to add serverless PostgreSQL to its platform, swiftly followed by Snowflake’s acquisition of Crunchy Data for $250M for pretty much the same reason.
Microsoft bet its data platform future on Fabric's unified approach, providing specialized compute engines that share OneLake storage. In doing so, the company is showing they're willing to put interoperability and customer demand above protecting their crown jewels, using open standards shared with the likes of Databricks (Delta) and Snowflake (thanks to Iceberg interop). Did you know that the Fabric runtime runs on top of Mariner 2.0, aka Azure Linux?
What sets this convergence apart from earlier "one size fits all" platforms is that modern systems embrace workload-specific processing while unifying storage, governance, and security. Microsoft Fabric exemplifies this strategy. For organizations building data applications with PowerTable, understanding when to use Fabric's three data approaches affects performance, cost, governance, and how easily business users can work with their data.
The historical separation of transactional and analytical systems solved real performance problems. Row-based storage optimizes for individual record operations, while column-based storage excels at aggregate queries across millions of rows. Running both workloads on the same system created lock contention and performance disasters.
This architectural constraint shaped decades of software design. Every business system needed its own database, its own copy of data, its own ETL processes to feed analytical systems.
What changed wasn't the fundamental trade-offs between storage formats, but our ability to manage them effectively. SAP HANA pioneered in-memory hybrid processing starting in 2010, delivering what would later be dubbed HTAP by Gartner in 2014. Around the same time, Microsoft was developing VertiPaq, an in-memory columnar engine that debuted in PowerPivot (2010) then became the core of Power BI's semantic models to this day. Microsoft then brought this OLAP innovation to the transactional world with SQL Server columnstore indexes in 2012, which used xVelocity technology based on the VertiPaq engine.
The industry has seen multiple attempts at unified systems over the decades. Early efforts failed because the hardware couldn't deliver on the promise - trying to run analytical queries on transactional systems created lock contention disasters, while 'universal' databases couldn't handle real production workloads at scale. Every major vendor now claims unified platforms, but the economics have fundamentally changed. What failed at $1000/GB RAM costs succeeds at $10/GB. What created performance bottlenecks on spinning disks works on NVMe SSDs.
Yet, while hardware continued to become more powerful, the appetite for more data continued to grow in parallel. In response, rather than insisting on cramming everything into one engine, Fabric provides specialized compute options that share storage. So yes, it's effectively a hybrid platform, but that doesn't mean a single engine is meant to do everything. You choose the right processing method for each workload while maintaining data consistency and governance.
This pattern of bringing specialized engines by use case under one roof is in display too with vector databases. Here, Fabric offers several options with CosmosDB, EventHouse, and even the good old SQL Database itself is catching up for this AI-driven requirement. Snowflake and Databricks have made similar moves.
Leaving aside vector databases for now, understanding Fabric's architecture choices helps explain why PowerTable works effectively across different engines, and when you'd choose each approach.
Fabric SQL Database is a serverless abstraction over Azure SQL that provides full ACID transaction support, referential integrity, and familiar T-SQL interfaces. For PowerTable applications, this means immediate consistency for writeback operations. When a user updates pricing data in a PowerTable application, that change appears instantly for all other users and systems.
This makes Fabric SQL Database ideal for master data management where data integrity is non-negotiable. Product catalogs, pricing tables, and organizational hierarchies benefit from guaranteed consistency without synchronization delays.
The trade-off is analytical performance at scale. While Fabric SQL Database handles substantial workloads, it's optimized for transactional patterns rather than complex analytical queries across billions of rows.
Fabric Data Warehouse provides T-SQL interfaces optimized for analytical workloads. Built on massively parallel processing (MPP) architecture with autonomous workload management, it uses distributed query processing across multiple compute nodes while storing data behind the scenes in Delta format for ACID transactions and interoperability.
For PowerTable users, this means building applications on existing data warehouse tables while benefiting from analytical query performance when displaying large datasets. The writeback operations PowerTable provides work seamlessly, optimized for bulk updates rather than high-frequency transactional changes.
This approach works particularly well for planning and budgeting applications where users need large amounts of historical context but make relatively infrequent updates to forecasts or targets.
The T-SQL compatibility means existing database teams can work immediately without learning new languages or paradigms.
The Lakehouse approach combines data lake flexibility with structured query capabilities. Built on Delta Lake format, it provides ACID transactions on object storage with both SQL and Spark interfaces.
However, there's a critical architectural limitation: PowerTable can read from Lakehouse SQL endpoints but cannot write back to them. The Lakehouse SQL endpoint operates in read-only mode due to Delta Lake's limitations around multi-table transactions. To modify Lakehouse data, you must use Spark interfaces.
This means PowerTable applications requiring writeback functionality need different patterns when working with Lakehouse environments. You might read reference data from Lakehouse while writing transactional updates to Fabric SQL Database or Data Warehouse, then synchronizing changes through Spark processes. That said, it is not uncommon to combine lakehouses and warehouses in end-to-end Fabric solutions.
The Lakehouse excels for scenarios where PowerTable displays large analytical datasets for context while capturing user inputs in separate transactional stores.
Choosing the Right Foundation: Decision Patterns
From a data engineering perspective, the lakehouse targets Python or Scala developers familiar with Spark and notebooks, while the warehouse will feel very familiar to organizations and individuals with a T-SQL background. In a future entry we will review where PowerTable fits within a medallion architecture as well as discuss the central role of semantic models in contemporary data architectures that have added AI readiness as one of their main goals.
Microsoft's original vision for Fabric security was ambitious and compelling. The initial "OneSecurity" concept, unveiled in 2023, promised a "Secure Once and Use Anywhere" model where granular security policies—including row-level, column-level, and data masking—would be defined once in OneLake and automatically enforced across all engines and workloads.
Thisvery ambitious vision turned out to be arduous to execute. Two years later, OneSecurity became the more tightly-scoped OneLake Security, available in limited preview for the past few months. While valuable, this represents a more incremental approach than the original mission statement. And while OneLake Security continues to mature, the current RBAC model provides role-based access control for folder-level permissions, but has important limitations:
Microsoft's Path Forward: Microsoft continues evolving this capability, with OneLake data access roles scheduled to be replaced by "OneLake security" in Q3 2025.
PowerTable's Approach: Given the current security landscape, PowerTable implements its own permission model that works consistently across all supported platforms—whether Fabric, Snowflake, Databricks, or traditional databases. This ensures predictable, granular access control regardless of the underlying platform's security maturity. As Microsoft's unified security vision evolves and stabilizes, PowerTable can adapt its integration accordingly while maintaining the reliable governance customers expect today.
While Fabric provides compelling integration benefits, most organizations have data across multiple platforms. PowerTable's connectors to Snowflake, Databricks, and traditional databases acknowledge this reality while maintaining similar architectural principles.
The strategic moves by industry leaders highlight recognition that sustainable data applications must work with enterprise data platform foundations rather than creating isolated data islands. Microsoft's early investment in PostgreSQL through Citus Data positioned them ahead of recent competitive moves, while PowerTable extends this philosophy by working directly with your chosen platform. Just because PowerTable is a Fabric workload doesn’t mean you have to do everything in Fabric.
What distinguishes PowerTable from traditional data application builders is recognition that sustainable applications must be built on enterprise data platform foundations. Applications that combine UI, compute, and storage in single-vendor packages might seem simpler initially, but they recreate the data movement and synchronization problems that led organizations to adopt platforms like Fabric in the first place.
By working directly with your chosen data platform's native capabilities, PowerTable applications inherit the governance, security, and performance characteristics you've already established - avoiding the data integration failures we've seen repeated across multiple technology cycles. Your data stays where your policies expect it to be.
The best way to understand these architectural choices is through specific business scenarios. Whether you're managing pricing data requiring immediate consistency, building planning applications on your data warehouse, or creating flexible workflows that span multiple data types, the key is starting with a concrete use case.
Identify the data sources involved, the performance requirements, and the governance constraints. This provides a foundation for choosing the right Fabric approach and understanding how PowerTable works within your existing architecture.
The convergence of transactional and analytical systems represents an evolution beyond the rigid separations of the past. Modern platforms like Fabric enable getting benefits of both approaches without the traditional compromises, but only when you choose the right tool for each specific workload.
See how PowerTable works with your specific Fabric architecture. Request a demo to explore how these choices play out with your data, your requirements, and your governance model.
1. Single-Table Transaction Scope:
2. Optimistic Concurrency Control Design:
3. Cloud Object Storage Architecture:
1. Traditional SQL Expectations vs. Delta Reality:
2. Spark as the Designed Write Interface:
Note: you technically could write data with your own code, not just Spark, as long as you'd be willing to dive into the Delta spec and create manifests yourself, aligned with the Delta version supported by the current Fabric runtime. In other words, that would be quite a heavy lift.
3. Microsoft Fabric's Implementation Choice:
4. PowerTable Implications:
This technical limitation isn't a Microsoft design flaw, it's an inherent constraint of the Delta Lake open-source protocol that prioritizes single-table ACID guarantees over multi-table transaction support. Databricks is pursuing multi-table transactional support via Unity Catalog, but exploring this goes beyond the scope of this entry.
Every enterprise technology conversation today eventually arrives at the same destination: AI. How do we use it? When do we invest? Where do we start?
But beneath the hype sits a more fundamental question that most organizations haven’t fully addressed: Is our data actually ready for AI?
For many, the answer is “partially.” Actuals, transactional data, and operational metrics are increasingly well-governed and consolidated onto modern data platforms. But there’s a critical category of data that remains stubbornly siloed: planning data—budgets, forecasts, scenarios, targets, and assumptions.
This gap isn’t just an inconvenience for the finance team. It’s a blind spot that fundamentally limits what AI can do for your organization.
When organizations talk about making their data “AI-ready,” the conversation typically focuses on data quality, governance, and consolidation. Clean it, govern it, centralize it. These are necessary steps. But they tend to focus exclusively on historical and operational data—what has already happened.
Planning data tells a different story. It captures what the organization expects to happen, what it’s preparing for, and what it’s committed to. Budgets encode priorities. Forecasts encode assumptions. Scenarios encode risk. Together, they form the forward-looking half of the business picture.
Now consider what happens when this data lives in a standalone SaaS planning tool, disconnected from the platform where your actuals reside. Any AI model, assistant, or automation running on your data platform can answer questions about performance—“What were last quarter’s sales?”—but it cannot answer questions about intent: “Are we on track against our plan? What happens if we miss our Q3 forecast by 10%? Which cost center is most at risk of exceeding budget?”
That’s not a minor limitation. It means your AI can look backward but not forward. It can describe the past but can’t help you navigate the future.
Of what use is the AI that can describe the past, but not navigate the future?
To understand the practical impact, consider a few scenarios that are already emerging in enterprises investing in AI-powered analytics:
Scenario 1: Automated variance commentary. You want AI to generate narrative explanations of budget-versus-actual variances. If your budget data is in one system and your actuals are in Microsoft Fabric, the AI has to work across two systems, two data models, and two security frameworks. In most cases, it simply can’t. The variance report still gets built manually.
Scenario 2: Intelligent forecasting. You want to use machine learning to improve forecast accuracy by analyzing patterns in historical actuals alongside previous forecasts. But if forecasts are locked inside a separate planning tool’s proprietary data store, there’s no clean way to feed both streams into a training pipeline. You end up with export files and ETL workarounds that are fragile, delayed, and ungoverned.
Scenario 3: Natural language queries across the business. You want executives to ask plain-language questions like “How is EMEA tracking against the revenue plan?” If the revenue plan exists in a separate system, the AI assistant has no access to it. The executive gets a partial answer—actuals only—or no answer at all.
In each case, the technical barrier isn’t the AI model itself. It’s the data architecture. Planning data is stranded in a silo, and no amount of prompt engineering can bridge that gap.
Making planning data AI-ready isn’t about adding an AI feature to your existing planning tool. It’s about ensuring that planning data lives in the same governed, accessible, and well-modeled environment as the rest of your enterprise data. Concretely, this means:
This is the architecture that Lumel EPM is built on. By operating as a native workload inside Microsoft Fabric, Lumel writes planning data to OneLake, where it’s immediately available to reports, AI models, and any other Fabric workload. There’s no data replication, no proprietary store, and no synchronization delay.
The benefits of unifying planning and actuals on a single platform extend well beyond AI enablement—though AI is where the strategic payoff is largest.
When planning data lives on the same platform as actuals:
These advantages compound over time. Each budget cycle that runs on the platform adds more forward-looking data to the lake. Each scenario that’s saved becomes training data for better forecasts. The system gets smarter because the data gets richer—and it’s all in one place.
If your organization is serious about AI readiness, here’s a question worth posing to whatever planning tool you’re currently using or evaluating:
“Where does our planning data physically reside, and can our AI workloads access it natively?”
If the answer involves proprietary data stores, export APIs, or complex integration layers, your planning tool is creating the very silo that your data platform strategy is trying to eliminate. It’s working against your AI ambitions, not supporting them.
The alternative is planning that operates inside your data platform—reading from and writing to the same store that powers everything else. That’s not a futuristic vision. It’s available today.
AI readiness is not just a data engineering project. It’s an architecture decision that touches every part of the enterprise—including, critically, how you plan.
If your forecasts, budgets, and scenarios are locked in a disconnected tool, you’re building your AI strategy on an incomplete foundation. The models will be less accurate. The insights will be less complete. And the executives asking questions will keep hearing, “We’ll get back to you.”
The fix isn’t another integration. It’s bringing planning to where the data already lives.
That’s how you make your data truly AI-ready.
Microsoft Fabric has changed how organizations think about their data platform. By unifying data engineering, analytics, governance, and AI workloads under one roof, it has eliminated much of the architectural sprawl that plagued earlier approaches.
But there’s a quieter revolution happening alongside the platform itself: the ISV workload model. And for finance and planning teams, it may be the most consequential development in enterprise software architecture in years.
If you manage a Fabric environment—or if you’re evaluating how to modernize your planning stack—understanding what native ISV workloads mean in practice is worth your time. The implications for security, cost, and user experience are significant.
For the past two decades, enterprise planning tools have followed a consistent pattern. You subscribe to a cloud-based SaaS platform. Your data gets replicated from your systems of record into that platform’s proprietary data store. Your users log in with a separate identity. Your IT team manages a separate set of roles, permissions, and security policies. And when it’s time to report, you extract data back out.
This model works—in the sense that organizations have used it for years. But it creates a specific set of structural costs:
For years, these costs were accepted as the price of doing business. But the ISV workload model in Fabric offers a fundamentally different approach.
Microsoft introduced the ISV workload framework to allow third-party applications to run inside Fabric—not alongside it, not connected to it, but actually embedded within the platform itself.
Here’s what that means in practice:
In short, a native ISV workload is not a bolt-on. It’s a first-class citizen of your Fabric environment.
[ninja_tables id="2772"]
For Fabric administrators and architects, the implications of the ISV workload model are architectural. But for finance and planning teams—the people who actually build budgets, run forecasts, and present to the board—the implications are deeply practical.
Faster time to value. Because a native workload operates on your existing data and semantic models, the implementation doesn’t begin with a months-long data migration project. You connect to the semantic model you already have. Your planning application can be up and running in hours, not months.
Broader access without broader cost. Consumption-based pricing eliminates the tension between “we need more people in the planning process” and “we can’t afford more licenses.” Seasonal budget contributors, occasional scenario reviewers, and ad-hoc users can participate without driving up your annual spend.
Trust in the numbers. When plans and actuals share the same definitions, the same security, and the same data store, the question “Why does my report show a different number than the budget?” disappears. Not because you’ve fixed a bug, but because the architecture makes that inconsistency impossible.
No IT overhead for separate governance. Finance teams won’t need to file IT tickets to add users to the planning tool, manage separate role assignments, or maintain integration pipelines. The planning application inherits everything from the Fabric environment that IT already manages.
Lumel EPM is the first and only enterprise planning solution built as a native ISV workload in Microsoft Fabric. As a Microsoft Strategic ISV Partner for Fabric, Lumel didn’t retrofit an existing SaaS product to connect to Fabric—it was architected from the ground up to operate inside it.
This means:
This isn’t a vision of what native planning could look like someday. It’s what Lumel EPM delivers today—trusted by thousands of enterprises worldwide.
You don’t need a fully mature Fabric deployment to benefit from this architectural shift. If you’re using Fabric today—or even just starting to explore it—understanding the ISV workload model helps you make better decisions about your planning stack now.
Choosing a planning tool that operates natively in Fabric means you’re not creating a new silo that you’ll have to migrate away from later. You’re investing in an architecture that grows with your platform adoption. Your planning data will already be in OneLake when you’re ready to build AI workloads on top of it. Your security model will already be unified when your governance requirements tighten.
In other words, the ISV workload model isn’t just about how applications run inside Fabric today. It’s about the decisions you make now that determine how easily your environment scales tomorrow.
The ISV workload model represents a genuine architectural innovation—one that changes the economics, security, and user experience of extending Fabric for enterprise use cases like planning.
For finance teams, it means planning can finally live where the data already does—governed by the same policies, accessible to the same users, and visible to the same AI workloads. No separate cloud. No separate licenses. No separate truth.
The era of planning as a disconnected SaaS island is ending. The platform era has arrived.
