Fabric Origin Studio

Fabric Data  is used for ingestion purposes and some transformation tasks. When data exists in specific sources, we ingest data from those particular sources and load that data into our staging or landing zone while dynamically passing variables. The ingested data is then transformed, and we use it for creating dimensions and fact tables. Once everything is properly modified, that data goes into our published layer, which our business people use.

I work for a service-based company where many of our clients use Fabric Data . They mostly use it for ingestion purposes. We create one job, and the pipeline is created with multiple tables loaded based on that. Fabric Data is very useful for our organization and our clients as well, saving time, simplicity, and offering many benefits. Some parts we use custom solutions for too, and due to Fabric Data, our clients and our organization save money, speed, and time.

I am using Fabric Data in our organization on a private cloud.

Recently, I find the copy feature of Fabric Data very helpful. The copy feature is very simple. I already work both on-premises and in the cloud. On-premises, we copy data from specific databases to other databases for their testing or development purposes. With zero-copying, we just copy some data for development or testing purposes, which is very easy to use and requires no maintenance. That is good. There are many features.

Fabric Data is very useful for our organization and our clients as well, saving time, simplicity, and offering many benefits. Some parts we use custom solutions for too, and due to Fabric Data, our clients and our organization save money, speed, and time.

I would add one thing regarding improvements for Fabric Data. Most of the ingestion teams or tools are adding AI aspects into the existing tools. I suggest the same thing—adding some AI features, such as "Coco" in Snowflake  or "Genie " in Databricks . You should also incorporate some parts where our code can identify quickly, and developers can understand fast based on that. Integrating those AI features into Fabric Data would be beneficial. If you improve some additional things, that would be a good part.

Fabric Data should be able to understand governance and security regarding its AI capabilities because that is very important for AI solutions. Client data is more crucial than any task, and that aspect should be covered.

Some improvements are needed for Fabric Data from the AI side. Day by day, AI is improving, and automating jobs is essential. The good thing is that you should continue developing your AI features.

I have been using Fabric Data for two years, which is twenty-four months.

Fabric Data is stable.

The scalability is good. Out of ten, I can give it a nine.

Customer support for Fabric Data is also good. Out of ten, I can give it a ten.

We have not previously used a different solution, but sometimes clients needed that specific aspect. However, mostly we are using Fabric Data.

We directly connected with Fabric Data without evaluating other options.

My experience with pricing, setup cost, and licensing is that pricing and those aspects are a different matter. It is not a concern for me because it matters to the client. Compared to other options, it is good—neither very high nor very low.

Most people find Fabric Data simple to use and workable. If your cost is less, then that is a substantial matter.

I rate Fabric Data a ten out of ten overall.

I choose a ten out of ten for Fabric Data because it is very simple to use. It is excellent for our work purpose and is easy to use. Support for Fabric Data is good as well, and most of the clients also use this feature, which is also a good part. There are many features as well.

The accuracy and reliability of Fabric Data's output are good compared to others, and its reliability is also good.

If someone is looking into using Fabric Data, I would advise choosing Fabric Data because currently in the market, Fabric Data is good compared to others. My overall review rating for Fabric Data is ten out of ten.

Fabric Data  serves as my main solution for day-to-day operations, depending on the services we implement for our needs.

We use Fabric Data  for deeply integrated fabrics, data flows, and more efficiently integrate it with Power BI for reporting models.

For any requirement with Fabric Data, if the source volume is less than a terabyte, or for day-to-day handling of data volumes in terabytes, Fabric Data is a good service that provides end-to-end services we can rely on.

Fabric Data offers best-in-class features including one unified platform for a data lake and data service, so we do not need to have separate storage or separate services for each function.

For example, when using Fabric Data with streaming data, we can integrate from the streaming application and then store it in the data lake.

The impact of Fabric Data on my organization is positive; for costing, it is very effective since it uses a capacity-based model.

Fabric Data could be improved in the future by increasing the size capability from terabyte to petabyte for deeper integration.

Already built-in ADF integrated with Fabric Data means that in terms of integration, it is very good and similar to ADF.

I have been using Fabric Data for around six months to one year.

Fabric Data is stable; scalability is managed by designing its metadata framework more effectively.

Customer support for Fabric Data depends on the volume and type of services the business fits into the solution.

The earlier solution was in staging.

Before choosing Fabric Data, we evaluated other options, but since our current source system is more focused on Microsoft-based services, we decided to go with Fabric Data.

I have seen a return on investment that is highly notable; the solutions I am getting from transitioning traditional ETL solutions to Fabric Data are remarkable.

My experience with pricing, setup cost, and licensing is limited; these factors are decided by the customer engaging this framework.

The accuracy and reliability of Fabric Data's output depend on how you design the solution based on the requirements.

My advice for others looking into using Fabric Data is to understand the existing services according to their requirements.

TCS  is already a partner; for any suggestions or upcoming solutions, they will choose Fabric Data based on customer and organizational discussions.

Before concluding, I recommend considering capacity-based requirements when choosing Fabric Data.

My overall review rating for Fabric Data is 7 out of 10.

My main use case for Fabric Data  is that I have been using Fabric  for around one and a half to two years, and typically in our project, we have been trying to shift from regular Azure-based services and Databricks  services to Fabric  itself because it is a complete all-in-one solution. We have been creating new pipelines in Fabric, and all development is being done in Fabric itself because it supports pipelines and notebooks. Previously, we were using notebooks from Databricks  and pipelines from Azure Data Factory , but currently, we are utilizing the notebooks and pipelines in Fabric itself, and the storage and everything is in the same UI, making it easier for us. We are doing complete end-to-end development in Fabric itself.

A quick specific example of a use case where Fabric Data  made a big difference for my team is that previously we had to create our notebooks in Databricks and deploy those notebooks separately, and we had to deploy our pipelines separately. This was a scenario that we overcame by creating the pipelines and notebooks in the same place and deploying them directly by using deployment pipelines. This was a big difference for us. Previously, all things were scattered. We were using Synapse  Analytics for storing our data and ADLS for storing our files and tables, so everything was scattered across different services. Now we have everything under a single umbrella.

The best features that Fabric Data offers are the unified UI and seamless integration, and these are the standout features for me.

Fabric Data has helped my project further because previously we were connecting Power BI to Synapse  Analytics itself, but now that we have data warehouses and lakehouses in place, we can directly connect here as well. The UI is easier, and the data governance team has found it easier to manage access and everything at a single place because previously they had to manage access for all the different services individually. For ADLS, they had to give different access and add different user groups, which was hectic. For me, when I was doing some proofs of concept, it was very difficult to understand. Currently, access and everything is simplified in Fabric, which is another valuable aspect.

Fabric Data has impacted my organization positively because collaboration has been better and deployments have been faster. Deployments have been faster, getting access sorted out has been faster, and the overall project nomenclature and the whole project structure has been simplified because everything can be found at a subfolder level and folder level. We do not have to go to Azure Data Factory  to find pipelines, and we do not have to go to Synapse to find warehouse data. We do not have to go to ADLS and we do not have to go to its directory to find source files or archive files. Everything is in a single UI, so it saves time for development and also for the data governance team for giving and managing accesses and for our data operations people for doing deployments.

One thing regarding needed improvements is related to the free tier or trial capacity. When I was learning Microsoft Azure  services, it was very easy to get credits and a free account, but in Fabric, it was inconvenient to get a free tier or trial capacity. It was a very difficult and cumbersome process, so we found upskilling ourselves in Fabric difficult. If that gets sorted out, then many people can easily learn because Fabric is very easy software, and people can learn easily once the free trial capacity gets figured out.

I have been using Fabric Data for four years.

Fabric Data is quite stable, and I have not faced any downtime issues.

Fabric Data's scalability is good because it handles growing workloads well.

Before using Fabric Data, we were using Azure  and Databricks, and it was very difficult to manage everything individually. It has been much easier for us now.

My experience with pricing, setup cost, and licensing was that this was done by our data governance team. I did not have any role in this setup and pricing.

Before choosing Fabric Data, we evaluated other options in Databricks, which we have used extensively, and it also had similar features.

Since moving to Fabric Data, I have saved around ten hours per month, but that is a very rough estimate because I have never thought in this way or never had a metric regarding this.

Regarding Fabric Data's governance and security, I think these aspects are great and have been proving very useful for our data governance team.

I have not used much of Fabric Data's AI capabilities, so I might not be able to answer that question fully.

I would recommend others looking into using Fabric Data to check out Databricks itself if possible, but I am not sure about the pricing part. Our project had people who checked it, so if they have considered Fabric over Databricks, then I think it is well and good. If you are coming from a setup of Azure plus Databricks or just Azure, Fabric makes a lot of sense. I would rate my overall experience with Fabric Data as an eight point five out of ten.

Approximately 90% of our projects are based on Fabric Data  because we are the data solution team, and we provide solutions that clients primarily request. From the last two years, most projects have been on Fabric Data . The remaining 10% involves on-premise solutions because we also work with some banking and telecom companies that prefer to avoid moving data to the cloud, so they use on-premise solutions like Informatica PowerCenter , Informatica BDM, and Denodo-related solutions.

We are currently only suggesting Fabric Data to clients. When they come with their requirements, we inform them about specific suggestions we can proceed with. They typically need solutions related to cost efficiency, performance, and comprehensive final reporting.

Customers usually use Fabric Data for warehousing because it is fundamentally a warehousing solution combined with business intelligence reporting. The second priority is the AI functionality to create AI modules. Since we provide a centralized solution, the complete client data from the company will be inserted into Fabric Data so they can easily apply AI models and business intelligence reporting.

The most valuable features or capabilities of Fabric Data vary based on requirements and different scenario needs since we are not moving to the OLTP system.

What I appreciate about Fabric Data is that it is easy to use and user-friendly. Additionally, it is cost-efficient. When clients come with solutions, their first and priority question is cost—how much they will be charged. Fabric Data offers an easy-to-use and cost-efficient solution.

Regarding Fabric Data's data integration feature, it is very good because of its compatibility. We have multiple connectors, and we can directly connect with the dynamic using Synapse  Link. There is no requirement for any development, and we have direct connectivity with shortcuts for some cloud integration, meaning from AWS  to Fabric Data. You do not need to implement any pipeline; it is simple to configure the connector, and all tables from AWS  can be available within Fabric Data in minutes. The connectivity for cloud infrastructure is very good within Fabric Data.

Fabric Data's machine learning for predictive analytics is very good because the power engine with PySpark provides excellent performance impact. We can apply multiple different levels of AI modules, such as forecasting and other suggestions. This is effective because I also use Databricks  and Data Robot, which are similar to Fabric Data, but Fabric Data has a larger picture making it easier to use.

Within Fabric Data, we have resources like Microsoft Purview , which provides governance capabilities. It is very easy to configure Fabric Data with Purview , and it provides complete lineage and metadata management easily. It requires only configuration with no extra development or additional inputs.

I find Fabric Data effective in real-time processing and providing timely insights for key business decisions. Fabric Data has provided PySpark capabilities along with webhook configurations. We can easily configure Fabric Data with real-time data, though there is a minimal separate cost associated with it. Based on the licensing cost, we can easily work with real-time data and also with near-to-real-time data.

I cannot say that the analytics and reporting capabilities of Fabric Data are good enough because it only provides compatibility with Microsoft Power BI . If the client has Tableau licensing other than Power BI, they might experience latency and performance issues within Fabric Data. Fabric Data is easy to use only with Power BI, so there is some limitation with the Power BI integration; it is not flexible for all tool integrations.

I would like them to improve the integration with third-party tools, as clients might experience latency and other issues.

Other than integration with third-party tools, I think Fabric Data could be improved and enhanced by advancing AI functionality. The global market is revolving around AI, so they need to focus on AI development within Fabric Data, making it a bit more configurable through visual screens. Currently, we work with data coding, so they might need to come up with layout screens to easily configure things, and the pipeline can be easily metadata-driven.

We have been using it for more than two years.

Regarding the stability and reliability of Fabric Data, I think it is good. I do not have any complaints about that. We have been using it for more than two years, and there have not been any major issues with resource availability or anything with the development team working. Fabric Data is active and available twenty-four hours a day, seven days a week.

The scalability of Fabric Data is very easy, but it depends on whether you have a dedicated server. If you do, you can avoid scaling up the server manually. By default, based on load processing, it automatically scales up. It is not a problem to manage; Fabric Data manages itself.

For the technical support of Fabric Data, we have a separate DevOps team and an administration team here. If we encounter any issues, the Microsoft ticket log creation process and the support team are good and cooperative, so I do not have any complaints beyond this.

I have participated in the initial setup of Fabric Data.

Participating in the initial setup of Fabric Data is very easy; you only need some administrative rights. It requires just two or three clicks, and the environment is ready for development and production easily. There is no extra effort or additional input; it is just a few clicks away.

Fabric Data is only affordable and cost-effective if you proceed with a long-term commitment and have a license for one or two years with completely dedicated servers. It will be cost-effective, but if we go with the pay-as-you-go and monthly basis, then it will be expensive. With pay-as-you-go, you have to manage most of the things yourself. You have to pause the servers and do some manual interventions.

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.