Fabric Data Reviews

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.

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.

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.

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 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.

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.

Most of the projects I have encountered involve data migration. Most organizations are using multiple data platforms where they are facing silos and data that cannot be extracted. A significant amount of inconsistency has been observed. To prevent and eliminate this, I have used Fabric Data extensively. That is the reason I have been using Fabric Data for three years.

I reduced around 60% latency using Fabric Data and created one single source of truth on the Microsoft ecosystem when working with a pharmaceutical industry. They were using multiple data sources, around six data sources, including Tracelink, SharePoint, and BigQuery, with the data coming in CSV format.

I have used Fabric Data for unified ETL with governance and compliance. Fabric Data offers a platform where anyone can use it with the capability to set roles and responsibilities, implement governance and compliance, and store data in a medallion form, which includes the Bronze, Silver, and Gold stages. It ensures data security and segregation of roles and responsibilities among individuals working in a company.

For one project, I used Lakehouse and Warehouse together. In the Bronze to Silver phase, Lakehouse was used, and for the Gold, the final curated layer, a Warehouse was used. This approach made the task simpler and improved team efficiency, running the complete pipeline efficiently.

Fabric Data offers Lakehouse and Warehouse capabilities, with Lakehouse being beneficial for PySpark users dealing with complex transformations. For less complex data, Warehouse serves as a viable option, both housed under one platform. It also supports the entire ETL to analytics and machine learning spectrum, beneficial for organizations handling large volumes of data. Fabric Data has helped me a lot and helped the organization to be the number one at itself.

First, Spark enablement and the time it takes to actually enable the Spark session takes a good amount of time. That can be optimized. The next thing I would appreciate is Copilot being integrated with all the cells in Spark, which can make coding easier. For security purposes, Purview can be integrated with Fabric Data. There is no need to create another software altogether.

Speed is a factor which Fabric Data says and confirms they will improve. The data speed will improve, but it is not a significant improvement as per the capability of Fabric Data. I would say roles and responsibilities are a bit difficult to set up in Lakehouse. It is just available in Warehouse right now. To set up the same in Lakehouse, it is a bit complex. Additionally, roles and responsibilities part is done, then the security part. There is no need to create a complete altogether software, which is MS Purview right now. It could have been integrated with Fabric Data itself as a security tab.

I have been using Fabric Data for around three years. I have completed around three projects with pharmaceutical industries, e-commerce industries, and I am currently working with the manufacturing industry as well. I have extensive experience with MS Fabric.

Coming up with a specific number would be difficult, but it is a significant win for us.

First, understand the business thoroughly. Always go step-by-step, complete the extraction completely, whether it is flowing incrementally or not. Once that is ticked out, jump on to the next process, which is data preprocessing. Most people directly jump on to creating the complete pipeline, which is a wrong step. As a data engineer, I should not jump onto the complete pipeline, I should progress step-by-step. I would rate this product a 7 out of 10.

We are pulling data from an upstream tool, which is D365 ERP, and pushing it to a particular DB or lakehouse for BI purposes, to be consumed by the BI users. We are using Fabric Data notebooks to integrate systems using Microsoft Graph APIs, pulling data from D365 ERP and pushing it to a compliance tool where the business users will make decisions.

Our main use cases for Fabric Data are building ETL and integrating systems. We are using data pipelines as well as Fabric Data notebooks majorly. We have also built an interim solution using SharePoint list and Fabric Data as an MDM solution, though it is not a true MDM.

We were using small-scale ETL tools called Sinch. We are now moving away from such tools as Sinch and Rally to Fabric Data, which provides a unique, unified way of working. It brings teams together and makes collaboration much easier. In that collaborative environment, we can include a BI user as part of a workspace, and end users can also be part of a workspace.

Collaboration has improved significantly. Fabric Data has data flow activities in the ETL data pipeline where a user without extensive data engineering knowledge can easily build an ETL data pipeline using those data flows, as long as they are familiar with DAX queries. This reduces the workload for data engineers.

I have observed some limitations with Fabric Data, especially when it comes to bringing data from private networks. Being a SaaS product, there is limited control, so having the option to create data gateways more easily within Fabric Data itself would be great. It would help to have more clarity about licensing capacities, as there are various capacities such as F16 and F64. A more detailed knowledge section within Fabric Data would be beneficial, while Microsoft Fabric Learn has extensive details, I would prefer to see this information integrated directly within Fabric Data itself.

The user interface of Fabric Data is quite standard, with regular changes published by Microsoft that come in handy when I have multiple tabs open. As for scalability, it is based on use cases. I do not think scalability is the biggest advantage of Fabric Data compared to any other Azure resources. We have auto-scaling in other facilities available, but it is not a major advantage compared to usage.

I have been using Fabric Data for two years.

I have not experienced any downtime or reliability issues with Fabric Data as of now.

I have not faced any issues with performance since the data we are processing currently is comparatively less. However, we have various systems to connect to, and since Fabric Data provides most of the functionalities available in ADF pipelines, I have nothing to complain about.

I have not encountered any challenges in scaling Fabric Data as of now, since the data volume is relatively low. I think it is very easy to scale it up and down.

The scalability of Fabric Data meets our needs as our data grows, as we have F16, F64, and other licensing capacities that fulfill our organization's requirements.

I have not reached out to customer support for Fabric Data at this point.

We were using small-scale ETL tools called Sinch. We are now moving away from such tools as Sinch and Rally to Fabric Data, which provides a unique, unified way of working. It brings teams together and makes collaboration much easier.

We were using small-scale ETL tools that did not have features such as drag and drop. Each data flow had to be configured using C#, and while they had some connection facilities to sources such as SQL Server and Amazon Marketplace, utilizing C# to orchestrate data workflows was challenging and time-consuming. The accuracy and visibility were comparatively low, which led us to switch to Fabric Data.

Compared to ADF, Fabric Data is much easier to build an ETL data pipeline. In ADF, I would have to create datasets and linked services, but with Fabric Data, I do not have to worry about it much and can directly go through and create a copy activity. As it is a kind of SaaS product, it is always better, and even a minor task such as building or adding an activity to send an email alert for an ETL data pipeline is much easier compared to ADF. In ADF, I have to create a web activity and call the URL to send the email alerts. There are many of these kinds of minor changes made on top of ADF, making it handy. The workspaces give better security control, and overall, the architecture built has security advantages compared to ADF. It is also very easy to set up.

I am not in a position to train the team, but personally, I find it very easy to learn. The user interface is nice, and there are plenty of resources available in Microsoft Learning and other various open sources.

We have certainly saved a significant amount of time by switching from small-scale tools to Fabric Data, which has improved visibility and increased accuracy.

I do not have much knowledge regarding pricing, setup costs, or licensing for Fabric Data because our Azure admin handles it.

We primarily operate within Azure, so our options were mainly ADF and Microsoft Fabric. Since we were already utilizing Power BI and ADF for data migration activities, it was a clear choice to adopt Fabric Data.

Security is a major challenge for our organization, as there are many users who work from different locations and have different roles. With Fabric Data, having workspaces and control over lakehouses and other resources allows us to maintain granularity and manage user access effectively, which has been a great advantage.

Within Fabric Data, I am using notebooks to integrate with other platforms and compliance tools. I need to be familiar with REST APIs and Microsoft Graph APIs. There are some inbuilt connections to Fabric Data, such as with Profisee, which provide an easier way to integrate.

Fabric Data provides a nice UI to track data lineage. For data governance, we are using Purview. For auditing and access management, we have the capability to assign the right access to each user based on their roles, which is a good advantage.

My advice for others considering using Fabric Data is to have prior knowledge about building ETL data pipelines. If they have worked with ADF, it makes their process much easier compared to someone who is coming directly to Fabric Data. Developers will have a significant advantage in creating their own data pipeline using DAX queries. I would rate Fabric Data an eight overall.

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.

I am leading the entire Fabric Data CI/CD project, where the development has already been completed in Fabric Data. I am here to enable CI/CD and environment segregation in Fabric Data, where I use Fabric Data CI/CD libraries. I also work on a data engineering project where I build pipelines from end to end.

I have used the Fabric Data CI/CD library and MD files to create the pipelines. I have also used Copy Data activities in Azure Data Factory.

Because it is under one ecosystem, our time has been saved. Cost has been saved but not as much as I expected it to be.

Money and time have been saved significantly. The training and cost of training for people has reduced because Fabric Data is quite easy to understand.

The best features are that the entire ecosystem is inside Microsoft and it is under a SaaS platform. I do not have to rely on any other tools or cross-functional tools to deploy or develop. The entire CI/CD, from development to testing to deployment, the entire operation can be done under the same Fabric Data platform.

The all-in-one system has been the most helpful for me.

Earlier we used to rely on different tools and had to purchase different enterprise-level tools. Different billing used to happen and they were not in line or were very inconsistent. Now that the entire thing comes under a single ecosystem, we do not have such issues.

Fabric Data needs more ecosystem support.

It needs a lot of support on the CI/CD part. It is still in development.

It needs more improvement on aspects like CI/CD.

I have been using Fabric Data for four months.

Currently, as Fabric Data is new, Microsoft is constantly developing it. There were a lot of issues in the initial days, but now Microsoft is working and trying to make it better every day.

Fabric Data does not have scalability issues.

Customer support receives a rating of six out of ten because they themselves are trying to figure out what is new and what the issue is.

I did not switch anything. Since the start, I have been in Azure and Azure cloud only.

I was considering choosing Databricks, but we are Microsoft partners, so I did not.

The initial setup was smoother than other tools.

The implementation team can use Fabric Data properly.

My overall review rating for Fabric Data is six out of ten.