Question 1

ADF or Fabric Data Factory: which one should we use?

Accepted Answer

Fabric Data Factory for new builds in most cases. The capabilities are similar (and growing closer) but the Fabric version integrates natively with OneLake and the rest of the Fabric platform without separate connection management. For existing ADF investments, the migration path to Fabric Data Factory is straightforward but not always urgent; existing ADF pipelines continue to work and can stay on standalone ADF for the foreseeable future. For new mid-market analytics builds, the default is Fabric Data Factory.

Question 2

Are Microsoft Fabric and Databricks genuinely competing for the same workloads?

Accepted Answer

Yes, increasingly. Both platforms can do most things: lakehouse, data warehouse, BI, ML, real-time. The competition is real. The differences are in optimisation and culture rather than capability. Fabric is built around BI-led mixed workloads. Databricks is built around code-first lakehouse and ML. Both can do the other thing, but each is designed for a different centre of gravity, and that is what shapes the decision.

Question 3

Are Microsoft Fabric and Snowflake genuinely comparable?

Accepted Answer

Yes, for the workloads most mid-market businesses actually run. Both are credible answers for cloud data platforms. The differences are in the optimisations and the integration story, not in raw capability. Both can land your data, model it, serve it to BI tools, and scale to large volumes. The decision is rarely about which is technically better. It is usually about which fits your team and your existing estate.

Question 4

Are there hidden costs?

Accepted Answer

Both platforms have non-obvious costs worth knowing. Fabric capacity sizing is its own learning curve, and over-provisioning is common in early Fabric deployments. Databricks workspaces can sprawl, with notebook clusters left running and unmanaged. Both vendors have monitoring tools. Use them from day one rather than discovering the bill at month-end.

Question 5

Are we ready for Microsoft Fabric?

Accepted Answer

If you scored nine or above, you are likely ready to consider Fabric. The Building stage is where structured platform investment usually starts paying back. Below nine, fix the foundations first. A new platform amplifies the problems, not solves them. The Fabric Adoption Playbook covers the platform decision in detail; the assessment tells you whether to start that conversation now or later.

Question 6

Azure SQL Database or Azure SQL Managed Instance?

Accepted Answer

Database for most use cases; Managed Instance for specific compatibility requirements. Azure SQL Database is the modern, fully-managed PaaS database with the lowest operational overhead. Managed Instance offers near-100 per cent compatibility with on-premises SQL Server, which matters for migrations from existing SQL Server environments where breaking changes would be costly. For new mid-market data platforms, Azure SQL Database is usually the default. For lift-and-shift migrations of existing SQL Server estates, Managed Instance may be the easier path.

Question 7

Can Fabric coexist with existing Power BI and Azure investments?

Accepted Answer

Yes. Fabric does not require ripping out existing Power BI investments; it extends them. Existing Power BI Pro licences continue to work, existing reports continue to run, and the migration path from Power BI Premium to Fabric capacity is well-documented. Existing Azure data investments (ADF, Synapse, Azure SQL, Storage) can be progressively migrated to Fabric or kept where they are with Fabric reading from them. The transition is incremental rather than a forklift replacement, which suits mid-market budgets and risk appetite.

Question 8

Can Fabric do ML?

Accepted Answer

Yes. Notebooks, ML models, real-time intelligence and data science workloads are all in the Fabric platform. The question is whether your team will use them well. The tools are credible. The ecosystem maturity is younger than Databricks. For most mid-market ML use cases (forecasting, classification, basic recommendations), Fabric is enough. For deep ML workflows with serious MLOps requirements, Databricks remains stronger.

Question 9

Can Fabric replace our planning system?

Accepted Answer

Usually no. Planning systems handle the workflow (scenario building, approval cycles, exception management, S&OP processes) that Fabric does not. Fabric handles the analytical layer (statistical forecasting, accuracy tracking, multi-source data integration) that the planning systems often handle weakly. The two work together. For very small operations a Fabric-only approach might work; for serious supply chain operations the planning system stays in place and Fabric augments it.

Question 10

Can Hopton build the architecture without delivering the reports?

Accepted Answer

Yes. Some clients engage us for the data engineering and architecture workstream specifically, with the reporting and visualisation handled by their internal team or another partner. The architectural deliverables (lakehouse structure, ingestion pipelines, semantic model design, deployment pipelines) are independent of the report build. The engagement scope is flexible. We are equally willing to deliver the full stack or a specific layer.

Question 11

Can Hopton design our Azure data architecture?

Accepted Answer

Yes. Architecture design is part of every Establish phase. The output is a written architecture document covering the Azure services to be used, how they fit together, the cost model, the security posture, the operational model, and the migration path from existing systems. The architecture is the foundation of the build phase that follows, but the architecture document is also useful as a standalone deliverable. Some clients use us for architecture only and deliver the build with internal teams or other partners.

Question 12

Can Hopton help us decide whether Fabric is right for our business?

Accepted Answer

Yes. The Reporting Modernisation Assessment (a four-week fixed-price engagement) is the structured way to get an independent view. Output is a written assessment with a clear recommendation: Fabric, alternatives, or a phased approach. We have written assessments recommending against Fabric where the business case did not support it, and we have written several recommending it. The framework decides, not the commercial bias toward selling more work.

Question 13

Can Hopton review our existing data architecture?

Accepted Answer

Yes. The Power BI Health Check (a two-week fixed-price engagement) covers the data architecture alongside the Power BI estate. For deeper architectural reviews on existing Fabric or Azure data platforms, we run extended assessments (typically four to six weeks) covering medallion structure, ingestion patterns, SCD handling, deployment maturity, and observability. Output is a written report with prioritised recommendations and a roadmap. The assessment is independent of any subsequent build engagement.

Question 14

Can MBA inform promotional design?

Accepted Answer

Yes, in two patterns. First, promote anchor products (those with strong outgoing associations) to drive baskets, accepting the margin sacrifice on the anchor for the basket-building uplift on associated products. Second, avoid promoting strongly co-purchased products simultaneously: if customers already buy A and B together, promoting both is unnecessary spending. The MBA-informed promotional plan is usually meaningfully different from the intuition-based plan, and the difference is measurable in basket-level uplift. We have run promotional optimisation work for retailers using MBA as the foundation.

Question 15

Can anomaly detection support customer behaviour monitoring?

Accepted Answer

Yes. Pattern detection on customer behaviour can surface accounts at risk of churn (sudden behaviour change), accounts at risk of fraud or compromise (unusual access patterns), and accounts that may be growing through organisational change (revenue patterns shifting). The challenge is distinguishing meaningful customer-level anomalies from natural variation, which requires careful baseline construction. Per-customer baselines work better than population baselines for established customer relationships.

Question 16

Can real-time replace our daily reporting?

Accepted Answer

Sometimes, for the right use cases. The high-frequency operational dashboards benefit from real-time. The strategic management reporting (monthly P&L, quarterly board pack) does not. The right pattern is a layered approach: real-time dashboards for operational decisions, refreshed-hourly dashboards for tactical management, and traditional batch reporting for strategic and statutory needs. Trying to put everything on real-time produces an expensive and unnecessary platform; trying to use only batch produces lost operational opportunities. Both have a place.

Question 17

Can the forecast run autonomously, or does it need human oversight?

Accepted Answer

Depends on the use case. For high-volume, low-stakes decisions (routine replenishment of stable products), autonomous operation with monitoring is appropriate. For high-stakes decisions (new product launches, promotional commitments, capacity decisions), human oversight is essential. The pattern that works is the forecast as input to a human-in-the-loop process for important decisions, and as direct driver for routine decisions, with monitoring agents flagging anomalies for review. The design of the operational workflow matters as much as the forecasting itself.

Question 18

Can we move from Fabric to Snowflake later, or vice versa?

Accepted Answer

Yes, with effort. Open table formats make data portability easier than it was. The harder parts are semantic models, BI tooling, security and the operational tooling around the platform. A migration is a real project, not a button-push, but it is no longer a one-way door. Choose well now and you will rarely need to migrate. Choose poorly and migration is a recoverable mistake.

Question 19

Can we reduce Fabric cost through reservations?

Accepted Answer

Yes, materially. Annual reservations save around 20 per cent off PAYG list prices. Three-year commitments through an Enterprise Agreement save up to 41 per cent. For workloads that only run during business hours, pausing capacity outside hours saves another 50 per cent on top. Combined, these can reduce Fabric capacity costs by 60 per cent or more against PAYG-without-pausing for typical mid-market patterns. The specific savings depend on your workload pattern; we cover sizing methodology in the True Cost FAQ.

Question 20

Can we run a quick MBA proof of concept?

Accepted Answer

Yes. We extract a sample of transaction data, run MBA in Fabric Data Science, produce the rule output, and walk you through the results. The proof of concept produces real rules on your real transaction data, not a generic demonstration. Often the rules surfaced in the proof of concept directly inform commercial decisions, even before the full implementation. Two to three weeks is the typical duration.

Question 21

Can we run an anomaly detection proof of concept?

Accepted Answer

Yes. A three to four week proof of concept on a representative data slice produces a working detector, validates the technique choice, and demonstrates the operational signal-to-noise ratio. The proof of concept output is often usable directly for some monitoring use cases, with the full implementation extending the coverage. Several of our anomaly detection engagements started as proofs of concept and grew into permanent monitoring capabilities.

Question 22

Can we use both platforms together?

Accepted Answer

Yes, and some organisations do. Fabric for BI and analyst-led work, Databricks for engineering and ML. The integration is workable through OneLake shortcuts and shared open table formats. The cost is operational complexity. Most mid-market businesses find that one platform serves them better than two. Larger organisations with distinct teams sometimes choose both deliberately.

Question 23

Do we need Purview for a mid-market analytics implementation?

Accepted Answer

For most serious implementations, yes. The capability that Purview provides (sensitivity labels, classification, lineage tracking, access governance) is genuinely valuable and increasingly expected by stakeholders, auditors, and regulators. Smaller implementations can get by with less; once the data estate spans multiple sources and the user base is broader than a small team, governance discipline supported by tooling becomes important. The cost of Purview is reasonable; the cost of governance failure is much higher.

Question 24

Do we need to learn KQL specifically, or can we just use SQL?

Accepted Answer

Both work, with different strengths. KQL is the native language for eventhouses and Real-Time Intelligence; the queries run faster and the language better fits the time-series patterns. SQL is supported through cross-Fabric queries and is more familiar for most analysts. For exploratory work and ad-hoc queries, KQL fluency makes a meaningful difference in productivity. For dashboards and reports built on top, the language choice matters less because the queries are written once and consumed many times. Most teams use a mix.

Question 25

Do you work on Azure outside of data and analytics?

Accepted Answer

No. Our scope is the Microsoft data and analytics stack. Azure as a broader cloud platform (compute, networking, identity, security, application services) is outside our specialism. We work with Azure data services because they are part of the data and analytics stack, but we do not deliver general Azure infrastructure work, application modernisation, or cloud migration outside the data context. For broader Azure work, we coordinate with specialist Azure partners.

Question 26

Does Databricks have better ML and AI tooling?

Accepted Answer

For now, yes, on the ML side. MLflow, Feature Store, Unity Catalog and the wider MLOps ecosystem are more mature in Databricks than in Fabric. Fabric is closing the gap on the data science workload, but mature MLOps is a multi-year build and Databricks has been at it longer. For organisations with serious ML ambitions, this is a meaningful advantage.

Question 27

Does Hopton implement real-time analytics?

Accepted Answer

Yes. Real-time and streaming analytics is part of our delivery scope when client use cases justify it. We have built real-time operational dashboards, supply chain visibility, and event-driven monitoring on Fabric Real-Time Intelligence. The team holds the relevant Microsoft certifications and has practical experience with the workload. Real-time is not the bulk of our work (most mid-market analytics is batch-led) but it is a capability we deliver when the use case is right.

Question 28

Does Hopton specialise in Azure?

Accepted Answer

Azure data services are at the centre of our work alongside Power BI, Microsoft Fabric, and Microsoft Dynamics 365 Business Central. Most of our engagements involve Azure Data Factory, Azure SQL, Azure Storage, and Microsoft Purview at minimum. Many include Azure Machine Learning, Azure OpenAI, or Azure-hosted infrastructure. The team holds individual Microsoft certifications across the Azure data stack. Azure is not a separate specialism for us; it is part of the Microsoft data and analytics stack we work in daily.

Question 29

Does Hopton specialise in data engineering and architecture?

Accepted Answer

Yes. Data engineering and architecture is at the centre of our work. Most of our engagements include the architectural design and implementation work alongside the analytical and reporting layer. The team includes data architects and engineers with practical experience building Fabric and Azure data platforms across mid-market sectors. Several team members hold individual Microsoft certifications including the DP-700 (Fabric Data Engineer) and the broader Azure data certifications. Architecture is not a sideline for us.

Question 30

Does Hopton work with Fabric only, or with the broader Microsoft data stack?

Accepted Answer

The broader stack. Fabric is one of our core technologies alongside Power BI, Azure Data Factory, Azure SQL, Azure Machine Learning, Microsoft Purview, and Microsoft Dynamics 365 Business Central. The strength is in knowing how these components fit together. Many of our engagements span Fabric and other Azure or Microsoft 365 services. Specialising in Fabric without specialising in the surrounding Microsoft estate would limit the value we deliver.

Question 31

Does MBA work for non-retail businesses?

Accepted Answer

Yes, with adjustments. The technique applies wherever transactions contain multiple items: financial products bought together, professional services purchased in combination, content consumed in sequence, courses taken in combination, pharmaceutical prescriptions in patient histories. The retail roots are visible in the terminology (basket, items) but the underlying maths is general. The data shape is the same: a transaction identifier and a set of items per transaction. Where the data fits the shape, MBA produces useful rules.

Question 32

How accurate should we expect demand forecasts to be?

Accepted Answer

Variable, by item and by horizon. For stable mature SKUs at weekly horizon, forecast errors of 10 to 20 per cent (mean absolute percentage error) are typical and good. For volatile or low-volume SKUs, errors of 30 to 50 per cent are common. For new products, forecast errors of 50 to 100 per cent or more are realistic. Aggregate accuracy is always better than SKU-level accuracy because errors cancel out. Setting realistic accuracy expectations is part of the early engagement; over-promising on accuracy produces disappointed stakeholders.

Question 33

How do Azure ML, Azure OpenAI, and Copilot fit together?

Accepted Answer

They serve different layers of AI capability. Azure ML is for traditional machine learning (predictions, classifications, forecasting) on your own data. Azure OpenAI is for generative AI through direct API access for custom applications. Copilot products are the user-facing AI assistants embedded in Microsoft applications, built on top of OpenAI models with Microsoft's product-specific tuning. Most mid-market businesses end up using Copilot for the user-facing AI, Fabric Data Science for traditional ML, and Azure OpenAI selectively for custom generative AI applications. The choice depends on the specific use case.

Question 34

How do I start a conversation about Azure data services?

Accepted Answer

Email hello@hoptonanalytics.com with a brief description of your current Azure estate, what you are trying to achieve, and any existing investments. The first conversation is exploratory and free. If there is a fit, we propose a four-week Establish phase that produces an architecture, a priority list, and a written delivery plan. From there you can decide whether to proceed with the build.

Question 35

How do I start a conversation about Microsoft Fabric?

Accepted Answer

Email hello@hoptonanalytics.com with a brief description of your current data and analytics estate, your main pain points, and what you are trying to improve. The first conversation is exploratory and free. If there is a fit, we propose a four-week Establish phase that produces an architecture, a priority list, and a written delivery plan. From there you can decide whether to proceed with the build.

Question 36

How do I start a conversation about anomaly detection?

Accepted Answer

Email hello@hoptonanalytics.com with a brief description of the use case (what kind of unusual behaviour are you trying to catch), the data sources, and the operational team that would respond to the alerts. The first conversation is exploratory and free. If there is a fit, we propose either a focused anomaly detection proof of concept or a broader analytics engagement that includes anomaly detection as one component.

Question 37

How do I start a conversation about data architecture?

Accepted Answer

Email hello@hoptonanalytics.com with a brief description of your current data estate (sources, current platform, scale), the architectural challenges you are facing, and what you are trying to achieve. The first conversation is exploratory and free. If there is a fit, we propose either a Health Check (lighter-touch review) or an architectural assessment (deeper review) as the structured next step.

Question 38

How do I start a conversation about demand forecasting?

Accepted Answer

Email hello@hoptonanalytics.com with a brief description of your supply chain operation, the products and SKUs you forecast, the planning systems already in place, and the specific accuracy or operational issues you are trying to solve. The first conversation is exploratory and free. If there is a fit, we propose either a four-week forecasting proof of concept or a broader supply chain analytics engagement that includes forecasting as one component.

Question 39

How do I start a conversation about market basket analysis?

Accepted Answer

Email hello@hoptonanalytics.com with a brief description of your transaction data, your basket sizes, and what commercial decisions you are looking to inform. The first conversation is exploratory and free. If there is a fit, we propose either a focused MBA implementation or a broader customer and product analytics engagement that includes MBA as one component.

Question 40

How do I start a conversation about real-time analytics?

Accepted Answer

Email hello@hoptonanalytics.com with a brief description of the use case (what decision needs to be made faster, what events need to trigger action, what data sources are streaming-capable), and the current state of your data platform. The first conversation is exploratory and free. If there is a fit, we propose either a focused real-time scoping engagement or a broader analytics engagement that includes real-time alongside batch.

Question 41

How do MBA rules inform store layout?

Accepted Answer

By revealing which products customers naturally buy together, layouts can either encourage the association (placing the products near each other for convenience and uplift) or deliberately separate them (placing products at opposite ends of the store to extend the shopping journey). Both strategies have been used effectively. The decision depends on the business: convenience-led retailers tend to group; destination retailers tend to separate. The rules surface the choice; the merchandising team makes the call. Most mid-market retailers do not formally use MBA for layout decisions and many would benefit from doing so.

Question 42

How do training and operability costs factor in?

Accepted Answer

Heavily, and most pricing comparisons miss this. A platform your team can run with existing skills costs less in practice than one that requires hiring. Fabric tends to win on this for organisations with Power BI developers. Snowflake tends to win for organisations with strong SQL engineering teams. The platform you can run is almost always cheaper than the platform you have to staff up to run.

Question 43

How do we avoid alarm fatigue?

Accepted Answer

Five disciplines. Calibrate thresholds against historical false positive rates so the alert volume is manageable. Tier alerts by severity so the most critical anomalies stand out from routine ones. Suppress duplicate alerts within a defined window. Route different alert types to the right teams rather than everything to one inbox. Track alert response and outcome so the calibration can improve over time. Without these disciplines, anomaly detection generates noise that gets ignored, defeating the point of the system. With them, the alerts that fire are the ones genuinely worth acting on.

Question 44

How do we compare pricing fairly?

Accepted Answer

Build a representative workload and price both. Sample queries, refresh patterns, user counts. Most pricing comparisons are unfair because they price one platform at a typical workload and the other at peak. Both vendors have pricing calculators. Use them with realistic numbers, including non-production environments and growth assumptions.

Question 45

How do we handle data quality issues that look like anomalies?

Accepted Answer

Carefully, because the line between 'data quality issue' and 'genuine anomaly' is sometimes thin. The pattern that works is two-stage: a data quality layer that filters out known data issues (missing values, duplicate records, schema violations) before the anomaly detection runs, and an anomaly detection layer that flags genuinely unusual events for review. Without the separation, anomaly detection produces a flood of false positives driven by data quality rather than business unusualness. The Trust Storytelling Delivery Checklist applies here particularly.

Question 46

How do we handle promotional baskets?

Accepted Answer

Carefully. Promotions distort buying patterns: customers buy products together because they are on promotion, not because they have a natural affinity. Including promotional baskets without flagging them produces rules that reflect promotional planning rather than customer behaviour. The right approach is usually to tag promotional transactions, run MBA both with and without them, and compare the rules. The 'organic' rules (without promotions) are usually more useful for ranging and store layout; the 'with promotion' rules are useful for promotional design.

Question 47

How do we handle promotional volatility?

Accepted Answer

By treating promotions as features in the forecasting model. The historical promotional flags become predictors, and the forecast for future periods incorporates the planned promotional calendar. This produces promotion-aware forecasts that distinguish baseline demand from promotional uplift. The technique requires the historical promotional data to be captured cleanly, which is often the bottleneck. Without clean promotional history, the models attribute promotional uplift to other factors and produce poor forecasts in promotional periods.

Question 48

How do we handle the training-versus-detecting tension?

Accepted Answer

By treating anomaly detection as a continuously learning system. The model trained on the most recent stable period is used for current detection. As new observations accumulate, they are evaluated against the current model. Confirmed anomalies are excluded from future training data; confirmed normal observations are included. The model retrains periodically (weekly or monthly typically) on the cleaned recent data. This pattern keeps the model adapted to evolving normal behaviour while preserving sensitivity to genuine anomalies.

Question 49

How do we measure forecast quality?

Accepted Answer

Through standard accuracy metrics: mean absolute error (MAE), mean absolute percentage error (MAPE), bias (whether the forecast systematically over- or under-shoots), and forecast value-add (whether the model is better than a naive baseline). The metrics are tracked over time and across SKU groups. Models that are getting worse trigger investigation. Models that are systematically biased need correction. The accuracy tracking is operational discipline, not just initial validation.

Question 50

How do we test data pipelines?

Accepted Answer

Through three test types. Unit tests on the transformation logic itself (does this Python function produce the expected output for known inputs). Integration tests on pipeline behaviour (does this pipeline correctly read from the source and write the expected schema to the destination). Data quality tests on the output (does the produced data meet the quality expectations: row counts in expected ranges, no null values in critical columns, foreign keys resolve). The Microsoft Fabric ecosystem supports each of these through standard tools (pytest, Great Expectations, SQL assertions). Mature data teams run all three; ad-hoc teams run none.

Question 51

How do we use MBA rules in cross-sell?

Accepted Answer

Two main patterns. Real-time recommendations: when a customer adds A to a basket online or at the till, the system suggests B based on the rules. The implementation requires the rules table to be accessible at transaction time, usually through an API. Batch recommendations: customers who have bought A but not B receive a targeted email or marketing communication suggesting B. The batch pattern is simpler to implement and works well for email-driven businesses. Both patterns produce measurable lift in attach rate when the rules are good.

Question 52

How do we visualise MBA rules in Power BI?

Accepted Answer

Three views work well. A rule table sorted by lift, showing the top rules with their measures. A network graph showing the strongest associations as edges between items, useful for understanding the structure of the relationships. A category heatmap showing aggregate association strength between categories rather than individual items. The right view depends on the audience: buying teams use the rule table, range planners use the network graph, leadership uses the heatmap. Power BI handles all three.

Question 53

How do you handle the layers as Delta tables in OneLake?

Accepted Answer

Each layer is a set of Delta tables in dedicated lakehouse workspaces or schemas. Bronze tables are append-only with transaction timestamps. Silver tables are mutable with merge logic for deduplication. Gold tables are typically rebuilt or merged depending on the modelling pattern. Direct Lake mode in Power BI reads Gold tables directly without copying. The Delta Lake format provides ACID transactions, schema evolution, and time travel across all three layers. The technology supports the pattern cleanly; the discipline is in the design.

Question 54

How does ADF handle on-premises systems?

Accepted Answer

Through the Self-hosted Integration Runtime, an agent installed on a server with access to the on-premises systems. ADF in the cloud orchestrates the pipeline; the integration runtime executes the source-side data movement. The model handles secure, performant integration without exposing the on-premises systems to the public internet. For mid-market businesses with significant on-premises data (older ERPs, internal databases, file shares), the integration runtime is the standard pattern. The same pattern applies to Fabric Data Factory.

Question 55

How does Azure relate to Microsoft Fabric?

Accepted Answer

Fabric is built on Azure infrastructure but presented as an integrated platform with its own pricing model and user experience. Several Azure services have Fabric equivalents: Azure Data Factory has Fabric Data Factory; Azure Synapse has Fabric Data Engineering and Data Warehouse; Power BI Premium is now part of Fabric capacity. The Azure services continue to exist for use cases that need them; the Fabric versions are usually preferred for new analytical workloads. The Fabric for Mid-Market FAQ in our library covers when Fabric is the right choice over assembling Azure components separately.

Question 56

How does Data Activator fit with anomaly detection?

Accepted Answer

Data Activator triggers actions when configured anomaly conditions are met. The pattern: the anomaly detection scoring runs continuously or in micro-batches, the scores are written to a stream that Data Activator monitors, and rules evaluate the stream and trigger actions. For high-stakes anomalies, the action is human notification (Teams message, email, ticket creation) for immediate review. For lower-stakes anomalies, the action is logging for periodic review. Data Activator is the operational layer that connects detection to response.

Question 57

How does Databricks handle multi-cloud?

Accepted Answer

Natively. Databricks runs on AWS, Azure and GCP with the same product. If your organisation has workloads across more than one cloud, this is a genuine advantage. Fabric is Azure only and pulls Azure-adjacent workloads with it. Multi-cloud is rarely a small consideration when it applies to you.

Question 58

How does Databricks pricing work?

Accepted Answer

Databricks is consumption-based, priced in DBUs (Databricks Units) per workload type. Compute scales when needed and stops when idle. Costs are visible per workload but less predictable per month. For organisations with intermittent workloads, this can be cheaper than Fabric's fixed capacity. For continuously running workloads, Fabric capacity often comes out ahead.

Question 59

How does Direct Lake mode change the architecture?

Accepted Answer

Significantly. Direct Lake reads Power BI data directly from Delta tables in OneLake without import or pass-through. The result combines Import-mode performance with near-real-time freshness because the lake is the storage layer rather than a separate copy. For new Fabric implementations, Direct Lake is the default for most semantic models. The exceptions are models that need calculated columns or complex DAX patterns that Direct Lake does not yet support, in which case Import mode remains the right choice.

Question 60

How does Fabric Git integration work?

Accepted Answer

Fabric workspaces can be connected to Azure DevOps Git or GitHub repositories. Notebooks, semantic models, pipelines, and reports are stored as code in the repository. Changes are made through pull requests with code review. Deployments to other workspaces (development to test to production) happen through the deployment pipelines feature or through CI/CD automation. The integration is the foundation for serious data engineering practice on Fabric.

Question 61

How does Fabric compare to building on raw Azure data services?

Accepted Answer

Fabric is the productised, integrated path. Raw Azure (ADF plus Synapse plus Power BI plus Storage plus Purview, configured separately) is more flexible but more work. For most mid-market businesses, Fabric's integration advantages outweigh the flexibility gains of raw Azure. For very specific high-volume or specialised workloads, raw Azure still has a place, but those situations are uncommon at mid-market scale. The default for mid-market new builds is now Fabric. Existing investments on Synapse or raw Azure can usually be migrated cleanly into Fabric.

Question 62

How does Fabric integrate with the rest of M365?

Accepted Answer

Natively. Entra ID for identity, Purview for governance, Sensitivity Labels for data classification, Teams for collaboration, Copilot Studio for AI. Power BI is part of the platform, not bolted on. This is the strongest single argument for Fabric in M365-heavy organisations: the integration tax of running anything else compounds over time.

Question 63

How does Fabric pricing affect the per-user Power BI cost decision?

Accepted Answer

The interaction is the most commonly missed cost pattern. On Fabric capacity below F64, every author and viewer of Power BI content still needs a Pro licence (£11 per user per month). At F64 and above, viewers are free; authors still need Pro. The crossover point where F64 becomes cheaper than F8 plus per-user Pro is around 500 viewers at PAYG, around 370 with annual reservations, around 250 with three-year EA discounts. Most mid-market businesses sit below the crossover and should stay there.

Question 64

How does Hopton help us choose?

Accepted Answer

Two ways. A decision review, two to three weeks at fixed price, where we walk a structured framework with your team and produce a written recommendation. Or, if you have already chosen Fabric, full delivery. We do not deliver Databricks projects ourselves. If Databricks is the right answer, we will tell you and can introduce you to people who do.

Microsoft Fabric - frequently asked questions

Can’t find what you’re looking for?