Why we built cortex as a graph, not a warehouse

Relational databases are great at answering the questions you already know how to ask. The problem is that real business data is messier than rows and columns. A customer is connected to an account, a subscription tier, a support history, a usage pattern, and a sales rep. None of those relationships sit cleanly in a table, and forcing them to creates a model that breaks the moment someone asks a question that crosses more than two of those boundaries.

Why we chose a graph

When we started designing Cortex, we made the deliberate choice to model data as a graph from day one. That meant giving up some of the familiarity and tooling that comes with relational systems. Query planners, ORM support, and a decades-deep ecosystem of adjacent tooling are all easier to reach for in a relational world. Building on a graph required us to make more decisions ourselves, earlier, with less prior art to lean on.

What it unlocks

Every query that runs on top of Cortex can traverse relationships that were never explicitly defined by the person asking the question. A natural language query about churn risk can pull in support ticket frequency, login patterns, billing changes, and account age without any of those connections being pre-joined or pre-modeled. The graph finds them. That is the core bet we made, and two years in, it is the reason Ask works the way it does.