Snowflake Software / SaaS Palo Alto, California

DataHub

IT Operations Automation · Real-time Analytics

A fragmented, self-managed observability stack forced engineers to jump between tools, left monitoring on the same infrastructure it monitored, and drove high AWS cost and incident blind spots.

$100K+ annual AWS savings
16% reduction in metrics volume in the U.S.
19% reduction in metrics volume in the EU
22 EKS and GKE clusters

Reported impact

Business outcome

DataHub eliminated over $100K in annual AWS observability cost, reduced median incident duration by about 80%, and created one searchable telemetry source that also powers AI-assisted diagnosis and reporting.

  • Cost Reduction
  • Productivity Improvement
  • Risk Reduction

Solution

DataHub replaced four self-managed observability systems with Observe by Snowflake so logs, metrics, traces, and alert context could be searched from one resilient platform. The team deployed the Observe agent across 22 EKS and GKE clusters and more than 70 isolated customer namespaces, then created separate U.S. and EU tenants through Terraform for regional data handling. Telemetry that previously lived in OpenSearch, Prometheus, Thanos, Grafana, and Alertmanager now lands in a single place where engineers can investigate incidents without switching tools or waiting for another team to build dashboards. DataHub also connected Observe’s CLI and OPAL query language to an internal AI agent in Slack, combining live telemetry with context from incident.io, Argo CD, and internal reference material. That design turns one telemetry store into both a human observability console and an AI-ready context layer for daily reports, faster diagnosis, and future automated remediation.

Data flow

Telemetry from DataHub's Kubernetes clusters is collected by the Observe agent and centralized in Observe by Snowflake. OPAL queries executed through a Slack-connected AI agent combine Observe data with incident.io and Argo CD context to answer operational questions and generate daily reports.

Solution architecture

4 components · 4 layers
  1. Ingest
    • Observe agent Collects telemetry from DataHub's Kubernetes fleet and feeds it into the shared observability platform.
  2. Storage
    • Observe by Snowflake Centralizes logs, metrics, traces, and operational context so incidents can be investigated from one platform.
  3. Serving
    • OPAL Provides the query language the internal AI agent uses to retrieve telemetry-backed answers and reports.
  4. Orchestration
    • Terraform Manages regional Observe tenant configuration and repeatable observability setup as code.

Architecture clues

  • An internal AI agent in Slack uses Observe CLI and OPAL against live telemetry.
  • Monitoring no longer runs on the same infrastructure it monitors.
  • Observe tenants are split between U.S. and EU regions for data residency.

Evidence from the source

DataHub chose Observe by Snowflake and brought its telemetry into one platform.
Engineers can ask operational questions in Slack, and the agent can generate and execute OPAL queries
The team deployed the Observe agent across its Kubernetes fleet
cut median incident duration by about 80%
retired over $100,000 a year of AWS infrastructure
Transparency Evidence & methodology 100/100 reference value · 79% confidence · 1 source

Review how this reference was scored and trace each normalized claim back to its documented source.

01

Scoring methodology

How scores are calculated

Customer Reference Value measures usefulness as a customer reference. Evidence Confidence measures the quality and traceability of available evidence, not independent verification.

Customer reference value100/100
  • Problem clarity20/20
    Measures whether the customer's operational problem is specific enough to compare.
  • Implementation depth25/25
    Rewards named components, data flow, integrations, and architecture detail.
  • Outcome specificity20/20
    Measures whether the reported benefit is concrete rather than a generic claim.
  • Quantified impact25/25
    4 metrics describe measurable impact.
  • Deployment scale10/10
    Rewards evidence of a live or scaled deployment and meaningful integration scope.
Evidence confidence79%
  • Source authority20/25
    The main evidence is an official vendor-published customer story.
  • Claim traceability21/25
    10 of 12 key fields link to a named source.
  • Direct evidence20/20
    5 direct source quotes retained.
  • Date provenance0/10
    The publication date has no documented provenance.
  • Source transparency8/10
    1 source reference document publisher, URL, authority, retrieval, and supported fields.
  • Implementation specificity10/10
    Rewards source-backed components, data flow, quantified impact, and a specific outcome.
02

Traceability

Sources & provenance

Field coverage shows which facts each source supports. Dates are shown only when documented by the source.

  1. Snowflake

    DataHub customer story

    First-party
    https://www.snowflake.com/en/customers/all-customers/case-study/datahub/
    Source type
    Vendor-published customer story
    Supports
    • Customer
    • Business problem
    • Solution
    • Products
    • Solution components
    • Data flow
    • Integrations
    • technical area
    • use case category
    • Business outcome
    • outcome category
    • Metrics
    • Architecture
    • evidence quotes

Date evidence

  • Sitemap last modified Oct 9, 2026 · Snowflake · Publisher metadata Publisher-reported modification timestamp; not a publication date.
    Open date source
  • Unverified extracted date Oct 9, 2026 · Snowflake · Unknown Legacy extracted date without source-page confirmation.
    Open date source
Not separately sourced Industry, Region, Company size. Treat these normalized attributes as lower-confidence until a dedicated source is added.