What is a Unified Data Platform?
There is no official category called “Unified Data Platform”. Vendors use their own terms — Data Intelligence Platform, AI Data Cloud, Unified Data & Analytics, Data & AI Platform — and each means something slightly different by it. So this site says plainly what it means by the phrase, and judges platforms against it.
A Unified Data Platform covers most of the data lifecycle from one vendor, over shared storage, governance and identity — so data does not have to be copied, re-permissioned or re-modelled to move between its parts.
Breadth is not unification
The second half of that sentence does the work. A vendor can sell something for every stage of the lifecycle and still make you copy data between the parts, grant permissions twice and maintain two definitions of the same table. That is a broad portfolio, not a unified platform.
So the test has two halves, and both have to hold. The first asks what the platform covers. The second asks whether it is one thing underneath. Passing the first alone is the common case, not the exception.
What it covers
Necessary, but not sufficient. Every assessment links to the vendor’s own documentation, and where a vendor publishes nothing on a point it is recorded as not assessed rather than guessed.
| Coverage | Microsoft Fabric | Databricks | Snowflake | Google Cloud | Amazon Web Services |
|---|---|---|---|---|---|
| Lifecycle coverage | Native Answers integration, data, metadata, visualisation, AI/ML and much of governance with its own components - Data Factory, Lakehouse, Warehouse, Real-Time Intelligence, Power BI and Data Science. | Native Covers integration, data, metadata, quality, AI/ML and governance with its own components; visualisation is the thinnest, with dashboards rather than a full BI tool. | Partial Strong on data, sharing, governance and AI, and adequate on integration; visualisation is limited to Snowsight rather than a full BI tool, and orchestration is thin. | Native Covers the lifecycle end to end with its own components - Dataflow and Datastream for integration, BigQuery and BigLake for storage and analytics, Knowledge Catalog for metadata and governance, Looker for BI, Vertex AI for machine learning. | Native The widest coverage of any vendor assessed. S3 for storage, Glue for integration and cataloguing, Lake Formation for lake governance, Redshift for warehousing, Athena and EMR for query and processing, MSK for streaming, SageMaker for machine learning, QuickSight for BI. |
| Analytical workloadsIs there a managed SQL engine for BI/analytical workloads? | Native | Native | Native | Native BigQuery is a serverless managed SQL engine for analytical workloads, and is the centre the rest of the stack is arranged around. | Native Redshift for managed warehousing and Athena for serverless SQL over S3 - two managed SQL engines rather than one, which is characteristic of the estate. |
| Operational workloadsIs there an operational database integrated with the analytics platform? | Partial SQL database in Fabric; check GA/preview status and other database options. | Partial Lakebase (managed Postgres). Verify GA status. | Partial Hybrid Tables (Unistore); Snowflake Postgres announced. Verify status. | Native Several first-party operational databases - AlloyDB, Spanner and Cloud SQL - and BigQuery reaches them directly. Federated queries send a statement to any of the three through the BigQuery Connection API and return the result as a temporary table, using EXTERNAL_QUERY. | Native A wide operational database range including Aurora, RDS and DynamoDB, and zero-ETL integrations are a fully managed route making transactional and operational data available in Redshift from multiple sources without building a pipeline. |
| Advanced analytics and data scienceAre experiment tracking, model registry and model serving built in? | Partial MLflow-based experiments and models in Fabric Data Science; production model serving is typically done through Azure services. | Native Managed MLflow, Feature Store, Model Serving. | Native Snowflake ML (Feature Store, Model Registry, model serving on Snowpark Container Services). | Native Vertex AI, now documented under Gemini Enterprise Agent Platform, provides experiment tracking, a Model Registry and managed serving endpoints, with notebooks through Colab Enterprise and Workbench. | Native SageMaker covers experiment tracking, a model registry and managed serving endpoints, with notebooks in SageMaker Studio and the newer Unified Studio. |
| Compute beyond SQLIs there managed Spark and a notebook experience? | Native | Native Databricks was founded by the original creators of Apache Spark. | Partial Snowflake Notebooks and Snowpark (DataFrame API) rather than managed Apache Spark; check the status of Spark-compatibility options. | Native Managed Spark on clusters or serverless, plus notebooks through Colab Enterprise and Vertex AI Workbench. Note the rename - Managed Service for Apache Spark now covers what were Dataproc on Compute Engine and Google Cloud Serverless for Apache Spark. | Native Managed Spark through EMR and through Glue, plus notebooks in SageMaker. Again more than one route to the same capability rather than a single managed experience. |
| SQL, Python and RWhich languages can users write workloads in? | Native SQL (T-SQL), Python/PySpark, Scala, R, KQL, DAX. | Native SQL, Python, Scala, R. | Native SQL, Python, Java, Scala (via Snowpark), JavaScript (UDFs/procedures). | Native GoogleSQL in BigQuery, Python through BigQuery DataFrames and notebooks, and Spark on Managed Service for Apache Spark covering Python, Scala, Java and R. SQL, Python and R are all first-class. | Native SQL through Redshift and Athena, and Python, Scala, Java and R through EMR and Glue Spark, with Python and R in SageMaker notebooks. Spread across several services rather than one runtime. |
| VisualisationDoes the platform include its own BI/dashboarding tool? | Native | Native AI/BI Dashboards and Genie. | Partial Snowsight dashboards and Streamlit in Snowflake; not a full BI suite, and usually paired with Tableau, Power BI, etc. | Native Looker for governed enterprise BI on a semantic model, with Looker Studio for lighter self-service. Licensed separately from BigQuery, which is part of why the platform scores only partial on being sold as one thing. | Native QuickSight is a first-party BI service, licensed and metered per user independently of the analytics services it reads from. |
| Baked-in data governanceAre row filters and column masking supported? | Unknown RLS/CLS exist in the warehouse and semantic models; OneLake security scope is evolving. Verify. | Native Row filters and column masks in Unity Catalog. | Native Row access policies and dynamic data masking (Enterprise edition or higher). | Native Row-level security and column-level policy tags in BigQuery, enforced by the engine. Worth checking against your contract rather than your architecture - Google notes row-level security may be unavailable on reservations created with certain BigQuery editions. | Native Lake Formation data filters give row-level and cell-level security on Data Catalog tables, applied to query results across integrated engines, and Redshift carries its own row-level security separately. |
Whether it is unified
These four are what separate a platform from a portfolio. A product can score well above and badly here, and several do — that is the interesting case rather than a contradiction.
| Unification | Microsoft Fabric | Databricks | Snowflake | Google Cloud | Amazon Web Services |
|---|---|---|---|---|---|
| Shared storage | Native OneLake is included automatically in every tenant and is the single store for all analytics data. Microsoft's own wording is "one copy of data to use with multiple analytical engines without duplication", in Delta Parquet or Iceberg. | Native One lakehouse store on the customer's cloud object storage, read by every engine in open formats rather than copied per workload. | Native A single managed storage layer serves every workload, with Iceberg tables extending the same engine to data held outside Snowflake. | Native Apache Iceberg managed tables, formerly BigLake tables for Apache Iceberg in BigQuery, give the same fully managed experience as standard BigQuery tables while storing data in customer-owned buckets, and Google states they let open-source and third-party engines work from a single copy of data. BigLake also reaches Amazon S3 and Azure Blob Storage. Worth knowing that this is a table-type choice rather than the default, since standard BigQuery storage remains its own format. | Partial S3 is the common substrate for the lake and much of the estate reads it in place. Redshift keeps its own managed storage, however, with Spectrum and zero-ETL integrations bridging the two rather than removing the boundary. |
| Shared governance | Native Governance and security are built into OneLake itself rather than applied per engine, so policy follows the data across experiences. | Native Unity Catalog "operates beneath every data and AI interaction" automatically, enforcing access control on a table query or a model call alike, and tracking lineage and audit across both. | Native One policy model across every workload, enforced by the engine itself at query time through masking and row access policies rather than documented and hoped for. Worth knowing when budgeting rather than when comparing architecture - masking, row access policies, classification, quality monitoring and lineage need Enterprise edition or higher. | Native IAM is one identity and permission model across the whole cloud, which is a reach few competitors match since it covers every service rather than one vendor's workspace. Knowledge Catalog carries governance across the estate on top of it. Mechanisms differ by service - BigQuery column and row policies are not object-level IAM on Cloud Storage - but that is true of every platform here, and the model is one. | Partial Lake Formation centrally governs lake data on S3 and its metadata in the Glue Data Catalog, but AWS states plainly that it "provides its own permissions model that augments the IAM permissions model" - so there are two models for lake data, and Redshift maintains its own grants alongside. Not one policy model across every workload. |
| Shared metadata and identity | Native One tenant-wide lake with a single catalogue across every workload; items are tenant objects rather than per-service resources. | Native Unity Catalog is one catalogue across data and AI assets, enabled automatically for workspaces created after 8 November 2023; older workspaces need an upgrade. | Native One account-wide catalogue across workloads, reaching beyond Snowflake only through Snowflake-mediated paths such as Iceberg tables, the Iceberg REST catalog API and catalog-linked databases. | Partial Knowledge Catalog provides universal business context across the estate through a context graph, and was renamed from Dataplex Universal Catalog on 10 April 2026 with API, CLI and IAM names unchanged. It sits over more than one technical catalogue rather than replacing them, though - BigQuery holds its own metadata, and Dataproc Metastore is a separate fully managed Hive metastore for lake and Hive workloads. One context layer, several catalogues underneath. | Partial The Glue Data Catalog is the catalogue for lake data, while Redshift carries its own. SageMaker Unified Studio brings these together, but AWS describes it as "a unified development experience that brings together AWS data, analytics, AI and ML services" - a single interface over separate services rather than a single catalogue beneath them. |
| Sold as one platform | Native Bought as Fabric capacity, with the experiences drawing on the same capacity rather than being licensed separately. | Native One platform billed in DBUs across workloads rather than as separately licensed products. | Native One platform billed in credits, though which features are available at all depends on the edition purchased. | Partial One account and one bill, but the components are separately metered products and Looker is licensed separately again. Closer to a well-integrated portfolio than a single platform purchase. | None Bought as separately licensed and independently metered services, not as one platform. One account and one bill is not the same thing - each service has its own pricing dimension, and removing one does not change how the others are charged. |
The two halves pull against each other
Read the tables together and a trade-off appears that neither shows alone. The platforms with the widest coverage score worst on unification, and the ones that are genuinely unified have gaps in what they cover.
AWS is the clearest case. It answers every coverage row natively — warehouse, operational database, data science, Spark and notebooks, all three languages, its own BI tool and row-level security — and then scores partial or worse on all four unification rows. Google Cloud matches it on coverage and lands in the middle on unification: one storage layer and one permission model, but several technical catalogues underneath and components bought separately.
Fabric, Databricks and Snowflake run the other way. All three are unified on every row, and all three have gaps in what they cover — operational workloads for all three, data science for Fabric, and compute and visualisation for Snowflake.
That is not a coincidence, and it is the most useful thing on this page. Breadth tends to come from assembling many services, and assembling many services is exactly what makes a single storage layer, one policy model and one catalogue hard to sustain. Choosing a platform usually means choosing which half of that trade-off you would rather live with.
What this is not
These are not scores out of nine, and the tables are not a ranking. A platform that answers fewer rows is not worse — it is differently shaped, and often deliberately so. An open, federation-first platform that deliberately does not own your storage will never score “native” on shared storage, and that is the point of it rather than a failing.
Nor does ticking every plane make something a Unified Data Platform on its own. That is coverage, which is one half of the test. What the criteria do is make the word mean something: when a vendor calls itself unified, you can check which of these it actually does, and read the source for yourself.
Where to go next
- Compare platforms across the full matrix, not just these rows.
- Browse the tooling landscape if you are assembling a stack from components rather than buying one platform.