My main use case for Fabric Data is to get the data from multiple data sources, whether on-premises or other cloud service providers, and store that data into Lakehouse or warehouse, prepare a data model for them, and create reports with the Power BI Desktop.

A specific example of how I have used Fabric Data recently includes a project where data was coming from Oracle and IBM, and there was another data source. All of it was getting combined in Snowflake, and I performed Snowflake mirroring with Fabric Data where all the data is mirrored into the Fabric environment, and then I had to create the data models for the Power BI reports.

Fabric Data enables me to get the data from multiple resources, whether on-premises or any other Azure service providers, and also allows me to transfer and migrate the data from any other platform to Fabric Data smoothly. I accomplish this in the form of files or text, using the functional features of Delta Lake in the Parquet format for transactional data and historical data, and I can store the data in the form of tables or create a data warehouse for data modeling and more.

One use case I can share is that if we have a tenant in which we have multiple users, each user gets a Fabric Data free trial of sixty days in which he or she can explore Fabric Data items depending upon the client's requirement. This gives us the opportunity to only pay for one particular tenant level Fabric Data capacity while all the other users can use the same.

The best features that Fabric Data offers include that in Lakehouse, it has the form of tables and files where I can store the Delta Lake format, including the transactional data or historical data where I can roll back to the version level or find out the historical data. It also has a very good compute engine for the data warehouse where all the queries and the storage is mainly computerized in the back end via compute size, and it provides similar use cases of data engineering solutions that I can have in ADF, Synapse Analytics, and basically, it acts as a SaaS platform combining all the data-related fields and profiles that I can encounter.

Regarding the Delta Lake versioning format, I can get the data in the previous version to perform the SCD1 or SCD2 type to check that I am only loading the incremental data. If I am talking about the compute engine, it mainly focuses on querying the data, how much transactional data is being queried in the back end, and how much data is stored in the form of stored procedures, tables, views, functions, and many other features.

I have not encountered any challenges in Fabric Data up until now.

I did encounter one challenge recently in Power Query editor where I had to perform the same amount of transformations for multiple reports, repeating the transformations for each row each time. I think they need to improve in that scenario.

I feel there are a few challenges that I might not have analyzed right now. Nevertheless, it is still in preview and evolving. I am waiting for the challenges to be renewed or modified, and then definitely, I might be rating it higher.

I have been using Fabric Data for more than two years.

Fabric Data is stable at a limited amount of storage.

Fabric Data is scalable since whenever I start my Fabric Data free trial capacity, it gives me a scalable amount of sixty days where I can explore Fabric Data items, and after that, I need to purchase the paid Fabric Data starting from F2 to 256. I am not sure about the highest amount, but I can scale up and down depending upon the workloads.

I have not explored customer support yet because I have not encountered any major issues with Fabric Data that require reaching out.

Previously, I worked with ADF and Synapse Analytics since they provided different functionality depending upon their deployment methods. However, since Fabric Data gained prominence around May 2026, I have transitioned most of my workloads, creating data pipelines and reports from various services to a single SaaS platform.

I was using Azure Data Factory and Synapse Analytics while I also utilized Power BI Desktop for creating the reports before choosing Fabric Data.

Pricing, setup cost, and licenses are not mainly handled by my team since we are mainly focusing on creating scalable pipelines for the migration of data from data sources to Fabric Data. I do not have much expertise on that subject.

Since Noventiq is currently working as a Microsoft service provider, we mainly focus on services provided by Microsoft. Fabric Data was launched around May 24, and the first project I did with Fabric Data was with a client where I had to create different layers of cementing models; I did raw, silver, and gold in Fabric Data layer in Lakehouse and warehouse as well. After that, I created multiple reports.

I actually encountered a few deliverables that were very helpful for the client, such as the incremental load and bifurcations of different layers of data, where I performed some transformations and the data modeling was performed in the gold layer so that I could have a perfect star schema in the form of fact and dimension tables. I was also able to create insightful business reports.

Depending upon the client's requirements, if the data is in the form of on-premises, I use the on-premises data gateway by deploying a virtual machine that is indirectly connected to on-premises and Microsoft data, and in the back end, it gets connected via Azure Relay. I can also connect the data via the virtual network gateway where Fabric Data is being deployed, and the paid Fabric Data is deployed in a particular virtual network connected with Fabric Data environment to get the data output.

I mainly use Azure, but there were two or three projects that I have worked on with AWS as well.

I did not purchase Fabric Data through the AWS marketplace for those AWS projects; it was actually set up by the client environment. I just had to migrate the data from AWS to Fabric Data.

My advice to others looking into using Fabric Data is that it is a one-stop solution for all the upcoming data-related profiles, such as data analysts, data engineering, data science, and Power BI development. All these things can be encountered on one platform; I just need to know how to manage different public items that are being deployed in Fabric Data. I would rate my overall experience with Fabric Data as 7.5 out of 10.

My main use case for Fabric Data includes using Data Factories, Lakehouse, Data Warehouse, and Data Pipeline, Gen2 flow, shortcuts, and some libraries in my projects.

A specific example of a project where I used Fabric Data is when I worked with big data and big data frames, where I utilized the Medallion Architecture design pattern. In the Bronze layer, I was configuring different source data to land in the Bronze layer, mapping data with source to destination, data types, and configuring tables one by one in the Bronze layer. I was also using an ETL pipeline and a try-and-catch block to handle the pipeline error and understand the error, along with using data changes, data type changes, and CDC (Change Data Capture) while also utilizing fact and dimension tables.

In addition to my main use case for Fabric Data, I encountered the shortcut method, which allows me to land data in Lakehouse from different sources, such as AWS and Azure, using a shortcut without copying the data to store it in Lakehouse.

The best features of Fabric Data include the OneLake architecture, as it combines data analytics, data engineering, and machine learning all in one platform. I can load data directly into Lakehouse without copying it, utilize the Medallion Architecture design pattern, clean data stored in Delta Lake, and use any cloud to store Delta Lake, which is a significant benefit to land data and store it in a Parquet file. The data is stored in a Parquet file, and without copying, I can use one raw data in a completely semantic model.

Fabric Data has positively impacted my organization by decreasing the storage-level cost, and we now have different teams, including a data analytics team and a data engineering team, all on one platform, allowing us to directly check the data analytics part. If the data analytics team needs some KPIs, the data engineering team can create a materialized view and store it directly in a Delta Lake-structured format. This is a benefit for all teams, from the starting project to the end project.

I believe Excel sheets have some issues when creating a data frame; however, JSON data works fine for Fabric Data. When using an Excel sheet, we need some extra libraries, and that feature would be useful because most e-commerce sites store data in Excel. Therefore, I need a way to directly store an Excel sheet in Delta tables.

I would like to add that we have DataBricks in my organization, which serves various purposes related to data handling.

I have been using Fabric Data for two-plus years, and I have completed two end-to-end Fabric Data projects.

In my experience, Fabric Data is stable.

Fabric Data is good for security and scalability, with row-level security and column-level security, and the ability to track any pipeline, making it easy and understandable for users, including non-IT persons, at a graphic level.

When I reached out regarding some issues we had encountered, I found the customer support to be good.

Before using Fabric Data, I worked on one project in DataBricks; however, since the client needed Fabric Data and had data stored in Azure, it was easy for me to load data from Azure into Fabric Data using one account, which is why I switched to Microsoft Fabric Data.

I have indeed seen a return on investment, as different employees use one cloud account, leading to fewer employees needed, thereby saving costs.

My experience with pricing, setup cost, and licensing is that we have an Azure license, making it easy to use Fabric Data.

Before choosing Fabric Data, I evaluated other options, specifically DataBricks and Snowflake.

I do not have extensive experience in Fabric Data currently, as I have only worked on two projects. Fabric Data is new for me, and I do not encounter any problems in my projects at this time. If there is any problem, I will read and discuss it.

I chose a rating of nine out of ten for Fabric Data because some features are not available. For example, DataBricks has certain features that Fabric Data currently does not have.

My advice for those looking into using Fabric Data is that it is easy to use. You can load from on-premise into Lakehouse, utilize copy activity from another cloud, leverage the shortcut method, and use Fabric Data pipeline. It is straightforward to load raw data in Fabric Data, and the Medallion Architecture is also straightforward, covering Bronze, Silver, and Gold layers. Additionally, analyzing historical data in the analytics field and accessing the data engineering and machine learning fields, all in one platform, is advantageous. I believe Fabric Data will be in high demand in the coming years.

I am currently learning about a Fabric Data project, and if there are any needed new updates, I will contact the customer.

My main use case for Fabric Data is to create a data pipeline that ensures that the data coming from the source has been properly cleaned and provided to the end user with a dashboard. Fabric Data helped with multiple tools for this, including notebooks, Gen flows, and pipelines. I created something where I could use the pipeline tool as an orchestrator and manage my overall pipeline.

I found Fabric Data to be very useful for data analysis. The dashboards that we can create are pretty much code-free and very easy to learn. Fabric Data can be a bit slow with dependencies, but overall it is quite good.

The best features Fabric Data offers are its Gen2 flows and its pipelines because they are all code-free and low-code tools. This means any person with a non-technical background can use them. In Fabric Data, we can connect with multiple other sources from GCP, Google Cloud, AWS, and Azure. I love that everything is on one lake, which is Delta Lake underneath, and everything integrates well with Microsoft tools as well as with Google Gen and AWS.

Fabric Data has positively impacted my organization because, compared to others, I found it pretty easy to use. Being with a group of business analysts, it was straightforward for all of us, especially since we were using Azure at that time. Having Fabric Data was an easier decision to make because both link to Microsoft, resulting in easier integrations and overall good performance. Although Databricks has more competency, as a data analyst, I find Fabric Data is at its peak.

I think Fabric Data could be improved by adding more notebooks, even though it currently has one.

I wish Fabric Data included more complexity because most of the tools are low-code or no-code. Adding more complexity would provide a more complete package, making it better than Databricks. I believe it should include Git as well, which it currently does not.

I have been using Fabric Data for about two years.

I have not found any issues with the reliability of Fabric Data. It is pretty secure.

Fabric Data has handled larger workloads and growing data volumes well and has scaled effectively.

Customer support for Fabric Data has been good. Our customers were pretty happy and delighted with the service.

My first solution was Microsoft Fabric, and later I was introduced to Databricks.

I cannot give exact figures regarding money saved, but after the application was built with Fabric Data, our client experienced significant growth in their field, leading to a lot of profit inflow because the end users loved the application. In terms of workforce, as it goes forward, there can be a reduction in team members, but that depends on the project's complexity. Overall, as a platform, Fabric Data is easy to learn and quite good.

My experience with pricing, setup cost, and licensing was not really discussed. I am not entirely aware of what our pricing was. If I had to guess, I think we were using something around 64, which comes to about $200 or $300 per month.

Something I wish I could do with Fabric Data is create my own application, which I have not done before. However, I have worked on other applications and end-to-end pipelines, along with dashboards, so I am trying to do a side project of my own using Fabric Data.

I noticed improvements because when I was first introduced to Fabric Data, I had no idea about it and was more of a code person. However, once I started using Fabric Data, I found it pretty easy to learn and quickly grasped it. Because it is low-code and more of a drag-and-drop tool, I could easily play around and become accustomed to it. Additionally, it is free for many users.

Since adopting Fabric Data, we saved a lot of time because we all did not have to code. If I were using Databricks, I would have spent multiple hours writing complex code, but using Fabric Data allowed us to save much time. I think a project that was supposed to take eight months could be completed in about six months, so we saved around two months. The performance has been quite good, and we did not find any lags, although there were some difficulties and slowdowns with dependencies, but overall it is quite good.

My advice for others looking into using Fabric Data is that if they are building something simple that does not require frequent maintenance, Fabric Data would be a suitable solution. However, if it is very complex and demands regular maintenance, Fabric Data might not be the best choice. For simple projects, especially in startups or where there are fewer tech staff and users transitioning from non-tech to tech, Fabric Data would be an excellent starting point.

Everybody should give Fabric Data a try because it is the easiest tool that I have ever used. I would rate this review an 8.

I have been using Fabric Data for the past two years.

My main use case for Fabric Data is building pipelines with notebooks and then surfacing the output in Power BI. Doing the data engineering inside Fabric makes it easier to ingest, clean, and shape the data into the exact structure I need for reporting, getting it from point A to point B in one workspace.

I work primarily with the pipelines because they give me a full end-to-end flow - I can take raw data and report on it in one place instead of going back and forth between databases and engineers. It lets me operate as a data scientist, data engineer, and business analyst from a single workspace, with end-to-end visibility and control over the pipeline.

Fabric Data's best features are the automation and the data engineering capabilities I can handle on my own.

The automation and engineering features stand out because they sit on top of the Microsoft infrastructure, making it very easy to connect to various data sources. I can ingest data even when it's not in my Azure Blob storage - from other SQL servers, on-prem connectors, or anywhere else - and the Power BI connector library lets me connect to data from almost any source, join multiple sources together, and provide reporting on top of it.

The AI features are still maturing, but Microsoft has a clear roadmap and direction for that to improve over the next few releases.

Fabric Data's best features are automation and the engineering part of the data that I can handle on my own, and the company is now getting into the AI part, which I feel is still not the best, but there is a feature for that to come.

The automation and engineering features stand out for me because they contain the Microsoft infrastructure, making it very easy to connect to various data sources, allowing me to ingest data even if it's not in my Azure Blob storage, such as from other SQL servers or any location, and it has extensive Power BI connectors that enable me to connect from almost anywhere, with a huge number of connectors to bring data from anywhere I need, join multiple sources together, and then provide my reporting on top of it.

The improvement part I foresee for Fabric Data is going to be with the AI.

Copilot in Power BI feels weak compared to standalone third-party assistants. Microsoft has the platform advantage but the model integration could be much more powerful and offer better insights.

I have been using Fabric Data for the past two years.

Fabric Data appears to be stable.

Fabric Data is scalable; if I build a good database model in the Lakehouses, it scales well for reporting.

The customer support for Fabric Data is good; especially if I raise a critical-level ticket, they contact me directly, but they could improve in some areas.

Previously, everything was done with Excel, and using Excel was a significant challenge for storing, manipulating data, and then publishing it online with Power BI when the Excel file sits on my desktop. However, pushing it into Fabric makes everything much easier, cleaner, and more transparent.

Fabric was the natural choice given our existing Microsoft stack Power BI, Azure, and Microsoft 365 and the deep native integration outweighed evaluating standalone alternatives.

My advice for others looking into using Fabric Data is to try to understand what users need before building from beginning to end; there are many ways to bring data, engineer it, and report it, such as data shortcuts, mirroring, imports, and data lakes. I suggest understanding the whole project from start to finish and evaluating each option that could work best for your case since there are numerous ways to bring in a single source of data, depending on the best use case to provide the most efficient and cost-effective Fabric solution. I would rate my overall experience with this product an 8 out of 10.

My main use case for Fabric Data involves using it as part of my preparation for the Microsoft Fabric Data Engineer Associate certification, where my hands-on practice covers building data pipelines, working with Lakehouse and OneLake storage, transforming data using Dataflow Gen2, and connecting outputs to Power BI for visualization. All work is done in a personal lab environment following Microsoft Learn guided exercises.

Fabric Data offers the best features by delivering a well-integrated, modern data engineering experience as a learning and certification platform. Fabric Data impacts my work positively, with one of its strongest aspects being its native integration across the Microsoft data stack. OneLake serves as a single unified storage layer across all Fabric workloads, meaning data written by a pipeline is immediately accessible in Lakehouse, Warehouse, and Power BI without duplication or manual transfer. This eliminates the data silo problem that commonly affects multi-tool environments.

This unified storage in Fabric Data impacts my workflow by making Dataflow Gen2 use the familiar Power Query interface, allowing accessibility for analysts already working in Excel or Power BI. The output of a dataflow can be directly directed into a Lakehouse table, which then becomes queryable via the SQL analytics endpoint without additional configuration.

I felt some features of Fabric Data, particularly around Dataflow Gen2 error handling and pipeline monitoring, lack clear documentation at the time of my study.

The needed improvements in Fabric Data include that the learning curve for newcomers can be steep when moving beyond the guided tutorials into independent project work.

I have been using Fabric Data for three months.

My experience with pricing, setup cost, and licensing involves having a student trial.

Fabric Data is a strong solution that delivers value as a learning and certification platform. I have no further suggestions at this time. I would rate this product a nine out of ten.

My main use case for Fabric Data is for ETL purposes, like migrations from SQL Server to Fabric, where I have developed pipelines, notebooks, and Dataflow Gen2 tools. For a vast amount of data, we performed the ETL and added that data into Lakehouses, and after that, warehouses, following the Medallion architecture that can be used for Power BI report generation.

In the healthcare project I have been working with, I had to perform integration and ETL processes to convert and add that data into Fabric data layers that can be used by Power BI. I used orchestrator notebooks related to PySpark, which is available in Fabric. I used this for ingestion of SQL Server data into the Lakehouses in Fabric. After that, with the help of Dataflow Gen2s, pipelines, and the other capabilities available in Fabric, we performed the transformation. Different kinds of transformations took place. In Dataflow Gen2, I added M queries that can, for example, change a column's data type, select what kind of column we want, and remove unnecessary things. We performed all of this transformation and after that, created a pipeline with everything in one place so that we can run those pipelines, get the data, ingest the data into a Lakehouse, and then also use that data in another layer. For my project, I used the Medallion architecture which has Bronze, Silver, and Gold layers. In the Bronze layer, I added the raw data with the help of ingestion notebooks in Fabric. In the Silver layer, I performed the transformation on that data with the help of a PySpark notebook and Dataflow Gen2. And in the Gold layer, I created a warehouse where I dumped all the data which can be used for a Power BI report or any other capability that will take help from Fabric.

The best features Fabric Data offers include the pipeline compatibility. We can use PySpark notebooks, we can use Dataflow Gen2s, and we can run as many Dataflow Gen2s as we want by adding them into notebooks. There is a feature called Monitor in Fabric in which we can check everything related to what kind of data flow is running, how much consumption it is taking, and what the notebooks are; everything being run is visible. We can check the compute instance and how much compute our Fabric environment is using. Its helpful nature related to data modeling and data warehousing are some of the good things which are integrated into one environment and are useful for work.

The monitoring feature is a very good feature. It is a window in which we can monitor everything related to a notebook, pipeline, or data flow in a single place: its start time, its end time, and whether it failed or not. It is very important to check whatever we have run, if it failed, where it failed, and if we have to rerun it from the start or rerun it from the failed activity. All these things can be monitored with the monitor feature. For the workflows, it is sometimes very difficult to manage if we are not organized. Fabric provides a feature to manage all these workflows in a single place. We can also use its resources, such as its capacity, its management tool, and many different things. The pipelines, which we are using in Fabric, are actually very helpful. They ease our task to get everything—notebooks, data flows, everything—in one place, connect everything, and prepare a pipeline. We can schedule the pipeline as per our requirements, whenever we want to run it, and at how many intervals we want to run it. This is a very good feature.

Fabric Data has positively impacted our organization as it has been our go-to tool for data integration with the help of Microsoft services. Previously, when we were using the Azure platform, it was very difficult to manage permissions and multiple things because all the environments are different. With Fabric Data, it is very easy to connect it with Power BI, all the datasets, data marts, and data warehouses to continue our work. It is an integrated environment which is very good for our work pattern.

There are a few things related to the management of compute resources: how much is being used and how to control those things. There are things related to the proper specification of errors. There should be documentation related to error resolving, showing how we can handle or tackle different kinds of errors. I faced many problems while running the data flow where the errors were not available on the internet to solve. Several things need to be taken care of.

There needs to be improvement in error handling and resource management because some of the documentation is not clear. I faced different kinds of errors which do not have any specific error handling available in the Microsoft documentation or Fabric community.

I have been working in my current field for 4.5 years.

Fabric Data has been stable over the last one year and working well. Microsoft is providing different upgrades every month, so it has been stable.

Fabric Data's scalability is good. We need to check what kind of output it is providing. It has worked well for me. There needs to be a little improvement in customer support. Sometimes, the documentation and error handling are not clear.

I would rate the customer support a four.

Previously, we were using SQL Server and directly connecting it with a Power BI report. We needed a good integration environment and an ETL platform. That is why we switched to Fabric Data.

The setup cost is reasonable, which is good for the developers to work on. It has very good pricing which is suitable for many organizations.

We were given the pricing and licensing by our organization. We were using the primary account where we have all the access, but I do not have any admin access.

As we completed the project, we achieved success within the required time. This is a return on investment for us. In the future, we are going to use this product. It has saved our time and money, and we have received many benefits from it.

The setup cost is reasonable, which is good for the developers to work on. It has very good pricing which is suitable for many organizations.

I have checked Snowflake and Databricks, but for good Power BI integration, Fabric Data is the best.

People can go with Fabric Data. It is a very good platform for integration and ETL. It will save time and cost, and it will resolve most of the problems for people. I would rate this product a seven overall.

I used Fabric Data as part of my preparation for the Microsoft Fabric Data Engineer Associate certification. My hands-on practice covered building data pipelines, working with Lakehouse and OneLake storage, transforming data using Dataflow Gen2, and connecting outputs to Power BI for visualization. All work was done in a personal lab environment following Microsoft Learn guided exercises.

I have additional observations about my main use case and my experience using Fabric Data for certification prep. I felt some features, particularly around the Dataflow Gen2 error handling and pipeline monitoring, lacked clear documentation at the time of my study.

The unified workspace is the biggest advantage I experienced while building those data pipelines and working with OneLake storage. Having data ingestion, transformation, storage, and reporting all within one platform significantly reduces the complexity of switching between tools. The integration with the broader Microsoft ecosystem felt natural, especially for someone who is already familiar with Azure services. The Microsoft Learn documentation and sandbox environments made it accessible for structured self-study.

Fabric Data's strongest aspect positively impacts my organization and my work with its native integration across the Microsoft data stack. OneLake serves as a single unified storage layer across all Fabric Data workloads, meaning data written by a pipeline is immediately accessible in Lakehouse, Warehouse, and Power BI without duplication or manual transfer. This eliminates the data silo problem that commonly affects multi-tool environments.

Dataflow Gen2 uses the familiar Power Query interface, making it accessible to analysts already working in Excel or Power BI. The output of a dataflow can be directly directed into a Lakehouse table, which then becomes queryable via the SQL analytics endpoint without additional configuration, significantly impacting my workflow.

I felt some features, particularly around the Dataflow Gen2 error handling and pipeline monitoring, lacked clear documentation at the time of my study.

The learning curve for newcomers can be steep when moving beyond the guided tutorials into independent project work.

I have been using Fabric Data for three months.

Fabric Data is pretty good, and I have no further suggestions for change or addition to make my experience even better. I would rate this review a 9.

My main use case for Fabric Data is for data ingestion, data transformation, and for data visualization.

A quick, specific example of how I use Fabric Data for data transformation or visualization in my daily work is that I was working on a project for a leading pharmaceutical organization, and they were using Excel for complex calculations. There were more than 50 Excel sheets, and they were applying formulas to them. We transformed that project and the whole process by writing the transformation logic in Fabric Data Notebooks. We automated that process and did data visualization using Fabric Data BI service.

We also applied incremental logic by using Fabric Data pipelines to ingest raw data using an SFTP source connection. Then, we used Fabric Data Notebooks for writing all the complex calculations and implemented the Medallion architecture. Afterwards, we used Power BI service to visualize the data.

The best features Fabric Data offers include Fabric Data Shortcut as the main feature, and also the integration of all the components like ingestion, transformation notebooks, and the deployment pipeline for CI/CD, which are game-changing. The visualization features are also great, and the features Fabric Data offers are different.

The feature I find myself using the most is the time travel feature because I mainly work with data transformation. Whenever bad updates happen, I use the time travel feature the most.

There is a high concurrency feature that can be applied in pipelines; we just need to add the high concurrency tag, and the pipeline will not start a new cluster each time the notebook runs. Fabric Data will use the same cluster for the notebook run, and this feature is a game-changer.

Fabric Data positively impacts my organization by bringing us more projects and work to do and also reduces the time significantly. Nearly 20 to 30 hours per week were reduced by using Fabric Data, and it is also very cost-optimized.

Fabric Data can be improved by releasing more features that are currently in preview, and once those features are fully released, that will be an improvement. Also, improving the real-time data capabilities, like the KQL dataset, would be beneficial.

The main improvement I would like to see is more integration with other tools; for example, SAP integration should be there because there are more integration tools available in Azure Data Factory than in Fabric Data, and I would like to have more integrations in Fabric Data.

I have been working in my current field for nearly three and a half years.

Fabric Data is stable.

Fabric Data's scalability is impressive. It is scalable on ingestion, and using an incremental pipeline, you can scale the data really well. It is also scalable at the cluster level and the storage level.

Customer support for Fabric Data is abundant, as there is a lot of customer support available when using Fabric Data. There is community help where you can post any issues, and the Microsoft Fabric team is very helpful.

I would rate the customer support on a scale of 1 to 10 as nine out of 10.

Previously, we were using Databricks for this, but we switched to Fabric Data because Fabric Data is more integrated. We don't need to shift our data from one tool to another, and all the processing and visualization can be done inside Microsoft Fabric Data.

I have seen a return on investment; as I said before, it previously took three to four days to get the optimized and calculated data, but now we are getting that in two to three hours, so more than half of the time is saved. Regarding pricing, we can do the computation and everything else at a fraction of the cost since we have a pay-as-you-go model, leading to nearly a 50 to 60% price reduction in cost and around an 80% time reduction.

My experience with pricing, setup cost, and licensing is that everything was very easy; Fabric Data follows a pay-as-you-go model, so if you are not using anything, you don't need to pay.

We evaluated other options before choosing Fabric Data, such as Talend, Azure Synapse, and Azure Databricks.

My advice for others looking into using Fabric Data is to complete certifications first before using it, like DP-100 and AZ-900. These are the basic certifications you need to do, along with DP-600 and DP-700, which are two associate-level certifications you need before working on Fabric Data. I would rate this product nine out of 10.

As a Data Scientist, my main use case for Fabric Data is to manipulate data inside Lakehouses and develop Power BI reports and publish to them in Fabric.

A quick specific example of how I have used Fabric Data recently is that I imported a dataset and used Python to run a notebook against the data to extract latitude and longitude for 300,000 addresses.

I don't have anything else to add about how I use Fabric Data in my day-to-day work; it is a great tool and a good tool to have in your toolbox.

In my opinion, the best features Fabric Data offers include the ability to work inside and spin up SQL databases and Lakehouses and work with Python, all within the same environment without having to go outside and use multiple other tools that are not compatible with the language and file system and data types that I am currently working with.

Fabric Data has positively impacted my organization because the company has a long history of working with data, and previously, there have been multiple pipelines for how to manage data from going from Power Apps into Excel and into SharePoint and then importing back into Power BI. Fabric Data has allowed us to change that and put the entire solution in one package and one environment, and that also makes things much more stable.

This move to one environment has led to measurable improvements, as it prevents a lot of breakage points and removes a lot of the complexity. The consistency between being able to use it inside one environment and not having to rely on other people outside of Fabric Data to do their job allows us to do more. It has also improved the user experience from within Fabric Data. For example, by using Translytical Taskflows, users that use Power BI no longer have to go outside Power BI to update data and have it returned back into their report; they can experience that all from the same environment.

I find the integration between these different tools within Fabric Data has some learning curves because Fabric Data is growing. It can sometimes be challenging to learn new tasks and items to get it to function, but overall, it usually works pretty well, even when things are in preview mode.

Fabric Data can be improved because it tends to be run by Fabric Capacity, which is basically the compute cycles, and it is not very clear on how and what that is going to be used. There should be a lot more transparency on what things actually cost when it comes to Fabric Capacity. In addition, some of the tools offered by Fabric Data don't provide really good guidelines for how to accomplish things inside Fabric Data; they just have all these tools and you have to know which one to go to make it work.

Fabric Data is laid out an umbrella with all the tools underneath it, and I don't find that their use case or how to maneuver or manage inside Fabric Data is intuitive. I wish they had spent more time developing the menus or how to get from one place to the other.

I have been using Fabric Data since 2024.

Fabric Data is stable most of the time, but not always.

The scalability of Fabric Data is great, and there is absolutely no problem with it. The biggest problem is the hidden cost of Fabric Capacity.

I haven't had to rely on customer support, so in this case, I would say it is great.

I did previously use different solutions before Fabric Data. We were using Power BI as a standalone reporting tool, SharePoint, Excel, Power Automate, and Power Apps, all combined to do the same things that we are currently doing in Fabric Data, plus we were using additional databases such as SQL, Mongo, and Snowflake, where Fabric Data now can manage everything.

Before choosing Fabric Data, we evaluated Databricks and decided that because it was not within the Microsoft umbrella, it would not be beneficial to use Databricks as an analytical tool.

I recently ran into Translytical Taskflows, which helps; it is basically SQL write-back, and I am finding the process very helpful in solving other problems.

My advice for others looking into using Fabric Data is to know what your Fabric Capacity usage is going to be. Do a really deep dive analysis of what that cost is going to be. Getting the right Fabric Capacity for your purchase is important, and the big break is at using F64 SKUs.

I am glad Fabric Data is available, and I enjoy working with it. I gave this review a rating of 8.

My main use case for Fabric Data is data integration, ETL, and BI. A specific example of how I use Fabric Data for integration, ETL, and BI is that we integrate several data sources such as SAP, Business Central, or any kind of data source, database, or API to build a Lakehouse. With the information on the Lakehouse, we perform an ETL process. Finally, we create BI solutions with Power BI.

The best features Fabric Data offers for my work include its integrated environment with many solutions inside the same platform. The features I use most often or find most valuable are Lakehouse, pipelines, dataflows, data agents, and reports and semantic models.

Fabric Data has positively impacted my organization as my company is a consultant company and we have implemented these projects for our clients. I have seen positive results and feedback from my clients after implementing Fabric Data. Specific outcomes and examples of how my clients benefited include cost savings and various KPIs, depending on the business.

To improve Fabric Data, I suggest more integration with additional data sources and better integration for data agents.

I have been using Fabric Data for three years.

In my experience, Fabric Data is stable.

Fabric Data's scalability is adequate; it is very scalable.

Customer support for Fabric Data is provided through partners.

Before Fabric Data, I used MicroStrategy. I switched from MicroStrategy to Fabric Data because of the revolution with Power BI.

I have seen a return on investment with time saved.

My experience with pricing, setup cost, and licensing is that it is acceptable.

Before choosing Fabric Data, I did not evaluate other options.

I do not have any advice to give to others looking into using Fabric Data. I have no additional thoughts about Fabric Data. I found this interview satisfactory and nothing should change for the future. I would rate this review an 8.