Coinbase Prime, the cryptocurrency exchange’s institutional custody and trading platform, launched its Data Quality Observability Platform (DQOP) in Q1 2025 to externalize data quality checks and assign clear ownership for failures. The platform embeds into the company’s internal data catalog, allowing any team member to declare expectations for datasets and route failures to accountable parties, addressing a longstanding problem where thousands of quality checks existed but remained scattered across pipeline code with no visibility or enforcement mechanism.
- Launch Date: Q1 2025
- Key Problem Solved: Data quality checks buried in pipeline code with no accountability or centralized visibility
- Integration Targets: Snowflake and Databricks data warehouses
- Alert Routing: Slack, PagerDuty, and internal metrics pipeline
Before DQOP, Coinbase‘s Data Platform team faced a core infrastructure challenge: while checks had prevented material financial losses, incidents continued because failures had little to do with detection and everything to do with ownership and visibility. Checks lived wherever teams wrote them; consuming teams could not see what upstream validations existed, only producing teams could add new checks, and failing checks had no assigned owner or consequence. This created a perverse incentive: teams added checks only after incidents, making coverage a map of past failures rather than current risk.
DQOP operates as a control plane rather than a new execution engine, delegating query runs to existing systems including Snowflake, Databricks, and the company’s Query Builder Service. The platform separates checks from contracts; anyone can add a check that generates notifications, but a contract requires an SLA, an assigned owner, and a paging policy. This distinction prevents coverage from growing into an alert fatigue problem. The system distinguishes between three failure types: configuration errors route to check authors, system errors page the platform team, and data failures alone alert the business owner. A broken check that cannot run is excluded from pass rates, preventing bad data quality scores from masking platform problems.
The platform uses two configurations per check: a profiling config specifying what to measure via SQL and dimensions, and a ThirdEye config defining thresholds and expectations. Metrics persist in Postgres, allowing new checks to compare against historical values without expensive warehouse rescans. Table quality checks validate data at rest for freshness, volume, and completeness; event quality checks invert the model, allowing consumers to declare field-level expectations that compile into a single query. Coinbase is moving toward AI-assisted authoring, where users describe data concerns, and the platform proposes checks justified by ninety days of profiling history.
