Tag: Data-Warehouse

Data Warehouse is a topic the MagnusMinds engineering team writes about from project work: how it is set up, where it breaks, and what we changed in production. This tag page lists all 4 articles tagged Data Warehouse.

Start with “We built a multi-tenant SaaS on Microsoft Fabric with a workspace for every customer”, “MS SQL Server for Scalable Database Solutions for 2025”, or “MySQL Federated Engine Data Migration”. Open a post for the full write-up, or follow another tag or category on the card to a related topic.

We built a multi-tenant SaaS on Microsoft Fabric with a workspace for every customer
Oct 02, 2026 7 min read

Most Microsoft Fabric projects serve one organization. Ours had to serve many. A cloud cost management (FinOps) software provider asked us to build the data platform behind their product: collect each customer's Azure and AI spending, turn it into one standard format, and serve it to dashboards and an AI assistant. Every customer had to see only their own data, onboarding had to be automatic, and the platform had to grow region by region. We built it entirely on Microsoft Fabric, with a dedicated workspace for every customer. This post walks through the design, the parts that made it work in production, and what we would tell any team building SaaS on Fabric. The challenge (pain points in real operations) A single-tenant Fabric design is straightforward. Multi-tenant SaaS raises harder questions, and each one had to be answered before the first customer went live. Isolation that can be proven: Customers trust you with billing data. "We are careful" is not enough. The platform had to show, automatically, that one customer's reports can never read another customer's data. One codebase, many customers: Every customer needed the same pipelines, the same data model and the same app. Hand-built workspaces drift apart within weeks. Onboarding without a project: Each new customer needed groups, storage, pipelines, a semantic model, an app and credentials. Doing that by hand would turn every sale into a mini-project. Capacity cost: Fabric capacity is billed whether it is busy or idle. Sizing it for the heaviest nightly run all day would waste money. Growth by region: Customers in different geographies expect their data to stay in region, and an incident in one region should not affect the others. What we built (tailored solution, delivered end-to-end) We designed the platform around three ideas: a regional deployment holds everything a set of customers needs, every customer gets their own workspace, and nothing is created by hand. 1. Regional deployments (growth and blast radius) Customers are placed on regional deployments, sometimes called deployment stamps. Each deployment has its own Fabric capacity, Azure Key Vault, Azure Function Apps and a core Fabric workspace. The core workspace holds the shared notebooks and pipelines, plus a Fabric SQL database that acts as the customer registry. The registry lists every customer with their workspace and lakehouse IDs, status and settings. Pipelines never hard-code a customer. They read the registry at run time. Adding a region means standing up a new deployment from the same templates. An issue in one deployment stays inside it. 2. A workspace per customer (isolation by design) Every customer gets a dedicated Fabric workspace containing: Bronze, Silver and Gold lakehouses in a Medallion Architecture A Direct Lake semantic model that holds every business measure The customer-facing Fabric App, built with Microsoft's Rayfin SDK A Fabric Data Agent that answers plain-English cost questions from that customer's model only Access is controlled through Microsoft Entra security groups per customer. Each customer's Azure credentials live in Key Vault and are read at run time, never stored in code. The important part is that isolation is tested. An automated check confirms that each customer's semantic model is bound only to that customer's own Gold lakehouse, and a read-only smoke test runs across every active customer on a deployment. 3. One pipeline run for every customer (one codebase) The transformation logic is written once and runs for everyone. A master pipeline reads the active customers from the registry, and a ForEach activity runs the per-customer pipeline for each of them: Converting Azure, OpenAI, Anthropic and Microsoft Copilot spend into FOCUS, the open standard for cloud cost data Cost allocation to teams, budgets, anomaly detection and savings recommendations Reservations, price sheets and Microsoft 365 usage A semantic model refresh at the end Every notebook and pipeline lives in source control. Processing is incremental: a watermark table records what each customer has already processed, so nightly runs only touch new data. Ingestion that needs customer credentials stays in Azure. Azure Durable Functions call the Cost Management API, Azure Resource Graph, Microsoft Graph and AI vendor usage APIs, and write Delta tables straight into each customer's OneLake. Azure cost export files reach Fabric through OneLake shortcuts, so raw files are never copied. 4. Onboarding as a workflow (one run instead of a project) Onboarding a customer is a single automated workflow. It: Creates the Entra groups Adds the registry entry Creates the workspace and the three lakehouses Stores the customer's credentials in Key Vault Deploys the semantic model, the app and the Data Agent Runs the isolation check Offboarding reverses it. One detail saved us more than once. A semantic model fails to deploy if it references a table that has no data yet. We generate a skeleton schema listing every table and column the model expects, create empty tables from it at onboarding, and backfill new tables into existing customers. A CI test also checks that every column a notebook writes exists in the model, so a schema change cannot break every customer overnight. 5. Capacity that follows the workload (cost control) Each deployment has two capacity sizes: a smaller resting size for daytime reading and a larger size for the nightly processing run. The capacity scales up before the run and scales down as soon as the master pipeline finishes, rather than after a fixed duration. The app also caches semantic model query results against a data-version stamp, which removes repeated identical queries and keeps the capacity free for real work. 6. Customer-hosted delivery (data residency) Some enterprise customers cannot allow their reporting data to sit in a supplier's tenant. For them, processing stays in the provider's tenant and only the finished Gold data is published into the customer's own Fabric tenant. The semantic model and app run there on the customer's capacity, and no copy is left on the provider's side. That deserves its own post, and we will cover how we built and tested it separately. Real-world impact (what changed after rollout) Isolation you can show an auditor: An automated check proves each customer's model reads only their own data, on every deployment. Onboarding in one workflow: A new customer goes from contract to live workspace, model, app and AI assistant without hand-built steps. One codebase for every customer: A fix or feature in a notebook, pipeline or model reaches all customers in the next release. Lower capacity cost: Compute is sized up only while the nightly run is actually running. Room to grow: New regions are new deployments from the same templates, with problems contained to one deployment. What we would tell any team building SaaS on Fabric Decide your isolation unit first. For us it was the workspace. Everything else, from access groups to deployment scripts, followed from that choice. Keep a registry and read it at run time. Pipelines that look up their customer list never need editing when a customer joins or leaves. Treat every Fabric item as code. Notebooks, pipelines, lakehouses and the semantic model all live in Git and deploy the same way to every workspace. Test isolation automatically. A check that runs on every release catches a binding mistake before a customer does. If you are planning a multi-tenant product or a large data platform on Microsoft Fabric, we would be glad to share what we learned. Connect with us to talk through your architecture.

MS SQL Server for Scalable Database Solutions for 2025
Apr 16, 2025 5 min read

As we approach 2025, the shift towards cloud-native database solutions is becoming undeniable. Businesses are increasingly moving away from traditional on-premise databases, opting for cloud technologies that offer scalability, flexibility, and cost-efficiency. But with this transition comes the challenge of understanding how to leverage these cloud-native databases effectively. In this article, we’ll explore the future of database solutions, the rise of cloud-native technologies, and how organizations can make the most of these advancements. At MagnusMinds, we specialize in helping businesses navigate the evolving landscape of cloud-based databases, ensuring they remain competitive by adopting cutting-edge solutions. Let's dive into why cloud-native databases are set to dominate in 2025 and beyond. What is Microsoft SQL Server? Microsoft SQL Server is an enterprise-grade RDBMS developed by Microsoft that offers a comprehensive suite of tools for managing and analyzing structured data. Known for its performance, reliability, and security, SQL Server is widely used in industries such as finance, healthcare, e-commerce, and manufacturing. Key Reasons MS SQL Server Remains a Top Choice 1. High Performance and Scalability: MS SQL Server is designed to scale from small single-machine applications to massive cloud-native environments. With in-memory processing, columnstore indexes, and intelligent query processing, it delivers lightning-fast performance even under heavy loads. 2. Advanced Security Features: Security is non-negotiable in today’s data-driven world. SQL Server offers features like: Transparent Data Encryption (TDE) Always Encrypted Row-Level Security Dynamic Data Masking Role-based Access Control These capabilities ensure that sensitive business data is protected at all times. 3. Integration with Microsoft Ecosystem: Seamless integration with tools like Azure, Power BI, Excel, .NET, and now Microsoft Fabric makes SQL Server the centerpiece of the Microsoft data stack. With Fabric, businesses can unify data from multiple sources into a lakehouse architecture that blends the scalability of data lakes with the performance of a data warehouse. This empowers users to build end-to-end data pipelines, perform real-time analytics, and create rich visualizations all from a single, integrated platform. In addition to Microsoft tools, SQL Server data can be easily connected to third-party BI platforms like Domo, offering alternative ways to visualize and analyze data for different user preferences. Whether it's advanced modeling with Power BI or executive dashboards with Domo, SQL Server serves as a powerful and flexible data foundation. 4. Comprehensive Business Intelligence (BI) Capabilities: SQL Server includes SQL Server Integration Services (SSIS), SQL Server Reporting Services (SSRS), and SQL Server Analysis Services (SSAS). This suite empowers businesses to: Perform ETL (Extract, Transform, Load) operations Create interactive dashboards and reports Analyze multidimensional data models Seamlessly integrate with Microsoft Fabric for enhanced analytics across lakehouses and data warehouses For organizations needing robust data integration across cloud and on-premises sources, Talend is often used alongside SQL Server. Talend’s ETL and data quality tools provide extended capabilities in managing complex data workflows, making it easier to deliver trusted, unified data to reporting tools and dashboards. 5. Cloud Readiness and Hybrid Flexibility: SQL Server supports deployment across on-premises, cloud (Azure, AWS), and hybrid environments. It enables businesses to modernize their data infrastructure at their own pace without compromising on functionality or security. 6. Support for AI & ML Integration: With built-in support for R and Python, SQL Server enables direct integration of AI and ML algorithms into data pipelines, making it easier for businesses to implement predictive analytics and automated decision-making. MagnusMinds: Your Trusted Partner for MS SQL Development With 20+ years of experience in delivering scalable IT solutions, MagnusMinds stands out as a leading provider of MS SQL Server development services. Our team of certified database professionals leverages the full power of SQL Server to craft tailored solutions for: Database Architecture & Design T-SQL Programming & Query Optimization SSIS/SSRS/SSAS Implementation Data Warehousing & ETL Pipelines SQL Server Performance Tuning Database Migration & Modernization Whether you're starting from scratch or upgrading a legacy system, we align SQL Server capabilities with your business goals to deliver measurable results. Real-World Use Case: Enhancing Operational Efficiency A large logistics firm partnered with us to redesign their database system using SQL Server. By optimizing indexes, rewriting T-SQL queries, and implementing SSIS for ETL, we achieved the following results: 55% faster report generation 40% reduction in query execution time Real-time data synchronization across branches This directly translated into better decision-making, reduced operational costs, and improved customer satisfaction. Future-Proofing Your Data Strategy With consistent updates, a strong community, and deep cloud integration including seamless compatibility with Microsoft Fabric SQL Server continues to evolve as a cornerstone for enterprise data strategy. Its flexibility, reliability, and extensive toolset make it ideal for businesses aiming to scale and innovate. Whether you're building a modern lakehouse, enhancing your data warehouse, or seeking real-time data insights through Power BI, Domo, or integrated ETL tools like Talend, SQL Server provides the foundation to achieve it. Final Thoughts If you're looking to build scalable and secure database solutions that can adapt to your growing business needs, Microsoft SQL Server is the platform to trust. MagnusMinds is here to help you harness its full potential with customized development, integration, and optimization services. Contact us today to schedule a free consultation and let’s transform your data into actionable insights.

MySQL Federated Engine Data Migration
Mar 13, 2024 4 min read

Scenario: If someone say you Hey, can you transfer one of MySQL data to another MySQL data and we think about SSIS or other Thing if yes then these article made for you to reduce your effort and save your time Introduction: In the dynamic landscape of database management, the need to seamlessly access and integrate data from multiple sources has become paramount. Whether it's consolidating information from disparate servers or synchronizing databases for backup and redundancy, MySQL offers a robust solution through its querying capabilities. In this guide, we delve into the art of fetching data from one MySQL server to another using SQL queries. This method, often overlooked in favor of complex data transfer mechanisms, provides a streamlined approach to data migration, enabling developers and database administrators to efficiently manage their resources. Through a combination of MySQL's versatile querying language and the innovative use of the FEDERATED storage engine, we'll explore how to establish connections between servers, replicate table structures, and effortlessly transfer data across the network. From setting up the environment to executing queries and troubleshooting common challenges, this tutorial equips you with the knowledge and tools to navigate the intricacies of cross-server data retrieval with ease. As we know We gonna use FEDERATED feature of MySQL workbench so first we need to check that our workbench support FEDERATED engine or not?   Simply open workbench and run below code show engines;   It shows all engines and check our system support FEDERATED OR NOT   If your system also not support don't worry we gonna enable it Open your folder where you save MySQL serve file In my case it in my C drive C>ProgramData>MySQL>MySQL Server 8.0>my.ini    open it in notepad++ or preferable software    Insert FEDERATED key word in script like below   Now need to restart MySQL Press Window+R button and paste services.msc press ok> find MySQL and restart it Now go to workbence and run show engines;  code   Now your FEDERATED engine get supported It show like below   Now our system Support FEDERATED engine This same process need to apply on destination side because both server (from source to destination server) need to support FEDERATED engine Now we make sure to we have permission of access source server for that we need to make user and and give permission of database and tables   Below code demonstrate to make user and give permission to user CREATE USER 'hmysql'@'192.168.1.173' IDENTIFIED BY 'Hardik...'; GRANT ALL PRIVILEGES ON *.* TO 'hmysql'@'192.168.1.173' WITH GRANT OPTION; FLUSH PRIVILEGES;   Now make connection of that user(we make above on source side) on destination server(our system)    Click on plus(+) icon as shown in image and fill all detail   Below image is for detail of user connection   After filling details our user added like below image   Go to user(hardikmysql) and find from which table we want to take data using MySQL query    Here i am taking 'actor' table from 'sakila' database which look like below   Now we need to run FEDERATED query on our system(destination server) with url string   Our MySQL query like below CREATE TABLE `actor` ( `actor_id` smallint unsigned NOT NULL AUTO_INCREMENT, `first_name` varchar(45) NOT NULL, `last_name` varchar(45) NOT NULL, `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`actor_id`), KEY `idx_actor_last_name` (`last_name`) ) ENGINE=FEDERATED default charset=utf8mb4 CONNECTION='mysql://hmysql:[email protected]:3306/sakila/actor';   Here main part is below ENGINE=FEDERATED default charset=utf8mb4 CONNECTION='mysql://hmysql:[email protected]:3306/sakila/actor';   Here 'mysql' is mandatory for connection string you can not use other word. 'hmysql' is user name 'Hardik...'  is password for user '192.168.1.173' is server adderess '3306' is port number 'sakila' is database name 'actor' is table name   Now run above table code and you get data in our system(destination server)    

Quick CSV to SQL with Azure Databricks | MagnusMinds Blog
Apr 14, 2023 5 min read

In this blog, we will explore Azure Databricks, a cloud-based analytics platform, and how it can be used to parse a CSV file from Azure storage and then store the data in a database. Additionally, we will also learn how to process stream data and use Databricks notebook in Azure Data Pipeline.   Azure Databricks Overview Azure Databricks is an Apache Spark-based analytics platform that provides a collaborative workspace for data scientists, data engineers, and business analysts. It is a cloud-based service that is designed to handle big data and allows users to process data at scale. Databricks also provides tools for data analysis, machine learning, and visualization. With its integration with Azure Storage, Azure Data Factory, and other Azure services, Azure Databricks can be used to build end-to-end data processing pipelines.   Parsing CSV File from Azure BlobStorage to Database using Azure Databricks Azure Databricks can be used to parse CSV files from Azure Storage and then store the data in a database. Here are the steps to accomplish this:   Configure Various Azure Components 1. Create Azure Resource Group Image 1 2. Create Azure DataBricks Resource  Image 2 3. Create SQL Server Resource  Image 3 4. Create SQL Database Resource Image 4 5. Create Azure Storage Account  Image 5 6. Create Azure DataFactory Resource  Image 6 7. Launch Databricks Resource Workspace  Image 7 8. Create Computing Cluster  Image 8 9. Create New Notebook  Image 9   Parsing CSV File from Azure Storage to Database using Azure Databricks Azure Databricks can be used to parse CSV files from Azure Storage and then store the data in a database. Here are the steps to accomplish this: 1. Create a cluster: First, create a cluster in Azure Databricks as above. A cluster is a group of nodes that work together to process data. 2. Import all the necessary models in the databricks notebook  %python from datetime import datetime, timedelta from azure.storage.blob import BlobServiceClient, generate_blob_sas, BlobSasPermissions import pandas as pd import pymssql import pyspark.sql Code 1 3. Mount Azure Storage: Next, mount the Azure Storage account in Databricks as follows #Configure Blob Connection storage_account_name = "storage" storage_account_access_key="***********************************" blob_container = "blob-container" Code 2 4. Establish The DataBase Connection #DB connection conn = pymssql.connect(server='****************.database.windows.net', user='*****', password='*****', database='DataBricksDB') cursor = conn.cursor() Code 3 5. Parse CSV file: Once the storage account is mounted, you can parse the CSV file using the following code #get a list of all blob from the container blob_list = [] for blob_i in container_client.list_blobs(): blob_list.append(blob_i.name) # print(blob_list)      df_list = [] #Generate SAS key for each file and load to the dataframe  for blob_i in blob_list:     print(blob_i)     sas_i = generate_blob_sas(account_name = storage_account_name,                              container_name = blob_container,                              blob_name = blob_i,                              account_key = storage_account_access_key,                              permission = BlobSasPermissions(read=True),                              expiry = datetime.utcnow() + timedelta(hours=12))       sas_url = 'https://' + storage_account_name +'.blob.core.windows.net/' + blob_container + '/' +blob_i     print(sas_url)          df=pd.read_csv(sas_url)     df_list.append(df) Code 4 6. Transform and Store data in a database: Finally, you can store the data in a database using the following code #Truncate Table Sales Truncate_Query = "IF EXISTS (SELECT * FROM sysobjects WHERE name='sales' and xtype='U') truncate table sales" cursor.execute(Truncate_Query) conn.commit()   # SQL Query For Table Creation create_table_query = "IF NOT EXISTS (SELECT * FROM sysobjects WHERE name='sales' and xtype='U') CREATE TABLE sales (REGION  varchar(max),COUNTRY  varchar(max),ITEMTYPE  varchar(max),SALESCHANNEL  varchar(max),ORDERPRIORITY  varchar(max),ORDERDATE  varchar(max),ORDERID  varchar(max),SHIPDATE  varchar(max),UNITSSOLD  varchar(max),UNITPRICE  varchar(max),UNITCOST  varchar(max),TOTALREVENUE  varchar(max),TOTALCOST  varchar(max),TOTALPROFIT  varchar(max))IF NOT EXISTS (SELECT * FROM sysobjects WHERE name='sales' and xtype='U') CREATE TABLE sales (REGION  varchar(max),COUNTRY  varchar(max),ITEMTYPE  varchar(max),SALESCHANNEL  varchar(max),ORDERPRIORITY  varchar(max),ORDERDATE  varchar(max),ORDERID  varchar(max),SHIPDATE  varchar(max),UNITSSOLD  varchar(max),UNITPRICE  varchar(max),UNITCOST  varchar(max),TOTALREVENUE  varchar(max),TOTALCOST  varchar(max),TOTALPROFIT  varchar(max))" cursor.execute(create_table_query) conn.commit()   #Insert Data From Main DataFrame for rows in df_combined.itertuples(index=False,name=None):     row = str(list(rows))     row_data = row[1:-1]     row_data = row_data.replace("nan","''")     row_data = row_data.replace("None","''") insert_query = "insert into sales (REGION,COUNTRY,ITEMTYPE,SALESCHANNEL,ORDERPRIORITY,ORDERDATE,ORDERID,SHIPDATE,UNITSSOLD,UNITPRICE,UNITCOST,TOTALREVENUE,TOTALCOST,TOTALPROFIT) values ("+row_data+")"     print(insert_query)     cursor.execute(insert_query) conn.commit() Code 5 As, Shown here The data from all the files is loaded to the SQL server Table Image 10   Azure Databricks notebook can be used to process stream data in Azure Data Pipeline. Here are the steps to accomplish this: 1. Create a Databricks notebook: First, create a Databricks notebook in Azure Databricks. A notebook is a web-based interface for working with code and data. 2. Create a job: Next, create a job in Azure Data Factory to execute the notebook. A job is a collection of tasks that can be scheduled and run automatically. 3. Configure the job: In the job settings, specify the Azure Databricks cluster and notebook that you want to use. Also, specify the input and output datasets. 4. Write the code: In the Databricks notebook, write the code to process the stream data. Here is an example code: #from pyspark.sql.functions import window stream_data = spark.readStream \     .format("csv") \     .option("header", "true") \     .schema("<schema>") \     .load("/mnt/<mount-name>/<file-name>.csv")   stream_data = stream_data \     .withWatermark("timestamp", "10 minutes") \     .groupBy(window("timestamp", "10 Code 6   How To Use Azure Databrick notebook in Azure Data Factory pipeline and configure the DataFlow Pipeline Using it. Image 11 1. Create ADF Pipeline  Image 12 2. Configure Data Pipeline  Image 13 3. Add Trigger To the PipeLine  Image 14 4. Configure the trigger  Image 15   These capabilities make Azure Databricks an ideal platform for building real-time data processing solutions. Overall, Azure Databricks provides a scalable and flexible solution for data processing and analytics, and it's definitely worth exploring if you're working with big data on the Azure platform. With its powerful tools and easy-to-use interface, Azure Databricks is a valuable addition to any data analytics toolkit.