{
  "$schema": "https://shirokoff.ca/architecture-radar/scorecards.schema.json",
  "note": "Source of truth for the Architecture Radar scorecards. The HTML tables, mermaid radar-beta curves and ECharts series in each assessment are generated from this file. Axes differ per assessment; scores are only comparable within one assessment.",
  "scale": {
    "min": 0,
    "max": 5,
    "meaning": "Higher = lower risk for that assessment's stated use case, not 'better in the abstract'."
  },
  "assessments": {
    "clickhouse": {
      "title": "ClickHouse",
      "url": "/architecture-radar/clickhouse",
      "category": "data",
      "reviewed": "2026-Q3",
      "published": "2026-07-08",
      "use_case": "High-volume real-time analytics — observability, events, clickstream, customer-facing dashboards.",
      "axes": [
        "Query Performance",
        "Real-Time Ingestion",
        "Lakehouse Fit",
        "SQL & Modeling",
        "Cloud Elasticity",
        "Reliability / HA / DR",
        "Governance & Security",
        "Ops & Observability",
        "Ecosystem Integration",
        "TCO / Cost Efficiency"
      ],
      "axes_short": [
        "Performance",
        "Real-Time",
        "Lakehouse",
        "SQL",
        "Elasticity",
        "HA / DR",
        "Governance",
        "Ops",
        "Ecosystem",
        "Cost"
      ],
      "target": "ClickHouse",
      "platforms": {
        "ClickHouse": [
          4.7,
          4.3,
          3.8,
          3.9,
          4.1,
          3.9,
          3.4,
          3.6,
          4.1,
          4.5
        ],
        "StarRocks": [
          4.7,
          4.3,
          4.4,
          4.1,
          3.9,
          3.8,
          3.7,
          3.6,
          3.8,
          4.3
        ],
        "Snowflake": [
          4.2,
          3.6,
          4.1,
          4.7,
          4.6,
          4.8,
          4.8,
          4.6,
          4.6,
          3.2
        ],
        "Druid / Pinot": [
          4.4,
          4.6,
          3.0,
          3.4,
          3.8,
          3.9,
          3.2,
          3.2,
          3.6,
          3.8
        ]
      },
      "verdict": "Adopt for real-time analytics at volume; Narrow Use as a general warehouse."
    },
    "doris-vs-starrocks": {
      "title": "Apache Doris vs StarRocks",
      "url": "/architecture-radar/doris-vs-starrocks",
      "category": "data",
      "reviewed": "2026-Q3",
      "published": "2026-07-08",
      "use_case": "Real-time, high-concurrency analytical serving with CDC ingestion and lakehouse acceleration.",
      "axes": [
        "Query Performance",
        "Real-Time Ingestion",
        "Lakehouse Fit",
        "SQL & Modeling",
        "Cloud Elasticity",
        "Reliability / HA / DR",
        "Governance & Security",
        "Ops & Observability",
        "Ecosystem Integration",
        "TCO / Cost Efficiency"
      ],
      "axes_short": [
        "Performance",
        "Real-Time",
        "Lakehouse",
        "SQL",
        "Elasticity",
        "HA / DR",
        "Governance",
        "Ops",
        "Ecosystem",
        "Cost"
      ],
      "target": "StarRocks",
      "platforms": {
        "StarRocks": [
          4.7,
          4.3,
          4.4,
          4.1,
          3.9,
          3.8,
          3.7,
          3.6,
          3.8,
          4.3
        ],
        "Apache Doris": [
          4.4,
          4.3,
          4.0,
          4.0,
          3.8,
          3.6,
          3.3,
          3.5,
          3.8,
          4.4
        ],
        "Snowflake": [
          4.2,
          3.6,
          4.1,
          4.7,
          4.6,
          4.8,
          4.8,
          4.6,
          4.6,
          3.2
        ],
        "ClickHouse": [
          4.6,
          4.0,
          3.5,
          3.8,
          3.9,
          3.7,
          3.3,
          3.5,
          4.0,
          4.4
        ]
      },
      "verdict": "StarRocks: Adopt for join-heavy BI + lakehouse acceleration. Doris: Adopt for real-time upsert serving."
    },
    "voice-agent-platforms": {
      "title": "Voice agent platforms",
      "url": "/architecture-radar/voice-agent-platforms",
      "category": "ai",
      "reviewed": "2026-Q3",
      "published": "2026-07-16",
      "use_case": "Enterprise phone-based voice agent — PSTN, cascaded STT/LLM/TTS, tool calling, compliance review.",
      "axes_note": "Re-cut for the voice domain; NOT comparable with the analytics assessments above.",
      "axes": [
        "Latency & Turn-Taking",
        "Telephony & Channels",
        "Tool Calling",
        "Model Flexibility",
        "Scale & Elasticity",
        "Reliability / HA / DR",
        "Governance & Compliance",
        "Observability & Evals",
        "Ecosystem",
        "TCO / Cost Control"
      ],
      "axes_short": [
        "Latency & Turns",
        "Telephony",
        "Tool Calling",
        "Model Flex",
        "Scale",
        "HA / DR",
        "Governance",
        "Observability",
        "Ecosystem",
        "Cost Control"
      ],
      "target": "LiveKit",
      "platforms": {
        "LiveKit": [
          4.6,
          4.6,
          4.2,
          4.5,
          4.4,
          4.2,
          3.9,
          3.8,
          4.3,
          4.0
        ],
        "Pipecat": [
          4.5,
          3.9,
          4.3,
          4.7,
          3.9,
          3.8,
          4.0,
          3.7,
          4.0,
          4.2
        ],
        "Vapi": [
          4.0,
          4.4,
          3.9,
          3.5,
          4.2,
          4.0,
          3.6,
          4.1,
          3.8,
          2.9
        ],
        "Managed cloud": [
          4.2,
          3.4,
          4.0,
          2.8,
          4.6,
          4.6,
          4.7,
          4.0,
          3.9,
          3.4
        ]
      },
      "verdict": "Trial LiveKit for voice-core products; Vapi where voice is a secondary channel; managed clouds only when data residency binds."
    },
    "cloud-data-platforms": {
      "title": "Snowflake vs Databricks vs Microsoft Fabric",
      "url": "/architecture-radar/cloud-data-platforms",
      "category": "data",
      "reviewed": "2026-Q3",
      "published": "2026-07-17",
      "use_case": "The core warehouse-lakehouse of record for an enterprise: mixed BI and data engineering, governed, multi-team, with AI/ML workloads alongside.",
      "axes": [
        "Query Performance",
        "Real-Time Ingestion",
        "Lakehouse Fit",
        "SQL & Modeling",
        "Cloud Elasticity",
        "Reliability / HA / DR",
        "Governance & Security",
        "Ops & Observability",
        "Ecosystem Integration",
        "TCO / Cost Efficiency"
      ],
      "axes_short": [
        "Performance",
        "Real-Time",
        "Lakehouse",
        "SQL",
        "Elasticity",
        "HA / DR",
        "Governance",
        "Ops",
        "Ecosystem",
        "Cost"
      ],
      "target": "Snowflake",
      "platforms": {
        "Snowflake": [
          4.2,
          3.6,
          4.1,
          4.7,
          4.6,
          4.8,
          4.8,
          4.6,
          4.6,
          3.2
        ],
        "Databricks": [
          4.4,
          4.0,
          4.8,
          4.4,
          4.6,
          4.6,
          4.7,
          4.3,
          4.7,
          3.4
        ],
        "Microsoft Fabric": [
          3.8,
          3.9,
          4.3,
          4.0,
          4.0,
          4.1,
          4.4,
          3.8,
          4.2,
          3.6
        ]
      },
      "verdict": "All three are Adopt for the right shop. Databricks if the lake and ML are the centre; Snowflake if governed SQL serving is; Fabric if you are a Microsoft estate and value integration over ceiling."
    },
    "orchestration": {
      "title": "Airflow vs Dagster vs Prefect",
      "url": "/architecture-radar/orchestration",
      "category": "data",
      "reviewed": "2026-Q3",
      "published": "2026-07-17",
      "use_case": "The orchestration layer for a production data platform: scheduled and event-driven pipelines, dbt-heavy transformation, multi-team, with real on-call.",
      "axes_note": "Orchestration-specific axes; NOT comparable with the analytics assessments.",
      "axes": [
        "Scheduling & Triggering",
        "Asset & Lineage Model",
        "Developer Experience",
        "Local Testing & CI",
        "Scale & Concurrency",
        "Reliability & Recovery",
        "Observability & Debugging",
        "Ecosystem & Integrations",
        "Ops Burden",
        "TCO / Cost Control"
      ],
      "axes_short": [
        "Scheduling",
        "Assets",
        "Dev UX",
        "Testing",
        "Scale",
        "Recovery",
        "Observability",
        "Ecosystem",
        "Ops",
        "Cost"
      ],
      "target": "Dagster",
      "platforms": {
        "Apache Airflow": [
          4.6,
          3.6,
          3.4,
          3.2,
          4.5,
          4.2,
          3.8,
          4.9,
          3.2,
          3.9
        ],
        "Dagster": [
          4.2,
          4.8,
          4.5,
          4.6,
          4.0,
          4.2,
          4.6,
          4.0,
          3.9,
          3.9
        ],
        "Prefect": [
          4.0,
          3.8,
          4.6,
          4.2,
          3.9,
          4.0,
          4.0,
          3.7,
          4.2,
          3.8
        ]
      },
      "verdict": "Dagster: Adopt when assets are the centre of the stack. Airflow: Adopt as the low-regret default, especially at multi-team scale. Prefect: Trial for Python-first teams."
    },
    "dbt-transformation-layer": {
      "title": "dbt and the transformation layer",
      "url": "/architecture-radar/dbt-transformation-layer",
      "category": "data",
      "reviewed": "2026-Q3",
      "published": "2026-07-17",
      "use_case": "The SQL transformation layer of a warehouse-centric platform: modeling, testing, lineage, and CI for an analytics-engineering team.",
      "axes_note": "Transformation-layer axes; NOT comparable with the analytics assessments.",
      "axes": [
        "Modeling Expressiveness",
        "Build Performance",
        "Incremental Correctness",
        "Testing & Data Quality",
        "Lineage & Documentation",
        "CI / Dev Loop",
        "Governance",
        "Ecosystem & Hiring",
        "Ops Burden",
        "Vendor & Licence Risk"
      ],
      "axes_short": [
        "Modeling",
        "Build Perf",
        "Incremental",
        "Testing",
        "Lineage",
        "CI Loop",
        "Governance",
        "Ecosystem",
        "Ops",
        "Vendor Risk"
      ],
      "target": "dbt (Core + Fusion)",
      "platforms": {
        "dbt (Core + Fusion)": [
          4.3,
          4.4,
          3.6,
          4.2,
          4.4,
          4.3,
          3.9,
          4.9,
          4.1,
          3.0
        ],
        "SQLMesh": [
          4.4,
          4.3,
          4.7,
          4.4,
          4.4,
          4.6,
          3.9,
          3.2,
          3.9,
          3.2
        ],
        "Warehouse-native": [
          3.2,
          4.2,
          4.0,
          3.2,
          3.4,
          3.0,
          4.2,
          3.4,
          4.5,
          2.6
        ],
        "Hand-rolled SQL": [
          2.6,
          3.0,
          2.4,
          2.0,
          1.8,
          2.4,
          2.2,
          2.6,
          1.8,
          4.6
        ]
      },
      "verdict": "dbt: Adopt — still the default, and the Fusion rewrite is real. But vendor risk is now the weakest axis, not a footnote."
    },
    "data-platform-techniques": {
      "title": "Data platform techniques",
      "url": "/architecture-radar/data-platform-techniques",
      "category": "data",
      "reviewed": "2026-Q3",
      "published": "2026-07-17",
      "use_case": "Six practices a data platform team chooses to adopt or skip: analytics engineering, medallion architecture, the metrics layer, data contracts, lakehouse-native serving, and data mesh.",
      "axes_note": "These are practices, not products. The axes are re-cut accordingly and are NOT comparable with any product assessment.",
      "axes": [
        "Problem Fit",
        "Evidence & Maturity",
        "Time to Value",
        "Discipline Required (inverted: higher = less discipline needed)",
        "Reversibility",
        "Tooling Support",
        "Governance Impact",
        "Scale Behaviour",
        "Failure Mode Severity (inverted: higher = fails more gracefully)",
        "Durability"
      ],
      "axes_short": [
        "Problem Fit",
        "Maturity",
        "Time to Value",
        "Low Discipline",
        "Reversibility",
        "Tooling",
        "Governance",
        "Scale",
        "Graceful Failure",
        "Durability"
      ],
      "target": "Analytics engineering",
      "platforms": {
        "Analytics engineering": [
          4.7,
          4.8,
          4.2,
          3.4,
          3.8,
          4.8,
          4.3,
          4.4,
          4.0,
          4.6
        ],
        "Medallion architecture": [
          3.6,
          4.4,
          4.4,
          2.8,
          3.4,
          4.6,
          3.4,
          3.8,
          2.6,
          3.4
        ],
        "Metrics layer / headless BI": [
          4.4,
          3.8,
          2.8,
          3.0,
          3.6,
          3.6,
          4.5,
          4.2,
          3.8,
          4.4
        ],
        "Data contracts": [
          4.5,
          3.6,
          2.4,
          2.2,
          3.0,
          3.2,
          4.7,
          4.5,
          4.2,
          4.5
        ],
        "Lakehouse-native serving": [
          4.2,
          3.6,
          3.0,
          3.2,
          2.6,
          3.8,
          3.8,
          4.4,
          3.4,
          4.7
        ],
        "Data mesh": [
          3.4,
          3.4,
          1.8,
          1.6,
          2.2,
          3.0,
          4.0,
          4.6,
          2.2,
          3.6
        ]
      },
      "verdict": "Analytics engineering: Adopt. Metrics layer: Adopt where the pain is real. Data contracts and medallion: Trial, deliberately. Lakehouse-native serving: Assess. Data mesh: Hold for most organisations — it is an org chart wearing an architecture diagram, and it fails harder than anything else here when the org isn't already shaped for it."
    }
  }
}