Scored matrix · Formats + Catalogs (C1 + C2)
Four pairs. Ten criteria. Three archetypes.
Components 1 (table format) and 2 (catalog) score together because the choice is structurally coupled: Unity ties to Delta; Polaris is Iceberg-first; Glue is AWS-bound; Nessie is Iceberg-native. Scoring them independently produces operationally undeployable pairs ("Unity 5/5 + Hudi 4/5"). The four paired candidates here are the ones a v1 engagement realistically picks between; Hudi+Glue, Gravitino as a meta-catalog, and Iceberg-via-Unity-UniForm are deferred to v1.1.
This is the heaviest component in the v1.3 evidence cut. A-05 (Unity OSS self-hosted immaturity) moved from open to confirmed on 2026-05-25, backed by two first-party sources (deployment maturity and Iceberg-REST functional incompleteness). MDR-0025 (Nessie/Polaris metadata-fetch parity) was added from a 2026-05-25 toy-scale measurement that removes catalog-driver overhead as a Nessie-vs-Polaris differentiator on the read path. A-04 and A-06 picked up first-party citations in the same cut.
I treat the scoring tables as the deliverable. The narrative around each table is what makes the tables operable: the ranking call, the decision shape, the fragility analysis, the cross-component coupling. The numbers come from the YAML scoring files in the source-of-truth project repository; this page renders them with the evidence tiers and short citations attached.
Methodology preamble
Same ten criteria, three weight vectors. Score shifts where the archetype reframes relevance.
The ten criteria are fixed across archetypes (per MDR-0008, which sets the criterion set). The weights change per archetype because the archetypes have different goals: A maximizes lock-in resistance, B maximizes managed simplicity, C maximizes AWS-native integration depth. Weight vectors are documented in MDR-0009 (A), MDR-0018 (B), and MDR-0020 (C). All three sum to 100.
A smaller number of scores also shift across archetypes when the criterion's meaning reframes. For example, multi_engine_query_support at Archetype A measures cross-cloud breadth; at Archetype C it measures within-AWS depth. Iceberg+Glue lifts from 3 (A) to 4 (B) to 5 (C) on this criterion not because the underlying engine integration changed, but because the relevant universe of engines did. This is documented in MDR-0004 (archetype-conditional weights) and called out explicitly per-cell in the YAML.
Every score carries an evidence tier per MDR-0003. Tier A is peer-reviewed research, an official standard (NIST, ISO, the OCSF spec body), or a production deployment at recognized scale, with Netflix, Pinterest, and AWS Security Lake as the canonical examples. Tier B is credible practitioner reporting, conference talks, multi-source synthesis, and first-party measurements at small scale. Tier C is vendor blog or marketing material, cited only with an explicit bias flag, and Tier D is speculation, which can never stand as the sole citation on a non-null score. The tier grades the backing, not the capability, so it is independent of the 1–5 score: a 5 backed by Tier C is less defensible than a 3 backed by Tier A. All four pairs reach 1.0 evidence completeness at all three archetypes under MDR-0013's separate completeness threshold; no client-specific null criterion exists at the formats+catalogs level (unlike Engines, where in-house skill is intentionally null until the engagement runs).
Disclosure: one candidate carries a filled block. Delta+Unity is flagged nature: explore for an in-progress Databricks conversation (a warm intro regarding Lakewatch go-to-market), with no commercial relationship in place and no score-altering effect; per MDR-0016 (disclosure discipline) the block is mandatory structure on every scored candidate, so the other three carry it as null.
Why C1 and C2 score bundled rather than independently: the four production-credible candidate pairs are not arbitrary combinations of (Iceberg, Delta, Hudi) × (Polaris, Nessie, Unity, Glue, Hive). Unity is Delta-first (UniForm bridges it to Iceberg-read only); Polaris is Iceberg-first and effectively requires Iceberg V2+ on the writer side; Nessie is Iceberg-native; Glue works with Iceberg in AWS but is tied to AWS IAM. If I scored format and catalog independently I would inevitably produce operationally undeployable rankings like "Unity 5/5 paired with Hudi 4/5", a configuration nobody runs in production. MDR-0008 makes the bundled framing explicit so the scoring rows correspond to real engagement choices, not Cartesian-product artifacts.
Why exactly four pairs in v1: Iceberg+Polaris, Iceberg+Nessie, Delta+Unity, Iceberg+Glue are the candidates with credible Tier-A or Tier-B production references in the security-data space. The pairs the matrix marks deferred, with the reason and the target cut for each:
| Deferred pair | Why deferred | Defer target |
|---|---|---|
| Hudi + Glue | Carries no security-specific production reference I can cite at Tier-A or Tier-B, so it sits at Tier-C unable-to-evaluate | Deferred to v1.1 pending a structured review |
| Iceberg+Gravitino (meta-catalog) | Needs a different scoring shape (Gravitino sits over multiple catalogs rather than alongside them) | Deferred |
| Iceberg+Hive Metastore | A migration-from baseline relevant to specific engagements | Deferred |
| Iceberg+Unity via UniForm bridge | A specialized case where Unity governs Delta tables exposed to Iceberg readers | Deferred to v1.1 pending a real production use case |
Archetype A
Archetype A: Multi-engine open lakehouse.
Engine portability is the explicit goal. Lock-in resistance dominates the weight distribution. The customer is willing to absorb operational complexity in exchange for the option to swap engines, catalogs, or clouds without rewriting the data layer.
Weights — Archetype A
| Criterion | Weight | What it measures |
|---|---|---|
| Multi-engine query support | 20 | Can the format + catalog combo be read/written by a credible breadth of engines (Spark, Trino, Athena, ClickHouse, DuckDB)? |
| Multi-engine federation | 15 | Federation across catalogs and clouds via a standard interface, which is what makes multi-engine real at scale. |
| Open governance | 10 | Apache vs vendor-controlled stewardship. Shapes the 12-month roadmap incentive structure. |
| Catalog ecosystem maturity | 10 | Today's deployed surface of production references and tooling depth rather than the marketing pitch. |
| RBAC + column-level security | 15 | Catalog-enforced row filters, column masking, and identity integration. The multi-tenant production gate. |
| Schema evolution + time travel (format) | 5 | Format-level partition evolution, schema add/drop/rename without rewrite, snapshot-based history. |
| Time travel + branching (catalog) | 5 | Catalog-level branches, tags, and atomic multi-table commits; Nessie's differentiator. |
| Cloud-native vs self-hosted | 5 | Whether the catalog ships as a credible managed service, a credible self-hostable artifact, or both. |
| Cost model (OSS vs licensed) | 5 | Per-seat / per-query / managed markup vs Apache-2.0 OSS base. TCO and license-escalation hedge. |
| Cloud + on-prem flexibility | 10 | Multi-cloud and air-gapped deployment. Penalty for AWS-only or single-vendor-managed designs under open-lakehouse framing. |
| Total | 100 | Must sum to 100. |
Scored matrix — Archetype A
Score on a 1–5 scale per MDR-0002, rendered in the red→green gradient. Score value in large white mono; below it the evidence-tier flag (A or B) plus a short citation keyword. Weighted total at the bottom of each column. The four paired candidates × ten criteria are the published scored record for this archetype; a paid engagement starts from these numbers and re-scores the client-specific criteria against a real environment.
| Criterion | Weight | Iceberg + Polaris | Iceberg + Nessie | Delta + Unity | Iceberg + Glue |
|---|---|---|---|---|---|
Multi-engine query support | 20 | 5 Tier A · Netflix 5 PB/day ·… | 3 Tier B · Nessie native; ClickHouse /… | 3 Tier A · UniForm = read-only bridge;… | 3 Tier A · Athena/EMR/Redshift integrated; non-AWS pays… |
Multi-engine federation | 15 | 5 Tier A · Pinterest 17k+ nodes ·… | 2 Tier B · Specialized to Spark/Trino, not… | 3 Tier B · Unity REST; premium features… | 2 Tier B · AWS-only; no cross-cloud federation |
Open governance | 10 | 4 Tier A · Polaris ASF-donated 2024; table-level… | 4 Tier B · Apache 2.0; vendor-originated | 3 Tier A · Open-source but Databricks-roadmap-controlled | 2 Tier A · Iceberg open; Glue catalog… |
Catalog ecosystem maturity | 10 | 3 Tier B · Polaris GA late 2024;… | 2 Tier B · Netflix/Apple/LinkedIn; thin in average… | 4 Tier A · Mature for Databricks customers;… | 4 Tier A · AWS Security Lake GA… |
RBAC + column-level security | 15 | 3 Tier B · Table+namespace RBAC; row/column =… | 2 Tier B · Branch-level only; no row/column… | 5 Tier A · Strongest on Databricks-hosted; OSS… | 4 Tier A · Lake Formation RLS +… |
Schema evolution + time travel (format) | 5 | 4 Tier A · Iceberg V3 metadata-only schema… | 4 Tier B · Iceberg V3 features (engine-side… | 4 Tier A · Delta schema evolution mature;… | 3 Tier A · Iceberg-native; Glue is transport |
Time travel + branching (catalog) | 5 | 3 Tier B · Snapshot-based; no Git-style branching | 5 Tier B · Git branches + tags… | 3 Tier B · Time travel; no Git-style… | 2 Tier B · Snapshot-only; no branching |
Cloud-native vs self-hosted | 5 | 5 Tier A · Self-hostable + Snowflake-managed +… | 4 Tier B · Self-hostable; managed cloud option… | 2 Tier A · OSS self-host pre-1.0 +… | 3 Tier A · AWS-managed only; no self-host… |
Cost model (OSS vs licensed) | 5 | 5 Tier A · Apache 2.0 both layers;… | 5 Tier B · Apache 2.0; no proprietary… | 3 Tier B · OSS base free; security… | 2 Tier B · A-12 modeled 20-40% delta |
Cloud + on-prem flexibility | 10 | 5 Tier A · AWS/Azure/GCP/on-prem; storage-swappable | 4 Tier B · Any Kubernetes; multi-cloud capable | 2 Tier B · Databricks Workspace on AWS/Azure/GCP;… | 1 Tier A · AWS-only by design; decisive… |
| Weighted total | 100 | 4.25 rank #1 | 3.10 rank #3 | 3.30 rank #2 | 2.70 rank #4 |
Ranking + winner call — Archetype A
Winner: Iceberg + Polaris at 4.25. Multi-engine query support (5), federation (5), cost model (5), and cloud/on-prem flexibility (5) all dominate under Archetype A's weight distribution. The pair is the Snowflake-incubated, Apache-stewarded answer to the multi-engine open lakehouse. Netflix validates Iceberg at 5 PB/day; the Iceberg REST interface Polaris implements is designed for 15+ engines; and Pinterest demonstrates REST-catalog federation at 17k+ node scale with credential vending, running Apache Gravitino over the same Iceberg REST spec. The catalog ecosystem maturity score (3) reflects Polaris's youth (GA late 2024 vs Hive Metastore/Glue's decade), and the RBAC score (3) reflects table-level-only governance with row/column masking delegated to the engine layer. Both are the deliberate trade-offs for portability rather than defects to fix.
Runners: Delta+Unity at 3.30, Iceberg+Nessie at 3.10, Iceberg+Glue at 2.70. Delta+Unity scores honestly here: RBAC (5) is the strongest in the field, but cloud/on-prem flexibility (2) and multi-engine portability (3) drag against Archetype A's weights. This is honest Archetype-B territory mislabeled as A. Nessie's branching (5) is the differentiator, but engine breadth (3) and RBAC (2) hurt under the 20+15-weighted criteria. Glue at 2.70 is Archetype-C excellence mislabeled as A; under Archetype C weights, the same scores would produce 4.20.
Decision shape — when Polaris loses
Three defensible exceptions where the call moves off Iceberg+Polaris under Archetype A framing:
- Iceberg+Nessie when the team treats detection logic as code: branches for testing rules, tags for compliance snapshots, atomic multi-table rollback for bad deployments. Nessie's branching (5) and OCSF-pipeline consistency (cross-table atomic commits) are the differentiators. Cost is engine-breadth narrowing (ClickHouse / Snowflake unvalidated) and RBAC weakness (engine-layer governance required).
- Iceberg+Glue when the engagement is AWS-only and lock-in resistance is not actually the design goal (despite Archetype A's stated weights). This is honest Archetype-C territory, not A. The 2.70 score reflects the mislabeling, not a defect of Glue.
- Delta+Unity when the engagement is Databricks-led. This is honest Archetype-B territory. Unity's catalog-enforced RBAC (5) is the strongest in the field; the cost is Databricks platform coupling.
Where the ranking is fragile — Archetype A
The Q3 2026 catalog comparison benchmark is the gating Tier-A evidence event for this ranking. Three specific places where the ranking could move:
- Polaris catalog ecosystem maturity (3). Pegged to "production references thin outside Pinterest." If Netflix, Insider, or another Tier-A reference publishes a Polaris production case by Q3, this climbs to 4 and the Polaris weighted total moves to 4.35, widening the gap to Delta+Unity from 0.95 to 1.05.
- Unity Catalog self-hosted maturity. Currently 2 (confirmed by A-05 in the v1.3 cut, see below). If Databricks lands operational tooling and named external case studies for self-hosted Unity, this moves to 3-4, and because the criterion carries weight 5 under Archetype A the move is small: +0.05 to +0.10 on the weighted total, taking Delta+Unity from 3.30 to 3.35-3.40. That widens its existing #2 margin over Nessie (3.10) rather than changing any rank, because the 0.85-and-up gap to Polaris (4.25) sits in multi-engine and flexibility criteria this score does not touch.
- Iceberg V3/V4 currency. Schema_evolution_time_travel_format is currently 4 uniform across Iceberg pairs (V3 features rolling out). If V4 lands inside the revalidation window with additional gaps, this score becomes decisive rather than uniform.
Disclosure · Archetype A
Delta + Unity carries a nature: explore disclosure: an in-progress Databricks conversation regarding Lakewatch go-to-market, with no commercial relationship in place. Per MDR-0016 (disclosure discipline) the block is mandatory structure on every scored candidate, and the flag is transparency; it does not alter the score itself.
Archetype B
Archetype B: Single-vendor managed lakehouse.
Already on Databricks (or similar). Optimize for operational simplicity within the vendor's ecosystem; accept some portability tradeoff for managed simplicity. RBAC and cloud-native simplicity carry the heaviest weights; multi-engine portability gets downweighted.
Weights — Archetype B
| Criterion | Weight | What it measures |
|---|---|---|
| Multi-engine query support | 10 | Can the format + catalog combo be read/written by a credible breadth of engines (Spark, Trino, Athena, ClickHouse, DuckDB)? |
| Multi-engine federation | 5 | Federation across catalogs and clouds via a standard interface, which is what makes multi-engine real at scale. |
| Open governance | 5 | Apache vs vendor-controlled stewardship. Shapes the 12-month roadmap incentive structure. |
| Catalog ecosystem maturity | 10 | Today's deployed surface of production references and tooling depth rather than the marketing pitch. |
| RBAC + column-level security | 25 | Catalog-enforced row filters, column masking, and identity integration. The multi-tenant production gate. |
| Schema evolution + time travel (format) | 5 | Format-level partition evolution, schema add/drop/rename without rewrite, snapshot-based history. |
| Time travel + branching (catalog) | 5 | Catalog-level branches, tags, and atomic multi-table commits; Nessie's differentiator. |
| Cloud-native vs self-hosted | 15 | Whether the catalog ships as a credible managed service, a credible self-hostable artifact, or both. |
| Cost model (OSS vs licensed) | 10 | Per-seat / per-query / managed markup vs Apache-2.0 OSS base. TCO and license-escalation hedge. |
| Cloud + on-prem flexibility | 10 | Multi-cloud and air-gapped deployment. Penalty for AWS-only or single-vendor-managed designs under open-lakehouse framing. |
| Total | 100 | Must sum to 100. |
Scored matrix — Archetype B
Score on a 1–5 scale per MDR-0002, rendered in the red→green gradient. Score value in large white mono; below it the evidence-tier flag (A or B) plus a short citation keyword. Weighted total at the bottom of each column. The four paired candidates × ten criteria are the published scored record for this archetype; a paid engagement starts from these numbers and re-scores the client-specific criteria against a real environment.
| Criterion | Weight | Iceberg + Polaris | Iceberg + Nessie | Delta + Unity | Iceberg + Glue |
|---|---|---|---|---|---|
Multi-engine query support | 10 | 5 Tier A · Netflix-validated 15+ engines (downweighted) | 3 Tier B · Nessie native; AWS-managed engines… | 3 Tier A · UniForm bridge; Spark-centric writes | 4 Tier A · Within-AWS parity; lifts from… |
Multi-engine federation | 5 | 5 Tier A · Pinterest 17k nodes; bonus… | 2 Tier B · Spark/Trino; not generic | 3 Tier B · Within-Databricks federation suffices for… | 3 Tier B · Cross-region via IAM +… |
Open governance | 5 | 4 Tier A · Polaris ASF 2024; hedge… | 4 Tier B · Apache 2.0; vendor-originated | 3 Tier A · Databricks-controlled (expected under B) | 2 Tier A · Glue AWS-proprietary (acceptable under… |
Catalog ecosystem maturity | 10 | 3 Tier B · GA late 2024; outside… | 2 Tier B · Limited security-specific case studies | 4 Tier A · Production at Databricks scale | 4 Tier A · AWS Security Lake 3+… |
RBAC + column-level security | 25 | 3 Tier B · Table-level; engine-layer governance work | 2 Tier B · Branch-level; 25-weight amplifies this… | 5 Tier A · Catalog-enforced row + column… | 4 Tier A · Lake Formation RLS +… |
Schema evolution + time travel (format) | 5 | 4 Tier A · Iceberg V3 metadata-only | 4 Tier B · Iceberg V3 features | 4 Tier A · Delta schema evolution mature | 3 Tier A · Iceberg-native; Glue is transport |
Time travel + branching (catalog) | 5 | 3 Tier B · Snapshot-based; no Git branching | 5 Tier B · Git branches + multi-table… | 3 Tier B · Time travel; no Git… | 2 Tier B · Snapshot only |
Cloud-native vs self-hosted | 15 | 5 Tier A · Snowflake-managed OR self-host OSS | 4 Tier B · Self-host OR managed cloud… | 5 Tier A · Databricks-managed is the shipped… | 5 Tier A · AWS-managed serverless; lifts from… |
Cost model (OSS vs licensed) | 10 | 5 Tier A · Apache 2.0 base; hedge… | 5 Tier B · Apache 2.0; no proprietary… | 4 Tier B · Marginal cost favorable for… | 3 Tier B · A-12 modeled 20-40% delta |
Cloud + on-prem flexibility | 10 | 5 Tier A · Cloud-agnostic; storage-swappable | 4 Tier B · Any Kubernetes; multi-cloud | 2 Tier B · Databricks workspace required; cloud-only | 1 Tier A · AWS-only (accepted under B) |
| Weighted total | 100 | 4.10 rank #1 | 3.25 rank #4 | 3.95 rank #2 | 3.45 rank #3 |
Ranking + winner call — Archetype B
Iceberg+Polaris leads at 4.10, with Delta+Unity close behind at 3.95. The most interesting result in any v1 matrix run is how close they land: two candidates with very different architectural premises arrive within 0.15 of each other under Archetype B's "single-vendor managed" framing. Polaris scores 5 on five criteria (multi-engine, federation, cloud-native, cost, on-prem, plus open governance at 4); even when most are downweighted, the cumulative breadth produces 410 points. Delta+Unity scores 5 on two heavily-weighted criteria (RBAC at 25, cloud-native at 15) and 4 elsewhere; the concentration on what B prioritizes produces 395 points, so the 15-point margin turns on breadth against concentration, and breadth is what holds the top spot here.
This is methodology validation, not a defect: "Archetype B is Delta+Unity's home" is true in a directional sense (Delta+Unity lifts +0.65 from A's 3.30 to B's 3.95) but not by enough to overtake Polaris's breadth, which keeps the top spot. The customer call becomes "do you want broad strength or RBAC-and-managed-cloud concentration?", and the 0.15 gap is thin enough that the org's existing vendor usually decides it.
Runners: Iceberg+Glue at 3.45, Iceberg+Nessie at 3.25. Glue lifts +0.75 from A; the cloud-native score adjustment (3→5) and within-AWS multi-engine framing (3→4) move it substantially, and a Lake Formation RBAC of 4 (25 pts short of Delta+Unity's catalog-enforced 5) keeps it out of contention but ahead of Nessie. Nessie lifts only +0.15 from A; the RBAC weight at 25 amplifies its score-2 weakness on row/column masking (50 pts vs Delta+Unity's 125), which drops it to the bottom of the B field.
Decision shape — which managed vendor
For Archetype B as posed, the call depends on what "single vendor" already is:
- Customer is on Databricks → Delta+Unity. Unity's catalog-enforced RBAC is the Archetype-B benchmark.
- Customer is on Snowflake → Iceberg+Polaris (Snowflake-managed). Same 4.10 score (the B leader), different vendor. The Snowflake-managed Polaris path solves cloud-native simplicity but inherits Polaris's table-level RBAC (engine-layer governance work).
- Customer is AWS-committed → Iceberg+Glue at 3.45. A mid-field runner under B (ahead of Nessie) whose real home is Archetype C, but viable for AWS-committed teams who want the single-managed-vendor pattern.
- Customer wants branching workflow over managed simplicity → Iceberg+Nessie. 3.25 is honest middle; the better archetype framing is A (engineering shop with detection-as-code).
Where the ranking is fragile — Archetype B
- The 4.10-vs-3.95 top two. The 0.15 gap between Polaris and Delta+Unity is the thinnest at this archetype. Raising the RBAC weight (25→30) shifts points toward Delta+Unity's catalog-enforced 5 and would close or flip it; raising multi_engine_query_support (10→15) widens Polaris's breadth lead. The 25/10 split is defensible but it is what orders the top two.
- Polaris's Snowflake-managed RBAC. Currently 3 (table-level + engine-layer delegation). If Snowflake ships catalog-enforced row/column policy above Polaris REST, this lifts to 4 and the weighted total moves to ~4.35, decisively beating Delta+Unity.
- Delta+Unity's multi-engine query support (3). If UniForm matures to true bidirectional read+write parity (not just Iceberg-read of Delta), this lifts to 4-5 and Delta+Unity reaches ~4.15.
Disclosure · Archetype B
Delta + Unity carries a nature: explore disclosure: an in-progress Databricks conversation regarding Lakewatch go-to-market, with no commercial relationship in place. Per MDR-0016 (disclosure discipline) the block is mandatory structure on every scored candidate, and the flag is transparency; it does not alter the score itself.
Archetype C
Archetype C: AWS-native lake.
Already heavily on AWS. Accept Glue lock-in for the integration depth (IAM + Lake Formation + Athena + EMR + Lambda + Glue ETL). The cloud_native_vs_self_hosted weight rises to 20, reflecting that AWS-managed-serverless is the design center; cloud_on_prem_flexibility drops to 5 because the AWS-only constraint is the explicit premise.
Weights — Archetype C
| Criterion | Weight | What it measures |
|---|---|---|
| Multi-engine query support | 10 | Can the format + catalog combo be read/written by a credible breadth of engines (Spark, Trino, Athena, ClickHouse, DuckDB)? |
| Multi-engine federation | 5 | Federation across catalogs and clouds via a standard interface, which is what makes multi-engine real at scale. |
| Open governance | 5 | Apache vs vendor-controlled stewardship. Shapes the 12-month roadmap incentive structure. |
| Catalog ecosystem maturity | 15 | Today's deployed surface of production references and tooling depth rather than the marketing pitch. |
| RBAC + column-level security | 20 | Catalog-enforced row filters, column masking, and identity integration. The multi-tenant production gate. |
| Schema evolution + time travel (format) | 5 | Format-level partition evolution, schema add/drop/rename without rewrite, snapshot-based history. |
| Time travel + branching (catalog) | 5 | Catalog-level branches, tags, and atomic multi-table commits; Nessie's differentiator. |
| Cloud-native vs self-hosted | 20 | Whether the catalog ships as a credible managed service, a credible self-hostable artifact, or both. |
| Cost model (OSS vs licensed) | 10 | Per-seat / per-query / managed markup vs Apache-2.0 OSS base. TCO and license-escalation hedge. |
| Cloud + on-prem flexibility | 5 | Multi-cloud and air-gapped deployment. Penalty for AWS-only or single-vendor-managed designs under open-lakehouse framing. |
| Total | 100 | Must sum to 100. |
Scored matrix — Archetype C
Score on a 1–5 scale per MDR-0002, rendered in the red→green gradient. Score value in large white mono; below it the evidence-tier flag (A or B) plus a short citation keyword. Weighted total at the bottom of each column. The four paired candidates × ten criteria are the published scored record for this archetype; a paid engagement starts from these numbers and re-scores the client-specific criteria against a real environment.
| Criterion | Weight | Iceberg + Polaris | Iceberg + Nessie | Delta + Unity | Iceberg + Glue |
|---|---|---|---|---|---|
Multi-engine query support | 10 | 5 Tier A · Netflix-validated 15+ engines; Glue-parity | 3 Tier B · Athena/Redshift not native to… | 3 Tier A · UniForm bridge; Athena/Lambda integration… | 5 Tier A · Athena+EMR+Redshift+Glue ETL+DuckDB-on-Lambda all native |
Multi-engine federation | 5 | 5 Tier A · Pinterest 17k+ nodes; bonus… | 2 Tier B · Specialized; no generic AWS… | 3 Tier B · Within-Databricks primarily | 3 Tier B · AWS regions/accounts via IAM… |
Open governance | 5 | 4 Tier A · Polaris ASF 2024; lock-in… | 4 Tier B · Apache 2.0 (downweighted under… | 3 Tier A · Databricks-controlled | 2 Tier A · Glue proprietary (accepted under… |
Catalog ecosystem maturity | 15 | 3 Tier B · AWS-specific depth lags Glue | 2 Tier B · No Lake Formation hooks;… | 3 Tier A · AWS-ecosystem depth integrates with… | 5 Tier A · Deepest AWS catalog ecosystem;… |
RBAC + column-level security | 20 | 3 Tier B · Table-level vs Lake Formation… | 2 Tier B · Branch-level; no native IAM… | 5 Tier A · World-class; IAM-integration story weaker… | 5 Tier A · Lake Formation + IAM… |
Schema evolution + time travel (format) | 5 | 4 Tier A · Iceberg V3 metadata-only | 4 Tier B · Iceberg V3 features | 4 Tier A · Delta schema evolution mature | 3 Tier A · Iceberg-native; Glue is transport |
Time travel + branching (catalog) | 5 | 3 Tier B · Snapshot-based | 5 Tier B · Git branches (bonus under… | 3 Tier B · Time travel; no branching | 2 Tier B · Snapshot only |
Cloud-native vs self-hosted | 20 | 4 Tier B · Self-host on AWS adds… | 3 Tier B · Nessie-on-EKS adds burden vs… | 4 Tier A · Databricks-managed ≠ AWS-managed under… | 5 Tier A · AWS-managed serverless is the… |
Cost model (OSS vs licensed) | 10 | 5 Tier A · Apache 2.0; Snowflake-managed adds… | 5 Tier B · Apache 2.0 | 3 Tier B · Databricks Premium adds vendor… | 4 Tier A · Pay-per-use is expected economics… |
Cloud + on-prem flexibility | 5 | 5 Tier A · Cloud-agnostic (downweighted under C) | 4 Tier B · Any K8s; multi-cloud (downweighted… | 2 Tier B · Databricks workspace required | 1 Tier A · AWS-only (downweighted under C) |
| Weighted total | 100 | 3.90 rank #2 | 3.05 rank #4 | 3.60 rank #3 | 4.20 rank #1 |
Ranking + winner call — Archetype C
Winner: Iceberg+Glue at 4.20. Home archetype confirmed. Iceberg+Glue lifts from Archetype A's 2.70 to C's 4.20, a +1.50 archetype-shift, the largest single-candidate shift in v1. The matrix is doing what it should: showing that under framing where AWS lock-in is accepted upfront and AWS-managed-serverless is the design center, Glue is the strongest fit rather than a compromise. Four score lifts from the B column to C's (not just weight shifts) drive the result: multi_engine 4→5, catalog ecosystem 4→5, RBAC 4→5, and cost 3→4. Per MDR-0004, scores can shift when the archetype reframes the criterion's relevance, so the goalposts have not moved; the same criterion set is applied with archetype-appropriate anchoring.
Runners: Iceberg+Polaris at 3.90, Delta+Unity at 3.60, Iceberg+Nessie at 3.05. Polaris holds up as the strong runner: broad strengths (multi-engine 5, federation 5, cost 5, on-prem 5, open governance 4) survive downweighting, but the structural RBAC gap and the not-AWS-native cloud-native gap keep it 0.30 behind Glue. Delta+Unity drops to 3.60 because "Databricks-on-AWS" is Databricks-managed, not AWS-native; catalog ecosystem drops 4→3, cloud-native drops 5→4, cost drops 4→3 under C's framing. Nessie at 3.05 is the matrix saying "Archetype C is the wrong question for this candidate; re-pose as A."
Decision shape — when Glue loses
- AWS teams considering hedge against future multi-cloud → Iceberg+Polaris. Stays competitive at 3.90, but the hedge contradicts Archetype C's "accept Glue lock-in" premise. If you're hedging, you're actually Archetype A, not C. Re-pose.
- AWS teams already running Databricks → Delta+Unity at 3.60. Defensible but the proper archetype is B (single-vendor managed), not C.
- AWS teams wanting detection-as-code branching → Iceberg+Nessie at 3.05. Wrong fit at C. Re-pose as Archetype A (engineering shop with branching workflow). Nessie at 3.05 here is the matrix telling the customer they're posing the wrong question.
Where the ranking is fragile — Archetype C
- Glue's cost score (4). Driven by A-12 (AWS Security Lake hidden-cost delta), which is a modeled Tier-B assumption built from published AWS pricing plus practitioner data points rather than a measured delta, which is why the 20-40% cost cells at Archetypes A and B carry Tier B, not Tier A. If empirically measured at <10% (rather than the assumed 20-40%), this lifts to 5 and Glue moves to ~4.30. If >50% with no offsetting AWS credits, drops to 3 and Glue moves to ~4.10. Either way Glue stays #1 at C.
- Polaris's catalog ecosystem maturity (3) within AWS. If AWS publishes a native Polaris-REST adapter for Athena (analogous to Glue catalog adapter), Polaris lifts to 4 and weighted total to ~4.05, narrowing the gap from 0.30 to 0.15. Watch AWS re:Invent 2026 catalog announcements.
- Delta+Unity's cloud-native (4). If Databricks releases an AWS-IAM-integrated identity bridge that ties Unity policies into Lake Formation, this lifts to 5 and weighted total to ~3.80. Still behind Polaris at C; the IAM-integration gap is the binding constraint.
- Fundamental fragility. Archetype C is the most AWS-centric archetype, which means the recommendation is highly correlated with AWS's product roadmap. If AWS deprecates or repositions Glue (low probability but non-zero), the #1 changes overnight. Hedge: track AWS Storage/Analytics product announcements quarterly.
Disclosure · Archetype C
Delta + Unity carries a nature: explore disclosure: an in-progress Databricks conversation regarding Lakewatch go-to-market, with no commercial relationship in place. Per MDR-0016 (disclosure discipline) the block is mandatory structure on every scored candidate, and the flag is transparency; it does not alter the score itself.
Cross-archetype synthesis
Every candidate has a home archetype. The matrix names it without engineering for the result.
The cleanest pattern across v1.3 (the one I would not have predicted from the criterion set alone) is that each of the four pairs has exactly one archetype where it dominates and two where it does not. Glue lifts +1.50 from A to C; Delta+Unity lifts +0.65 from A to B; Polaris monotonically declines from A through C without dropping out of the top three; Nessie sits in the 3.0–3.3 band across all three archetypes without ever winning, because its differentiator (branching for detection-as-code) is only relevant for an engineering-shop subset of Archetype A that the standing weight vector does not single out.
| Candidate pair | A (multi-engine) | B (managed) | C (AWS-native) | A→C shift | Home archetype |
|---|---|---|---|---|---|
| Iceberg + Polaris | 4.25 | 4.10 | 3.90 | −0.35 | A — multi-engine open lakehouse |
| Delta + Unity | 3.30 | 3.95 | 3.60 | +0.30 | B — single-vendor managed |
| Iceberg + Nessie | 3.10 | 3.25 | 3.05 | −0.05 | A subset — engineering shop with branching workflow |
| Iceberg + Glue | 2.70 | 3.45 | 4.20 | +1.50 | C — AWS-native lake |
The +1.50 Glue shift: methodology validation, not goalpost-moving
Iceberg+Glue lifting from A's 2.70 to C's 4.20 is the largest single-candidate archetype-shift in v1.x. Four explicit score lifts (per MDR-0004 archetype-conditional weight rule) drive most of the delta on top of the weight redistribution. Multi-engine query support goes 3 → 4 → 5: at A it measures cross-cloud breadth (Glue cannot federate to Azure/GCP without egress); at B it measures within-vendor breadth (Glue inside AWS works); at C it measures within-AWS depth (Glue with Athena + EMR + Redshift + Lambda + Glue ETLis the relevant universe). Catalog ecosystem maturity goes 4 → 4 → 5: under C the relevant ecosystem is AWS-native, where Glue dominates. RBAC goes 4 → 4 → 5: under C, Lake Formation + IAM is the gold standard rather than a runner-up to Unity's federated-identity model. Cost goes 2 → 3 → 4: under C, AWS pay-per-use is the expected economics, so transparency becomes the relevant measure rather than OSS-vs-licensed. Each shift carries a criterion-level caveat in the YAML; the same taxonomy is applied with archetype-appropriate anchoring.
Polaris's narrow lead at Archetype B, 4.10 against 3.95: a finding, not a flaw
Iceberg+Polaris (4.10) leads Delta+Unity (3.95) by 0.15 under Archetype B's weight vector, which is the thinnest top-two gap anywhere in the matrix but still an ordering rather than a tie, since 0.15 on a 1–5 weighted scale is a narrow lead and the arithmetic does not wobble. Polaris scores 5 on five criteria (multi-engine, federation, cloud-native, cost, on-prem, with open governance at 4); cumulative breadth survives the downweighting to 410 points. Delta+Unity concentrates 5s on the two heaviest-weighted criteria (RBAC at 25, cloud-native at 15) and scores 4 on most of the rest; the concentration on what B prioritizes produces 395 points. This is the matrix saying "Archetype B is Delta+Unity's home" is true in a directional sense (Delta+Unity lifts +0.65 from A's 3.30 to B's 3.95) but not by enough to overtake Polaris's breadth, which holds the top spot. The customer call becomes "do you want broad strength or RBAC-and-managed-cloud concentration?" If RBAC weight were 30 (not 25), Delta+Unity's catalog-enforced 5 would close or flip the gap; if multi-engine weight were 15 (not 10), Polaris would extend its lead. The 25/10 split is defensible per MDR-0018 but it is what orders the top two.
Nessie's flat profile: by design, not by accident
Iceberg+Nessie sits at 3.05–3.25 across all three archetypes without ever winning. The spread is only 0.20, the smallest of any candidate. The matrix is doing its job: Nessie's differentiator is Git-style branching with multi-table atomic commits, which scores 5 on the time_travel_branching_catalog criterion at all three archetypes. But that criterion is weight 5 at every archetype; there is no weight vector in the v1 candidate set that elevates branching to a primary criterion. The engagement subset where Nessie's branching pattern dominates (engineering-shop with detection-as-code workflows, OCSF normalization across 15+ tables that must stay consistent) is a real customer pattern but a sub-archetype of A. v1.4 may add a fourth archetype, or sub-weight A, to surface Nessie's home more sharply.
Polaris's monotonic decline: the breadth-vs-specialization story
Iceberg+Polaris declines monotonically 4.25 → 4.10 → 3.90 from A through C. The decline is small because Polaris's strengths (multi-engine, federation, cost, cloud-on-prem flexibility, open governance) hit ceiling scores at A and continue to score 4–5 even as their weights drop. The 0.35-point A-to-C decline reflects the structural RBAC gap and the not-AWS-native cloud-native gap; both are honest, both are deliberate trade-offs for portability. The honest customer call across all three archetypes: Polaris is the safe default whenever the customer's archetype is not strongly committed; the specialized choices (Unity at B, Glue at C, Nessie at A-subset) are the optimization on top.
v1.3 evidence integration
Four first-party surfaces landed on 2026-05-25. Formats+Catalogs is the component most affected.
The v1.3 evidence cut on 2026-05-25 delivered four first-party measurements that bear directly on the Formats+Catalogs scoring. A-05 moved from open to confirmed. MDR-0025 was added as a Proposed decision. A-04 picked up friction characterization (without changing trajectory). A-06 picked up per-stack reachability detail that affects schema-evolution scoring rationale. None of the headline weighted totals moved, but the evidence underneath strengthened materially.
This is the component most affected by v1.3 because every one of the four measurements lands on a C1+C2 candidate or interaction. The Engines matrix carries one v1.3 signal (the Trino federation-overhead smoke: +35.6 ms at toy scale, an engine-layer number that reads on A-13's ~2.67s public-data federation floor by attributing roughly 91% of that gap to base-engine cost rather than federation); the Pipelines matrix carries zero direct v1.3 signals. F+C carries four, two of which are first-party Tier-B measurements I personally captured in the local docker stack on 2026-05-25 between roughly 14:00 and 19:00 Eastern. The methodology principle is that v-cuts narrate the evidence that arrived rather than the conclusions the evidence supports; this section is the narrative.
A-05 confirmed: Unity OSS self-hosted is operationally immature
Status changed from open to confirmed on 2026-05-25, backed by two distinct first-party surfaces. The claim: Unity Catalog self-hosted remains operationally immature relative to Databricks-hosted through the next revalidation cycle (until 2026-11-25). Confidence: high.
Surface 1, deployment maturity (per the 2026-05-25 Unity OSS deployment-maturity research-log entry). Server v0.4.1 is still pre-1.0; the chart has no semver release (SHA pin required); the chart is not on any Helm registry; the default metastore is H2 in-memory; the default image tag is main (unstable). The GitHub-tagged v0.4.1 image is not pushed to Docker Hub. v0.4.0 (2026-02-11) is the highest published image; image-pin discrepancy at the registry boundary.
Surface 2, Iceberg-REST functional incompleteness (per the 2026-05-25 Unity OSS Iceberg-REST read-only research-log entry). Unity OSS v0.4.0 exposes the Iceberg REST catalog API as a read-only subset. GET /v1/{prefix}/namespaces works; POST /v1/{prefix}/namespaces returns NotImplementedError: Server does not support endpoint. Same for POST tables, commits, deletes. pyiceberg list_namespaces() succeeds; create_namespace() fails. Standard tooling that expects symmetric Iceberg REST write semantics cannot treat Unity OSS as a peer write-target to Nessie or Polaris.
Scoring implication. Delta+Unity's cloud_native_vs_self_hosted = 2 at Archetype A and the same score weight at Archetype B (2 / 5, where B uses 5 for Databricks-managed, not OSS) both hold up under the strengthened evidence. The score of 2 may actually understate the gap; the Iceberg-REST asymmetry is a second-order penalty that the current criterion set does not capture. A v1.4 refresh may add a per-criterion penalty on rbac_and_column_level_security for any candidate where the catalog's external-client write surface is incomplete, since RBAC policy wiring through a broken POST surface is operationally fragile. Deferred decision.
Reproducibility footprint. Both surfaces are reproducible in roughly 30 minutes against the local docker stack. Surface 1 reproduces via docker pull unitycatalog/unitycatalog:latest and inspecting the manifest history (only v0.4.0 published); Surface 2 reproduces by attaching pyiceberg to the Unity OSS Iceberg-REST endpoint and calling create_namespace(), where the NotImplementedError appears immediately. The 30-minute reproducibility budget is a deliberate v1.3 evidence-quality target: Tier-B first-party measurements should be re-runnable by anyone with the docker stack within a coffee-break window. Higher friction signals lower evidence quality regardless of how convincing the original measurement looked.
MDR-0025 (Proposed): Nessie and Polaris share metadata-fetch latency at toy scale
Status: Proposed on 2026-05-25. Adoption gate: Q3 2026 catalog benchmark at >1M-row scale.
The measurement: 9 queries × 3 runs × 2 catalogs = 54 timings against a local Docker stack (SeaweedFS + Nessie + Polaris + DuckDB), data byte-identical replicated from Nessie to Polaris. Workload: 5K rows total (5 source classes × 1K rows per table), the toy scale the finding is named for. Nessie median 98.9 ms, p95 241.1 ms. Polaris median 96.4 ms, p95 236.0 ms. All 9 queries within 5% on median across 3 runs. Statistically indistinguishable.
Scoring implication. Removes catalog-driver overhead as a Nessie-vs-Polaris differentiator on the read path at toy scale. The Polaris-vs-Nessie spread on this matrix (Polaris 4.25 vs Nessie 3.10 at Archetype A; 4.10 vs 3.25 at B; 3.90 vs 3.05 at C) is not driven by metadata-fetch latency. It is driven by RBAC posture, ecosystem maturity, and engine breadth. If a future v1.4 taxonomy refresh adds metadata_fetch_latency as an explicit scored criterion, the two catalogs would score equal on that dimension at small scale, and the differentiation would have to come from the production-scale (>1M-row) follow-up. The toy-scale Tier-B finding does NOT generalize without that counterpart measurement. Adoption gate held until Q3.
The +35.6 ms Trino federation overhead measured in the sibling 2026-05-25 federation-overhead smoke (Trino 476 joining byte-identical tables across Nessie and Polaris; single-catalog median 158.3 ms, federated 193.9 ms, per A-13) sits in a different layer (engine-layer federation) than the catalog-driver metadata fetch measured here. The two are not comparable and not contradictory. Both anchor independent points on the F+C cross-component coupling story.
A-04: Polaris ecosystem trajectory confirmed; specific friction characterized
Status holds at open with medium confidence (per the 2026-05-25 Polaris deployment-maturity research-log entry). The trajectory claim (Apache Polaris adoption accelerates as ASF governance and Snowflake commercial momentum compound) picks up first-party signal: Apache published the first official Helm chart apache-polaris-1.5.0 on 2026-05-18, eight days before the v1.3 cut.
But the chart ships with friction: it requires k8s 1.33+ (bleeding-edge), is not yet on any Helm registry (install from cloned source), defaults to in-memory persistence (no documented production Postgres-backed path in 1.5.0), and the docker POLARIS_BOOTSTRAP_CREDENTIALS env-var pattern silently regenerates root credentials when the realm name is wrong. OAuth client-credentials flow requires bootstrapping a service principal via the management API rather than via env. STS-less S3 backends need X-Iceberg-Access-Delegation: "" as a header override.
I read these as friction signals along the maturity trajectory, not refutations. The trajectory claim holds; the per-engagement diligence list gets refined. Polaris's catalog_ecosystem_maturity = 3 at Archetypes A and B stays accurate; the youth is real, the trajectory is intact.
A-06: Iceberg V3 row-lineage stack reachability (per-stack, not uniform)
Per the 2026-05-25 Iceberg V3 row-lineage stack-blockers research-log entry, V3 row-lineage is reachable end-to-end on Spark 3.5.6 + Hadoop catalog + Iceberg ≥1.11. The _row_id populates correctly across snapshots. The research log counts four stacked blockers on the no-Spark path, and two of them sit on the pyiceberg + Nessie pair specifically: pyiceberg 0.11.1 cannot write V3 at all, and Nessie 0.107.5 silently downgrades V3 to V2 at the catalog layer. The third is reader-side, because DuckDB iceberg_scan() does not expose _row_id even when explicitly requested, independent of writer or catalog. The fourth is the DML path: pyiceberg's overwrite and upsert operations collapse snapshot history (one visible snapshot after three writes), which undercuts even V2-level audit-trail reconstruction. Polaris ≥1.5.0 and Databricks Unity are not yet tested.
Scoring implication. Schema_evolution_time_travel_format scored 4 uniform across Iceberg pairs in v1.3. The per-stack reachability nuance means the score is correct in aggregate (V3 features ship, engine support is rolling) but the caveat language sharpens. For an engagement that depends on row-lineage specifically, the stack-blockers map matters more than the format-level score. The 5-weight criterion does not move the ranking; the diligence on which engine + catalog stack the customer actually plans to deploy is now refinable to the per-stack cell.
Why row-lineage matters for a security-data engagement. Iceberg V3 row-level lineage exposes a stable _row_id across snapshots so downstream consumers can treat the table as a change-data-capture source without an external CDC tier. For the SOC pattern, that maps directly to detection-rule fan-out: a Sigma rule that fires on a row in the bronze table can be reliably joined to the same row after silver/gold transforms have rewritten the table. Without row-lineage, the consumer joins on natural keys (event-time, source-host) that may not be unique. The pyiceberg + Nessie blockers mean that the no-Spark stack (pyiceberg + DuckDB + Nessie + MinIO/SeaweedFS) cannot adopt row-lineage in v1.3; the Spark + Hadoop + Iceberg ≥1.11 stack can. For the Iceberg+Polaris and Iceberg+ Nessie scoring rows specifically, this means the engagement diligence should ask which engine the customer plans to use as the writer. Spark gets row-lineage today; pyiceberg does not.
Aggregate v1.3 takeaway. No weighted total moves; the evidence underneath strengthens. A-05 confirmation pins Delta+Unity's self-hosted score at 2. MDR-0025 parity finding pins the Polaris-vs-Nessie spread to RBAC and ecosystem differentiators rather than catalog-driver overhead. A-04 friction characterization sharpens the per-engagement diligence list without lowering Polaris's maturity score. A-06 stack-blocker map makes the schema-evolution caveat per-stack rather than per-candidate. Next v-cut is gated on Q3 2026 catalog comparison benchmark at >1M-row scale; until then the toy-scale evidence is the floor.
Cross-component coupling
The C1+C2 choice constrains three other components. Read this before the engagement.
C3 (engine). Engine choice acts as a hard filter on catalog viability. ClickHouse, ranked #1 in the Engines matrix at Archetype A, pairs cleanly with Polaris (native via Iceberg REST) or Glue (via Glue REST in AWS). ClickHouse-Nessie integration is unvalidated in the engagements I've seen; the REST API should make it work in principle but production-grade evidence is missing. ClickHouse on Delta+Unity sits in UniForm read-only mode, a material constraint if write paths run through ClickHouse. The implication: a ClickHouse-led shop pulls Polaris up and pulls Unity down beyond what the standalone F+C scores suggest. If the engine is fixed (ClickHouse), the catalog choice flattens to "Polaris or Glue, and Glue only if AWS-only."
C4 (pipeline). OCSF normalization at ingest matters for all four pairs but is most essential under Polaris and Nessie. Where governance is delegated to the engine layer, schema-correct data reduces engine-layer RBAC complexity. Under Delta+Unity, the catalog enforces the policy regardless of ingest schema correctness; under Glue, Lake Formation policies bind to the Glue catalog tables independently of the pipeline. The C4 + C1+C2 interaction is highest-stakes for the engineering-shop-with-Nessie pattern: detection-as-code workflows depend on multi-table atomic commits, which depend on consistent OCSF normalization across the tables being committed together.
C6 (storage tier). All four pairs assume object storage. Polaris and Nessie are storage-agnostic (S3, Azure Blob, GCS, MinIO, SeaweedFS, on-prem S3-compatible); Glue ties to S3 specifically; Unity prefers Databricks-managed storage with multi-cloud support via the Databricks Workspace. If air-gapped on-prem is in-scope, only Polaris and Nessie remain viable.
C6 storage-layer maintenance flag (MDR-0024, Proposed). The MinIO archive verified 2026-05-25 (repo archived 2026-02-13 after UI removal in 2025-05, community Docker stop 2025-10-23, README to maintenance mode 2025-12-03) demonstrates that storage-layer maintenance status is a material risk for F+C choices when the candidate stack depends on a specific S3-compatible backend. The flag is per-candidate (not a scored criterion) with values ACTIVE, MAINTENANCE, ARCHIVED. Polaris-on-MinIO or Nessie-on-MinIO inherits the MinIO archived status as risk; SeaweedFS is the current ACTIVE alternative I've validated in the local docker stack. The Delta+Unity and Glue paths are unaffected by this specific flag because neither defaults to a self-managed S3-compatible backend.
Aggregate. The C1+C2 choice is rarely orthogonal to C3, C4, or C6. The matrix ranks F+C in isolation per archetype, but engagement diligence pulls in the engine compatibility view (ClickHouse / Trino / StarRocks / DuckDB × four pairs), the pipeline OCSF coupling, and the storage-layer maintenance-status flag. The synthesis page covers how the cross-component coupling reads across all nine cells of the matrix.
Engagement diligence checklist when F+C is the gating decision. If the engagement starts with the format and catalog choice (as opposed to the engine or the platform pattern), I run a five-item check before the scoring table is decisive.
- What engine does the customer plan to use as the primary writer? ClickHouse, Spark, pyiceberg, and Trino each have different V3 / V4 currency, which colors the schema_evolution_time_travel_format caveat per-stack.
- Is the storage tier a managed cloud service or a self-managed S3-compatible backend? If self-managed, which one? MinIO is archived in v1.3 (MDR-0024 flag); SeaweedFS is the ACTIVE alternative I have validated.
- What is the multi-tenant posture? Single-tenant isolated platforms can live with engine-layer governance (Polaris + Trino ACLs); multi-tenant MSSPs need catalog-enforced RBAC (Unity-on-Databricks or Lake Formation).
- What does the migration path off the choice look like in 5 years? Iceberg-native pairs (Polaris, Nessie, Glue) migrate by pointing at a different REST endpoint; Delta+Unity migrates via UniForm + Iceberg-rewrite, which is a multi-quarter project.
- What disclosure context applies? Delta+Unity carries a nature: explore flag (an in-progress Databricks conversation regarding Lakewatch go-to-market, no commercial relationship, no score-altering effect); the other three candidates carry null disclosure blocks per MDR-0016.
What this matrix does not score. The C1+C2 matrix scores production-credible format-and-catalog pairs against the ten criteria. It does not score: migration tooling maturity, ecosystem politics (Iceberg V3 spec status, Polaris-Snowflake commercial direction), pricing-model changes that may happen mid-engagement, or vendor-specific support SLAs. Those live in the vendor evaluations page and the assumptions page. The matrix is the candidate-elimination engine; the surrounding pages are the diligence frame.
Sibling pages
Where to read next.
Scored matrix · summary
The three scored components, all three archetypes: the nine-cell summary.
Compact view across Engines, Formats+Catalogs, and Pipelines.
Cross-archetype synthesis
Five validation patterns. One non-obvious finding per archetype.
Where the matrix becomes operable: the structural reasoning across the nine cells, including the Archetype B 4.10-vs-3.95 top two and the MDR-0025 read-path implication.
Scoring decisions (MDRs)
The matrix decision records, including MDR-0008, 0009, 0018, 0020, 0024, 0025.
Criterion set, archetype weight vectors, evidence completeness, the v1.3 additions.
Foundational assumptions
Seventeen assumptions. Each one has a refutation criterion.
A-04 (Polaris ecosystem), A-05 (Unity OSS, confirmed in v1.3), A-06 (Iceberg V3 engine rollout), A-12 (AWS Security Lake hidden cost).
Component criteria
Nine components, the scoring criteria for each.
Framing for Components 0 through 8, with cross-component dependencies surfaced.
Decision framework
The four-phase, fourteen-question framework that drives candidate elimination.
How the framework selects which archetype frames the F+C choice for a given engagement.
Capability Matrix index
Back to the Matrix.
Scored matrix, synthesis, scoring decisions, assumptions, decision framework, components, vendor evidence, decision records, plus case studies and the public reference catalog.
Page metadata
Maintained by Jeremy Wiley. v1.3 cut 2026-05-25. Revalidate by 2026-11-25 or sooner if the Q3 2026 catalog comparison benchmark lands (Tier-A anchor for catalog ecosystem maturity + multi-engine query support at production scale), Iceberg V4 ships (per the V4 milestone tracking), the Hudi structured review completes (would add Hudi+Glue), or Snowflake ships catalog-enforced row/column policy above Polaris REST (would lift Polaris RBAC scores at Archetypes A and B).