Decube Raises Seed Round to Build the Data Context Platform

Three years ago I watched a $2 million pipeline failure go undetected for 72 hours because no one could answer a single question: what changed? The lineage tool showed a graph. The monitoring tool showed an alert. The data catalog showed a description last updated eight months ago. None of them talked to each other. None of them knew about the business context behind the pipeline that broke.

That was the moment Decube was conceived. Today, we are announcing our Seed Round to build what we believe should have existed from the start: a Data Context Platform that connects lineage, quality monitoring, and business glossary into a single operational view.

What We Are Building

Data observability tools have multiplied over the past four years. Most of them do one thing reasonably well - they alert you when something looks wrong. What they do not do is tell you why it went wrong, what it affects downstream, who owns the fix, and what the business impact is in terms a VP of Finance can read at 9am on a Monday.

Decube starts from a different premise. Column-level lineage is not a feature - it is the foundation. When a row count drops by 40% in your orders_daily table, the platform immediately shows you which upstream dbt model introduced a filter change, which Fivetran connector last synced three hours late, and which Snowflake schema column was renamed without a migration script. That information has to be automatic. Manual lineage documentation is always six months stale.

The Gap We Are Closing

The current tooling landscape has three categories of products that do not communicate with each other. Data catalogs (Alation, Collibra, Atlan) store metadata and business definitions. Data observability platforms (Monte Carlo, Anomalo, Bigeye) monitor freshness and volume. Data lineage tools (OpenLineage, Marquez, dbt docs) map transformation graphs. Each category is genuinely useful. Together they create three siloed datasets and three different dashboards to maintain.

Data engineers spend an estimated 30-40% of their time on incident triage - figuring out root cause, identifying who to contact, and communicating impact to stakeholders. That percentage has not decreased even as monitoring tooling has improved. It has not decreased because the tools alert faster but do not reduce the cognitive work of connecting the dots.

Why Seed Round, Why Now

We spent fourteen months building the first version of Decube with a small founding team before raising external capital. That was intentional. We needed to prove that column-level lineage could be extracted automatically from query logs without requiring instrumentation, YAML tags, or weeks of professional services work. We proved it. Decube connects to Snowflake, BigQuery, and Redshift via read-only OAuth and produces a full lineage graph within 10 minutes of authorization.

The Seed Round will fund three priorities: deepening integrations with the dbt Cloud API and Airflow metadata database, building the business glossary layer that connects technical columns to business definitions certified by non-technical owners, and expanding the quality monitoring rules engine to support statistical anomaly detection on top of threshold-based rules.

Who We Are

The founding team has direct experience with the problem. Before Decube, our engineers built data infrastructure at companies managing petabyte-scale warehouses. Our head of product spent four years as a data engineering team lead at a mid-market fintech where she personally triaged hundreds of pipeline incidents. We did not set out to build a startup. We set out to build the tool we could not find.

Jatin Solanki, CEO and Co-Founder, previously led data platform engineering at a Series C logistics company. His co-founders bring backgrounds in query optimization, data governance, and enterprise SaaS product management. The team is based in Singapore with engineers distributed across Asia and Europe.

What We Have Learned From Early Customers

Our design partners include data teams at a Series B healthcare analytics company, a mid-market e-commerce operator running Snowflake, and a fintech startup on BigQuery with 200+ dbt models. Three observations have shaped the product roadmap.

First, column-level granularity is not optional. Table-level lineage tells you which table is upstream. Column-level lineage tells you that the specific column your executive dashboard reads was transformed by a model that changed its filter logic on Tuesday. The delta between those two levels of information is the difference between a 3-minute triage and a 3-hour one.

Second, ownership assignment matters more than alerting thresholds. Teams told us the hardest part of data incidents is not detecting them - it is knowing who to wake up at 2am. Decube syncs ownership from LDAP, Okta, or CSV import and routes alerts directly to the responsible engineer. Broadcast alerts to Slack channels are ignored. Targeted pages to the right owner get resolved.

Third, business context must be written by business people. The glossary feature only works if the definitions are certified by the finance analyst who actually uses the revenue column, not written by the data engineer who built the model. Our product surfaces the column, auto-generates a draft definition from transformation logic, and routes it to the designated business owner for approval. No analyst has to know what a dbt model is.

The Road Ahead

The data stack is fragmenting further, not consolidating. New warehouses, new transformation frameworks, new orchestration tools arrive every quarter. Each one creates a new surface area for lineage gaps and a new category of quality failure mode. Our conviction is that the platform layer connecting all of them - the context layer - is more durable than any individual tool in the stack.

We are not trying to replace Snowflake, dbt, or Airflow. We are the layer that knows how they connect, which parts are healthy, and who is responsible for each piece. That problem is not going away.

If you run a data team dealing with pipeline incidents, unexplained dashboard discrepancies, or ownership confusion across a growing stack, request a demo. We built Decube for exactly that situation.