Microsoft Fabric vs Snowflake for external company data

External company data arrives the same way whichever platform you run: as files, or as pages from an API, that must become tables you can join to your own. This comparison takes one such file into Microsoft Fabric and into Snowflake and sets the two side by side where the work differs: where the file waits, how it is loaded, how a JSON cell is read, what each platform bills for, and how the two read each other's tables when a company runs both. Every statement about either platform comes from its own documentation, read on 4 October 2026.

Fabric and Snowflake are where a team keeps its own tables and joins other data to them. Fokals supplies data for that join: firmographic, technographic, hiring and intent data on public and private companies, refreshed daily. It is delivered direct, by REST API and as bulk files in CSV, JSON or JSON Lines, which you load with the platform's own loader, as the sections below show. The file used here is a daily export of Hiring Activity from the hiring dataset: the open, new and closed postings of each company. The data dictionary describes it: CSV in UTF-8 with one header row, one row per company and closed UTC day, and the open postings by job function held as a JSON object in a single cell.

The two side by side

Two shapes of platform

Microsoft's overview describes Fabric as an analytics platform delivered as software as a service. Its workloads, among them Data Factory, Data Engineering, Data Warehouse and Power BI, work over OneLake, one logical data lake for each tenant. For tables it offers two stores, compared in Microsoft's decision guide. A lakehouse is developed with Apache Spark and exposes a read-only SQL analytics endpoint. A warehouse is developed in T-SQL and supports multi-table transactions. Both keep their tables in Delta Lake format in OneLake.

Snowflake's key concepts describe one service in three layers. Storage reorganises loaded data into an internal compressed, columnar format. Compute is the virtual warehouse, a cluster that shares no compute with other warehouses. Cloud services coordinate the rest. The page says there is no hardware for you to select or manage and that Snowflake cannot be installed locally or on private cloud infrastructure.

So the first decision differs. Fabric asks you to choose between a lakehouse and a warehouse before the first load. Snowflake asks you to choose a stage and the size of a warehouse.

Loading the file

On Snowflake a file waits in a stage. The loading overview describes internal stages inside Snowflake and external stages over Amazon S3, Google Cloud Storage or Microsoft Azure. COPY INTO loads staged files into an existing table, and the overview says bulk loading relies on a virtual warehouse that you name in the COPY statement. The MATCH_BY_COLUMN_NAME option is supported for CSV, so columns can be matched to the header row by name.

-- Snowflake: match the columns of the file to the table by header name
copy into company_hiring_daily
  from @fokals_landing/company_hiring_daily/2026-10-03/
  file_format = (
    type = csv
    parse_header = true
    field_optionally_enclosed_by = '"'
    error_on_column_count_mismatch = false   -- the file may carry columns the table lacks
  )
  match_by_column_name = case_insensitive;

In Fabric the file waits in the Files area of a lakehouse or in Azure storage. Microsoft's ingestion page says the warehouse's COPY statement reads CSV, JSONL and Parquet from Azure Data Lake Storage Gen2, Azure Blob Storage and OneLake. The COPY INTO reference maps input fields to table columns in order unless you give a column list with field numbers, and FIRSTROW = 2 skips a header row.

-- Fabric warehouse: fields map to columns by position, so create the table in the file's column order
COPY INTO dbo.company_hiring_daily
FROM 'https://onelake.dfs.fabric.microsoft.com/<workspaceId>/<lakehouseId>/Files/fokals/company_hiring_daily/2026-10-03/*.csv'
WITH (
    FILE_TYPE = 'CSV',
    FIRSTROW = 2,
    FIELDQUOTE = '"'
);

The stage, folder and table names are illustrative. A JSON cell contains commas and quotes, so on either platform open a sample file and test one load before you rely on the quote options. Two differences matter once the load runs daily. Snowflake's reference says COPY INTO ignores staged files that were already loaded into the table unless you set FORCE = TRUE. The Fabric reference describes no equivalent, so there you load each dated folder once and test for repeated keys yourself: Microsoft's T-SQL page says a warehouse accepts a primary key only as NOT ENFORCED. And a load into a Fabric lakehouse is not a COPY at all: the decision guide lists Spark, pipelines, dataflows and shortcuts, as the guide to Microsoft Fabric for external company data works through.

JSON in a cell

Fokals files hold lists and objects as JSON in a single cell, and here the two platforms part. Snowflake's semi-structured types are VARIANT, OBJECT and ARRAY. PARSE_JSON turns JSON text into a VARIANT, and FLATTEN turns an object into rows with a KEY and a VALUE.

-- Snowflake: one row per company, day and job function
select h.company_id, h.day, f.key as job_function, f.value::number as open_postings
from company_hiring_daily h,
     lateral flatten(input => parse_json(h.by_function)) f;

A Fabric warehouse has no column type for it. Microsoft's data types page lists json among the types that warehouse tables do not support and gives varchar as the alternative. The COPY INTO reference limits a varchar(max) value loaded from CSV or JSONL to 1 MB. The text is then read with OPENJSON, which returns a key, a value and a type for each property.

-- Fabric warehouse: the same rows in T-SQL
SELECT h.company_id, h.[day], f.[key] AS job_function, CAST(f.[value] AS int) AS open_postings
FROM dbo.company_hiring_daily AS h
CROSS APPLY OPENJSON(h.by_function) AS f;

On both, keep the cell as delivered in the table you load and write the expanded rows to a second table keyed on the company ID, the day and the job function. Daily Fokals rows are written once, after the day closes, and are never revised, so that table only ever gains rows. Both platforms document MERGE for the datasets whose rows do change, such as Job Postings, which is keyed on the posting ID: Snowflake in its MERGE reference, and Microsoft on the T-SQL page, which says MERGE is generally available in the warehouse and that inserts, updates and deletes are not supported on a lakehouse's SQL analytics endpoint.

What each bills for

Neither platform's prices or billing terms are given here: each vendor states them on its own pages. The units are what differ.

Snowflake's cost page says virtual warehouses consume credits when loading data, executing queries and performing other DML operations, and that storage is calculated on the average bytes stored each day.

Microsoft's licensing page describes a capacity as a distinct pool of resources whose size sets the computing power available, measured in capacity units, and explains how F capacities are bought through Azure. A lakehouse or a warehouse can be created only in a workspace that a capacity backs.

For a daily vendor file the consequence is simple. On Snowflake the load runs on a virtual warehouse that consumes credits while it runs. On Fabric it draws on a capacity that is already sized, alongside everything else in the workspaces on it.

Sharing, and running both

Each platform has its own way to receive data without loading it. Snowflake's Secure Data Sharing works between Snowflake accounts: no data is copied and shared objects are read-only. Fabric's external data sharing works between Fabric tenants: the data stays in the provider's OneLake, and the recipient gets a read-only shortcut in a lakehouse. Both matter if your other vendors use data sharing on one of the two.

For a company that runs both platforms, Microsoft documents two bridges, so a vendor file need be loaded only once.

• Mirroring. Fabric's page on mirrored databases from Snowflake says Snowflake tables are replicated continuously into OneLake and exposed through a read-only SQL analytics endpoint. Mirroring has no schedule or replication window, and the page sets out the cost on each side and advises mirroring only the tables you need.
• Iceberg tables. Microsoft's page on Snowflake with Iceberg tables in OneLake describes Snowflake on Azure writing Apache Iceberg tables directly to OneLake, where a shortcut presents them as Delta tables, and reading OneLake's Delta tables as virtual Iceberg tables. The Fabric capacity must be in the same Azure location as the Snowflake account, and Snowflake reaches OneLake over the public network.

Which to choose, by use

• Your other data is already on one of them. Load there. The join to your own tables is the reason to load at all.
• Your reports are in Power BI. Fabric keeps tables in OneLake, where Microsoft says Power BI can read them in Direct Lake mode without a copy.
• You work across clouds. Snowflake runs on public cloud infrastructure and stages files in Amazon S3, Google Cloud Storage or Azure. Fabric runs in a Microsoft Entra tenant and reaches other clouds through shortcuts.
• Your tables are full of JSON. Snowflake stores it in VARIANT, and a Fabric warehouse keeps it as text read with OPENJSON.
• Your team writes T-SQL. Microsoft's decision guide names the Fabric warehouse for it, and Apache Spark for the lakehouse.
• You run both. Load into one and let mirroring or Iceberg tables serve the other.

What the data brings on either platform

Whichever platform you load into, the tables keep the properties of the record. Every row carries the time it was observed, and daily and weekly datasets are written once, after the period closes, and are never revised, so a query as of any past day returns what was known that day. Each row also carries a stable company ID and, for a listed company, its ticker, MIC, ISIN, LEI, FIGI and CIK, so the loaded tables join to your own tables and to a security master on a shared identifier. For the full pipelines see loading company data into Snowflake, and for the neighbouring choices Snowflake vs Databricks and Databricks vs Microsoft Fabric.

Frequently asked questions

The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.

What this page says about the products it names was checked against their public documentation on 4 October 2026. Product and company names are trademarks of their owners. Fokals is not affiliated with them or endorsed by them.