Capability Matrix · Scored matrix, archetype-first
Three archetypes. Same nine cells, read top-down per stack.
Three components are scored separately under three archetypes: Engines (Component 3), Formats+Catalogs (Components 1+2 as a paired choice), Pipelines (Component 4). That produces nine scoring runs. Same criterion set in each run; different weights per archetype produce different orderings. The same candidate can rank #1 under one archetype and #4 under another. That is the method working as designed, not a bug. This page reads the matrix archetype-first: the customer-stack view.
The three archetypes I'm running against:
- Archetype A, Zeek-heavy SOC. Platform-perf-led. 5–50 TB/day, 90d hot, 1yr warm, 80% recurring queries, p99 < 5s target. The cost-reduction-and-platform-throughput posture.
- Archetype B, federated lakehouse. Open-format-portability-led. 10–100 TB/day, multi-source federation, OCSF-normalized ingest, dashboards p99 < 10s + federated joins p99 < 30s. The single-vendor-managed-but-portable posture.
- Archetype C, analyst-led shop. TCO-and-tool-flexibility-led. AWS-native serverless, Iceberg+Glue as the foundation, pay-per-use economics, lowest skill-ramp wins. The analyst-tooling-tier posture, not the platform-engineering tier.
Each cell carries the top candidates ranked by weight-adjusted score on a 1–5 scale, where weights sum to 100 per archetype. Each archetype section opens with the cross-component stack synthesis (what the three winners are, and why they hang together) and then drills into each component cell. For the component-first read (all three Engines cells side-by-side, all three F+C cells side-by-side, etc.), see the dedicated Engines, Formats+Catalogs, and Pipelines pages.
v1.4 evidence cut · 2026-07-20
Engines concurrency moved on first-party evidence. Formats and pipelines hold.
The v1.3 evidence cut shipped 2026-05-25 without re-scoring any cell, and then two lab slices landed: the single-host engine-join bench on 2026-06-10 (Tier B) and the multi-user concurrency bench on 2026-06-15 (Tier B). The v1.4 cut (2026-07-20, MDR-0037) re-scores the engines concurrency cells on that concurrency evidence, which moves StarRocks from 2 to 4 at Archetypes A and B and lifts it past DuckDB at A. Formats+catalogs and pipelines were not re-scored: their v1.2 scores hold on the v1.3 evidence basis until the Q3 2026 catalog benchmark and the ~Q1 2027 H1-COST-02 pipeline benchmark land, so read Cells 2, 3, 5, 6, 8, and 9 as a dated snapshot (2026-05-25 scoring, v1.3 basis). What changed under the v1.3 evidence cut, still the basis under those held scores:
- A-05 moved from Proposed to Confirmed. The Iceberg+Polaris vs Delta+Unity spread at F+C Archetypes A and B is now backed by first-party evidence of Unity OSS Iceberg-REST functional incompleteness, not just architectural argument.
- MDR-0025 added (Proposed). Nessie vs Polaris catalog metadata-fetch latency is at parity at toy scale; the spread inside the F+C scoring between the two reflects RBAC depth and ecosystem maturity, not driver overhead. Honest narrowing of where Nessie loses.
- A-06 refined (Engines A, B, C). Iceberg V3 row-lineage is Spark-side working on Iceberg ≥1.11; pyiceberg + Nessie are blocked. The score on
iceberg_native_vs_connectoracross engines now differentially weights writer-ecosystem maturity rather than treating V3 currency as uniform.
Archetype A · Zeek-heavy SOC · platform-perf-led
The A stack: ClickHouse + Iceberg+Polaris + Tenzir (Cribl override).
Archetype A reads as a coherent platform-performance stack. ClickHouse wins the engine layer on raw analytical query performance at weight 22 (with native IP type carrying a further 8 under the v1.3 MDR-0023 split of the original 30, where ClickHouse also scores 5). Iceberg+Polaris wins the format+catalog layer because the A weights prioritize engine portability, cost flexibility, and cloud-agnosticism, where Polaris scores 5 on five criteria simultaneously. Tenzir leads Pipelines on weighted total because A treats default reduction ratio, Apache-2.0 lockin, and resource efficiency as ranking-decisive, though Cribl remains the procurement-evidence-defensible default for Fortune-100 deployments at 5+ TB/day. The unifying logic is that A buys platform throughput and accepts the under-anchored production-evidence gap on Polaris and Tenzir as a v1.x research-tier signal, not a deployment-grade certainty.
Cell 1 · Engines × Archetype A
ClickHouse leads on raw platform perf.
Weight summary: raw_analytical_query_performance 22, native_ip_type_support 8, concurrency 15, iceberg_native 15, ops_complexity 15, federation 5, semantic_layer 5, spl_dialect_distance 10, in_house_skill_base 5 (intentionally null at standing-matrix level, filled at engagement scoping). That single weight-5 null is the only source of the lower-vs-upper spread on each candidate here, a fixed 0.20-wide band (score-floor 1 vs ceiling 5 across 5 weight points), so every range on this page is a null-skill band of that width; the archetypes where the skill base is scored (C) or weighted 0 (B) carry no null and collapse to single points.
| Candidate | Final (1–5) | Top criteria-drivers | Notable caveats |
|---|---|---|---|
| ClickHouse | 3.65–3.85 | raw_perf 5; native_ip 5; concurrency 4; iceberg_native 4 | Cold-tier query on S3 less proven than Trino-over-Iceberg-on-Glacier |
| Trino | 3.41–3.61 | native_ip 5; federation 5; iceberg_V3_currency 5; raw_perf 3 | v1.3 native IP type (IPADDRESS) keeps Trino at #2; federation under-leveraged at A's 5-weight |
| StarRocks | 2.87–3.07 | concurrency 4; multi_table_join_CBO 4; raw_perf 3; native_ip 2 | Concurrency now first-party Tier-B (2026-06-15 multi-user bench, MDR-0037), which lifts it past DuckDB at A; archetype mismatch remains, since the dual-engine pattern is its home |
| DuckDB | 2.63–2.83 | ops_simplicity 5; native_ip 3; single-user_perf 4 | native_ip 3 (inet ext); single-node ceiling, can't be primary at 5–50 TB/day |
ClickHouse wins on the criterion that dominates at Archetype A: raw_analytical_query_performance at weight 22 (with native IP type carrying a further 8, where ClickHouse also scores 5), and the published Zeek benchmark earns it the raw-perf 5. Trino holds #2 (3.41–3.61) on the v1.3 native IP type criterion (IPADDRESS is first-class) plus federation and iceberg_V3_currency scores of 5, even though its raw_perf score of 3 keeps it well behind ClickHouse on the criterion A weights heaviest. Trino's federation strength is better-leveraged at Archetype B, where it becomes the outright winner. A-06 evidence refresh: ClickHouse's iceberg_native score of 4 reflects writer-ecosystem lag relative to Trino on V3 row-lineage; if ClickHouse writes catch up, that relative weakness closes. The lab revised one input that belongs here in the open: ClickHouse is structurally more expensive than Iceberg-on-S3 with a separate query engine, since the MergeTree format duplicates data and compute and storage scale together. That cost finding holds, and it is the accepted tradeoff at Archetype A, where storage cost is not a scored criterion and raw_analytical_query_performance carries weight 22 (native IP type the further 8 under v1.3), so the latency win is what the archetype is buying. The same finding is why ClickHouse reorders downward under the cost-led and federated archetypes below, where cost and simplicity dominate the weights rather than latency.
Cell 2 · Formats+Catalogs × Archetype A
Iceberg + Polaris is the Archetype-A default.
Weight summary: multi_engine_query_support 20, federation 15, cost_model 15, cloud_native_vs_self_hosted 15, RBAC 15, schema_evolution 10, ecosystem_maturity 10. Lock-in resistance dominates because engine portability is the explicit goal.
| Pair | Final (1–5) | Top criteria-drivers | Notable caveats |
|---|---|---|---|
| Iceberg + Polaris | 4.25 | multi_engine 5; federation 5; cost 5; cloud_flex 5 | Ecosystem maturity 3 — production references thin outside Pinterest |
| Delta + Unity | 3.30 | RBAC 5; ecosystem_maturity 5; schema_evolution 4 | cloud/on-prem 2 + multi_engine 3 drag against Archetype-A weights; A-05 confirmed |
| Iceberg + Nessie | 3.10 | branching 5; cloud_flex 5; cost 5 | RBAC 2 (engine-layer delegation); engine breadth 3; MDR-0025 (Proposed) on metadata-latency parity |
| Iceberg + Glue | 2.70 | ecosystem_maturity 4 (within AWS); RBAC 4 | on-prem flexibility 1 decisive against A; mislabeling — honest C territory |
Iceberg+Polaris wins decisively at A. The gap-to-#2 is 0.95, the largest spread in any F+C cell. Polaris scores 5 on five criteria simultaneously (multi-engine query support, federation, cloud-native-versus-self-hosted, cost model, and cloud/on-prem flexibility), with open governance at 4 rather than 5 because Polaris is Snowflake-donated and Snowflake-managed in its hosted form. The Delta+Unity #2 position is honest but archetype-mismatched: RBAC at 5 is real, but cloud/on-prem flexibility at 2 and multi-engine at 3 drag too hard at A's weights. With A-05 now confirmed, the Unity OSS Iceberg-REST gap is first-party evidence, so the spread to Polaris is structural, not interpretive. Nessie at #3 is the choice for engineering shops that treat detection logic as code; the branching score 5 doesn't carry weight at A's settings because branching isn't an A design center.
Cell 3 · Pipelines × Archetype A
Tenzir leads on weighted total. Cribl wins on production evidence.
Weight summary: default_reduction_ratio 20, ocsf_normalization_fidelity 5, pricing_model 15, vendor_lockin 10, resource_consumption 10, lines_of_config 15, correlation_capability 5, aggressive_workload 10, in_house_skill_base 10 (intentionally null — engagement fills it in; produces the lower-vs-upper bound spread).
| Candidate | Final (1–5) | Top criteria-drivers | Notable caveats |
|---|---|---|---|
| Tenzir | 3.75–3.95 | OCSF-native 4; Apache-2.0 lockin 5; resource 4 | Production evidence Tier B/C; public customer count under 100 |
| Cribl | 3.35–3.55 | production_validation 5; reduction_ratio 4 | Proprietary lockin 2; per-volume licensing; 70–90% reduction is tuned-not-default |
| Vector | 3.25–3.45 | OSS pricing 5; lockin 5; resource 5 | OCSF 2 — generalist, depends on VRL skill in-house |
| Kafka Connect | 2.00–2.20 | lockin 4 (Apache); resource 4 | Archetype mismatch — streaming-to-lake, not cost-reduction |
Tenzir leads on weighted total by ~0.40 over Cribl. The honest engagement call doesn't read that way. Cribl carries Tier-B production evidence across 50+ Fortune-100 customers, which stays at B rather than climbing to A because the customers are unnamed and MDR-0003 caps an anonymized reference at Tier B on the plain ground that a reader cannot check it; Tenzir carries Tier B/C evidence that is predominantly vendor blog and documentation. For procurement gates that want named production references at 5+ TB/day, Cribl is still the safer call. Tenzir is the upgrade path when (1) OCSF is the canonical schema and non-negotiable, (2) open-source exit strategy is a procurement requirement, (3) the team can sustain 0.5–1 FTE of TQL rule authoring. The weighted total is the matrix's recommendation; the production-evidence asymmetry is the engagement override. v1.1 closes this gap with the H1-COST-02 head-to-head benchmark (~Q1 2027).
Disclosure block (Archetype A). No candidate at any component carries an active partnership disclosure: no commercial relationship or in-progress commercial exploration exists with a scored vendor.
Archetype B · Federated lakehouse · open-format-portability-led
The B stack: Trino + Polaris (4.10, narrowly over Delta+Unity 3.95) + Tenzir.
Archetype B is where the matrix produces its largest finding. Trino wins Engines by lifting from A's #2 to B's #1, on the two criteria B weights hardest and Trino was already strongest on: federation_breadth (score 5, weight climbs to 20) and iceberg_native_vs_connector (score 5, weight climbs to 25). F+C produces a near-call: Polaris at 4.10 by breadth (5 on five criteria) narrowly leads Delta+Unity at 3.95 by concentration (5 on RBAC at weight 25, 5 on cloud_native at 15). Tenzir's Pipelines lead at A holds and widens at B because Cribl drops on OCSF fidelity at weight 30. The B logic is single-vendor-managed-but-portable, and the matrix produces a procurement-defensible near-call at the F+C layer, Polaris a hair ahead, rather than manufacturing a wide separation. The Databricks-committed-vs-Snowflake-committed pivot is the customer's call, not the matrix's.
Cell 4 · Engines × Archetype B
Trino wins on federation breadth and iceberg-native depth.
Weight summary: federation 20, iceberg_native 25, raw_perf 15, native_ip 5, concurrency 10, semantic_layer 15, splunk_compat 5, ops_complexity 5, in_house_skill_base 0 (intentionally weighted 0 — "assume hire"; bounds collapse to single values).
| Candidate | Final (1–5) | Top criteria-drivers | Notable caveats |
|---|---|---|---|
| Trino | 3.90 | federation 5; native_ip 5; iceberg_V3_currency 5; raw_perf 3 | 2.67s average latency on the Zeek workload (roughly 91% base-engine cost, ~9% federation overhead per the 2026-05-25 smoke, so it is not a "federation floor"); single-source measurement could lift raw_perf to 4 |
| ClickHouse | 3.50 | raw_perf 5; concurrency 4; iceberg_native 4 | Federation 3 + semantic_layer 2 drag at B's weights; A-06: writer lag on V3 |
| StarRocks | 2.80 | raw_perf 4; multi_table_join_CBO 4; concurrency 4 | MySQL-compatible-only federation collides with B's federation 20 weight; concurrency now first-party Tier-B (2026-06-15) but at weight 5 it moves the total only 0.10 |
| DuckDB | 2.35 | ops_simplicity 5; single-user_perf 4 | Worse at B than A — single-node ceiling collides with 10–100 TB/day volume |
Trino's lift from A's #2 to B's #1 is the cleanest re-ranking finding in the matrix. Two criteria do the work: federation_breadth (Trino 5) climbs from weight 5 at A to weight 20 at B, andiceberg_native_vs_connector (Trino 5) climbs from weight 15 to weight 25. Together the two criteria Trino was already strongest on now carry 45 of B's 100 weight points, versus 20 at A. ClickHouse's raw-perf advantage (still real, still score 5) loses absolute weight (15 vs A's 22) and gets offset by a weaker semantic_layer score, dropping it to #2 at 3.50. StarRocks holds #3: its MySQL-compatible-only federation collides with B's federation weight. DuckDB drops hardest, from A's #3 to B's #4, since its single-node ceiling matters more at B's 10–100 TB/day volume than at A's smaller footprint.
Cell 5 · Formats+Catalogs × Archetype B
Polaris narrowly leads Delta+Unity, 4.10 to 3.95.
Weight summary: RBAC 25, cloud_native 15, ecosystem_maturity 15, multi_engine 10, cost 10, schema_evolution 10, federation 10, on-prem flexibility 5. RBAC concentration is the archetype's design center.
| Pair | Final (1–5) | Top criteria-drivers | Notable caveats |
|---|---|---|---|
| Iceberg + Polaris | 4.10 | Broad strengths across 6+ criteria scoring 5 | RBAC 3 (table-level + engine delegation); Snowflake-managed adds vendor coupling |
| Delta + Unity | 3.95 | RBAC 5; cloud_native 5; ecosystem_maturity 5 | multi_engine 3 — UniForm bridge case; A-05 confirmed |
| Iceberg + Glue | 3.45 | RBAC 4 (Lake Formation + IAM); ecosystem_maturity 4 | Cloud-native lift 3→5 lifts substantially but AWS-only ceiling holds |
| Iceberg + Nessie | 3.25 | branching 5; cost 5; cloud_flex 5 | RBAC 2 amplified at weight 25 — biggest weighted-point gap |
The honest near-call. Polaris narrowly leads at 4.10 and Delta+Unity follows at 3.95, a 0.15 gap, and the two arrive there from very different scoring shapes: Polaris by breadth (5 on five criteria), Delta+Unity by concentration on what B prioritizes (5 on RBAC at weight 25, 5 on cloud_native at 15). The narrow margin is procurement-defensible on the scoring alone: the open option (Polaris) still edges the managed one (Delta+Unity), so recommending either at B is an evidence call, not partnership steering. The customer call: Databricks-committed → Delta+Unity; Snowflake-committed → Polaris; AWS-committed → Glue and re-pose the engagement as Archetype C. With A-05 confirmed and MDR-0025 narrowing where Nessie loses (RBAC, not metadata latency), the v1.3 evidence picture is that the four-pair ordering at B reflects governance reach, not driver depth.
Cell 6 · Pipelines × Archetype B
Tenzir's lead widens. Same winner, different gap.
Weight summary: ocsf_normalization_fidelity 30, correlation_capability 15, pricing_model 10, vendor_lockin 10, resource_consumption 5, default_reduction_ratio 5, lines_of_config 15, aggressive_workload 5, in_house_skill_base 5.
| Candidate | Final (1–5) | Top criteria-drivers | Notable caveats |
|---|---|---|---|
| Tenzir | 3.70–3.90 | OCSF-native 4; correlation 5; lockin 5 | Same Tier B/C evidence floor — lead widens because Cribl drops on OCSF |
| Cribl | 3.20–3.40 | production_validation 5; correlation 4 | OCSF 3 (via Packs) at weight 30 = 30-pt swing against Tenzir's 4 |
| Vector | 2.70–2.90 | OSS pricing 5; lockin 5; resource 5 | OCSF 2 at weight 30 = wrong-tool penalty deepens; 60-pt gap to Tenzir |
| Kafka Connect | 2.00–2.20 | lockin 4; resource 4 | Same misfit as A — different reason (wrong shape for OCSF-first) |
Tenzir's absolute total at B (3.70–3.90) is essentially equal to A (3.75–3.95), and the point accounting shows why. Raising OCSF fidelity from weight 5 to 30 gains Tenzir 100 weighted points and raising cross-source correlation from 5 to 15 gains another 30, so the B reweighting adds 130 points on the two axes B prioritizes. Those gains are offset by 135 points lost as default reduction (25 to 10), aggressive reduction (10 to 5), resource (15 to 10), pricing (10 to 5), and lock-in (10 to 5) all fall in weight, so the net is 5 points down, which is the 0.05 the total moves. What changes is the lead, from ~0.40 at A to ~0.50 at B, because Cribl drops harder on the OCSF axis (score 3 vs Tenzir's 4 at weight 30, a 30-point swing) than Tenzir loses on the reduction axis. That is the subtlest validation on the page: the archetype-conditional weights preserve the winner while widening the gap, which is the same recommendation carrying more defensibility. Cribl remains the production-evidence-defensible alternative where Tier-A references are gating, and the engagement override pattern from Cell 3 still applies.
Disclosure block (Archetype B). No active partnership disclosures at any component: no commercial relationship or in-progress commercial exploration exists with a scored vendor.
Archetype C · Analyst-led shop · AWS-native, TCO-led
The C stack: Athena + Iceberg+Glue + Vector.
Archetype C is where the most dramatic shifts happen, and where the matrix earns its keep. Athena leads at C (4.29), with Trino as runner-up at 3.98 — a clear 0.31-point gap, not a near-tie — on the strength of the v1.3 native IP type criterion plus Athena's pure-serverless ops_simplicity and federation scores. Iceberg+Glue lifts +1.50 from A→C, the largest single-candidate archetype shift in v1.x, validated by MDR-0004's criterion reframing, under which AWS-native depth becomes the maturity measure that counts at C. Pipelines produces the first category-winner change across all nine cells: Vector dethrones Tenzir because C's twin design-center weights (pricing_model_defensibility 20 + vendor_lockin_score 15 = 35 combined) outrank Tenzir's OCSF fidelity. The C logic is that AWS lock-in is a deliberate design choice, and the matrix shows that an honestly-scored AWS-native stack ranks at the top of C on its own merits.
Cell 7 · Engines × Archetype C
Athena leads clearly. Trino is the closest competitor.
Weight summary: iceberg_native 25, ops_simplicity 20, multi_engine_federation 15, raw_perf 11, native_ip 4, concurrency 10, splunk_compat 5, semantic_layer 5, in_house_skill_base 5 (scored here, not null: Athena 4, Trino 3, and so on), which is why the C totals are single points rather than the 0.20-wide null-skill bands the Archetype-A cells carry.
| Candidate | Final (1–5) | Top criteria-drivers | Notable caveats |
|---|---|---|---|
| Athena | 4.29 | iceberg_native 5; ops_simplicity 5; federation 5; native_ip 4 | v1.3 native IP type (Presto/Trino IPADDRESS lineage, score 4) is part of what puts Athena at #1; raw_perf 3 + concurrency 3 are its softest scores |
| Trino | 3.98 | federation 5; iceberg_V3_currency 5; ops_simplicity 5 (managed Trino-on-EMR); native_ip 5 | Self-managed Trino-on-EKS would score 3 on ops_simplicity, dropping total to ~3.58 |
| ClickHouse | 3.65 | raw_perf 5; native_ip 5; concurrency 4; iceberg_native 4 | Raw_perf wins points but loses weight; ClickHouse Cloud-on-AWS marketplace caveat |
| DuckDB | 2.92 | ops_simplicity 5 (Lambda-native pattern); iceberg_native 4 | Concurrency 1 — analyst-overlay only, never primary |
| StarRocks | 2.82 | multi_table_join_CBO 4; raw_perf 3 | Weakest AWS-managed-cloud story; right home remains the dual-engine pattern |
Athena leads clearly at C (4.29), with Trino the closest competitor at 3.98 — a 0.31 gap, decisive rather than a coin flip. Athena wins on the pure-serverless premise: ops_simplicity 5, federation 5, and the v1.3 native IP type criterion (Presto/Trino IPADDRESS lineage, score 4) all favor a fully managed AWS-native service over a self-hosted or managed-but-separate query engine. Trino at #2 depends on the managed-Trino-on-EMR assumption to hold its ops_simplicity score of 5; a self-managed Trino-on-EKS deployment would drop that criterion to 3 and push the total down to roughly 3.58, which would open real daylight to ClickHouse at #3 (3.65). The honest engagement call: default to Athena for AWS-committed customers who want the lowest operational burden; choose Trino when the workload needs genuinely broad federation across non-AWS sources that Athena's connector set doesn't reach.
Cell 8 · Formats+Catalogs × Archetype C
Iceberg + Glue lifts +1.50 to home archetype.
Weight summary: ecosystem_maturity 25, multi_engine_query_support 20, RBAC 20, cost_model 15, cloud_native 10, schema_evolution 5, federation 5, with AWS-native depth as the design center.
| Pair | Final (1–5) | Top criteria-drivers | Notable caveats |
|---|---|---|---|
| Iceberg + Glue | 4.20 | ecosystem_maturity 5; multi_engine 5; RBAC 5 | AWS Security Lake hidden-cost delta 20–40% per A-12; cost score 4 not 5 |
| Iceberg + Polaris | 3.90 | Broad strengths persist; cost 5; cloud_flex 5 | Not AWS-native; Snowflake-managed adds vendor; ecosystem_maturity 3 at C |
| Delta + Unity | 3.60 | RBAC 5; schema_evolution 4 | Databricks-on-AWS ≠ AWS-native; ecosystem_maturity drops 4→3 at C |
| Iceberg + Nessie | 3.05 | branching 5; cost 5; cloud_flex 5 | No native IAM story; branching specialty doesn't anchor C's design center |
Glue's +1.50 lift A→C is the largest single-candidate archetype shift in v1.x. Four score shifts drive it (the criterion reframing permitted by MDR-0004): multi_engine_query_support 3→5, since AWS-native is the full scope under C; catalog_ecosystem_maturity 4→5, where AWS depth is the maturity measure that counts; rbac_and_column_level_security 4→5, where Lake Formation plus IAM sets the governance bar; and cost_model 3→4, where pay-per-use transparency is the economics the archetype rewards. Each shift is documented with an explicit caveat in the YAML, not goalpost-moving. Polaris at #2 at 3.90 is honest middle ground; the hedge against AWS lock-in contradicts C's "accept Glue lock-in" premise. If you're hedging, you're actually Archetype A, not C.
Cell 9 · Pipelines × Archetype C
Vector dethrones Tenzir. The first category-winner change.
Weight summary: pricing_model_defensibility 20, ocsf_fidelity 20, vendor_lockin 15, lines_of_config 15, resource_efficiency 10, default_reduction_ratio 10, correlation_capability 5, aggressive_workload 5, in_house_skill_base 0.
| Candidate | Final (1–5) | Top criteria-drivers | Notable caveats |
|---|---|---|---|
| Vector | 3.55 | pricing 5; lockin 5; resource 5 | OCSF 2 — depends on VRL fluency or Rust/serverless culture; Datadog stewardship |
| Tenzir | 3.40 | OCSF 4; correlation 5; lockin 4 | Commercial cost penalty at C; OCSF advantage doesn't overcome 35-pt pricing+lockin gap |
| Kinesis Firehose + Lambda | 3.35 | pricing 5; lines_of_config 4 | lockin 1 — structural AWS lock-in penalized only if customer reads the signal |
| Cribl | 2.95 | production_validation 5; correlation 4 | Per-volume licensing on AWS = double cost; pricing 2 + lockin 2 |
| Kafka Connect | 2.75 | lockin 4 (Apache); resource 4 | Right home is streaming-fan-out (Archetype D — not yet scored) |
Vector at 3.55 / Tenzir at 3.40 / Firehose+Lambda at 3.35 = 0.20-point spread across three genuinely different procurement postures. The matrix is telling AWS-committed customers that the top-3 spread is real but narrow. The pivot is the customer's lock-in posture: lock-in-tolerant (durably committed to AWS, no multi-cloud roadmap) → Firehose+Lambda is defensible and cheapest; lock-in-cautious (multi-cloud roadmap, vendor-portability is a deliberate goal) → Vector or Tenzir; OCSF-fidelity- binding (Reg-SCI audit or AWS Security Lake completeness ≥95%) → Tenzir regardless of economics. The "no dominant winner" finding IS the matrix working as designed. When reality doesn't have a clean answer, the matrix shouldn't manufacture one.
Disclosure block (Archetype C). No active partnership disclosures at any component. Recommend Glue for AWS-committed engagements; the call rests on the scoring alone.
Recent cuts log
v1.4 re-scored engines concurrency. v1.3 was evidence-only.
What shipped 2026-07-20 (v1.4). One targeted re-score: the enginesconcurrency_multi_tenant_behavior cells move to the first-party 2026-06-15 multi-user bench per MDR-0037. StarRocks goes from 2 (Tier C, "no published data") to 4 (Tier B, measured best-behaved under load), which lifts it past DuckDB at Archetype A (2.87–3.07 over 2.63–2.83) and to 2.80 at B. ClickHouse and Trino keep their concurrency 4 with the bench added as a citation, and the Trino Archetype-B concurrency cell re-tiers B to A on the named-operator Pinterest reference. Formats+catalogs and pipelines were untouched.
What shipped 2026-05-25 (v1.3). An evidence-strengthening pass, not a methodology change. Three concrete updates:
- A-05 moved Proposed → Confirmed. The Iceberg+Polaris vs Delta+Unity spread at F+C Archetypes A and B is now backed by first-party evidence of Unity OSS Iceberg-REST functional incompleteness, not architectural argument. Affects cells 2 and 5 narratively, not score-wise.
- MDR-0025 added (Proposed). Nessie vs Polaris metadata-fetch latency at parity at toy scale; the spread inside F+C scoring is RBAC depth and ecosystem maturity, not driver overhead. Honest narrowing of where Nessie loses. Applies across cells 2, 5, and 8.
- A-04 and A-06 first-party citations. A-06 refined: Iceberg V3 row-lineage is Spark-side working on Iceberg ≥1.11; pyiceberg + Nessie blocked. The Engines
iceberg_native_vs_connectorscoring now differentially weights writer-ecosystem maturity across cells 1, 4, and 7.
What stayed the same. Outside the engines concurrency cells, no scores moved. The formats+catalogs and pipelines tables hold their v1.2 scores until the gating Tier-A evidence lands: the Q3 2026 catalog benchmark (anchors F+C maturity scores at Tier A) and the H1-COST-02 head-to-head pipeline benchmark plus OCSF lossiness measurement around Q1 2027 (anchors Pipelines OCSF fidelity and reduction-ratio at Tier A). On engines, the single-host slice already landed (2026-06-10 join bench and 2026-06-15 concurrency bench, both Tier B), while the cluster, federated-join, and AWS-native scenarios that would anchor engine federation and distributed concurrency at Tier A are still open. Until those land, the production-evidence asymmetry on Pipelines and the under-anchored Polaris production references on F+C are the v1.x limits I'm honest about.
The next score-changing cut for formats and pipelines lands when the Q3 2026 catalog benchmark result is reproducible and citable; the engines concurrency cut already landed on the 2026-06-15 bench.
The other Matrix pages.
Seven of the nine cells above are the v1.2 scored matrix read archetype-first; the two engines cells at Archetypes A and B carry the v1.4 concurrency re-score (MDR-0037). The companion pages cover the components read component-first, the scoring criteria, the MDRs that govern the methodology, the foundational assumptions, the evidence discipline behind the scored candidate files, the decision framework, and the cross-archetype synthesis.