Knowledge Graph

StudioGraphExploration

Beta Works · surface still evolving · Studio explorer; range histograms and index-accelerated hops still rolling out

What it is

A dedicated graph database makes you decide, up front, what your nodes and edges are, then pay to keep that model in sync forever. The Knowledge Graph explorer takes the opposite approach: it derives the graph from the tables and foreign keys you already have. Open it in Studio, choose a starting table, and that table becomes the root of a canvas. Its columns appear as nodes; a low-variety column such as country or status fans out into its distinct values; and clicking a value lets you hop into a related table, carrying your filter with you.

The key idea is that a node is a value, not a row. “Germany” is one circle standing for every German customer, so a hundred-million-row table still fits on one screen. The canvas shows the relationships between your data rather than the data itself, and the path from the root to any node behaves exactly like a WHERE clause — each step you click narrows the set of rows the next step describes.

Why it matters

Point-and-click data exploration usually means either scrolling endless result grids or hand-writing a new query for every question. The Knowledge Graph lets you navigate by meaning instead — “German customers”, “pending orders” — over your existing schema, with no separate graph store to load and no model to design first.

• No modeling, no ETL — the graph comes from your declared foreign keys, so there is nothing to build and nothing to keep in sync.
• Value-granular — you navigate by category, not by row, so an enormous table collapses onto a single, readable canvas.
• Honest counts — every number shown is exact, NULL is a first-class value, and when a fan is trimmed it says “50 of 12,043” rather than hiding the rest.
• Filter-carrying hops — jump from German customers to their orders to those orders’ statuses, and every count stays scoped to the path you walked.

flowchart LR
  classDef a fill:#1f2640,stroke:#7c5cff,color:#e8eaf0
  classDef b fill:#1f2640,stroke:#00d4ff,color:#e8eaf0
  classDef g fill:#1f2640,stroke:#4ade80,color:#4ade80

  T[customers<br/>table]:::a --> C[country<br/>column]:::b
  C --> V["Germany<br/>4.1M rows"]:::g
  V --> O["orders<br/>1.2M rows"]:::a
  O --> S[status<br/>column]:::b
  S --> P["pending<br/>during that path"]:::g

How you use it

Open the command palette (⌘P / Ctrl-P) and choose Open Knowledge Graph. Pick a root table from the toolbar and its columns appear as nodes. Click a green facet column to fan out its distinct values; click a value to see the tables it reaches, each labelled with how many of its rows are connected to your current set; then click a table to make it the new focus and keep going. A breadcrumb lets you step back up the path at any time. For a column whose variety is unknown, the Measure button computes its exact distinct count on demand.

Everything the canvas draws corresponds to a query you could have written by hand. A path of “customers, filtered to Germany, hopped to their orders, grouped by status” is exactly this:

-- What the drill-down "German customers -> their orders -> status" represents.
-- Counts are exact and de-duplicated so a fan-out never over-counts.
SELECT o.status, COUNT(DISTINCT o.id) AS orders
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE c.country = 'DE'
GROUP BY o.status
ORDER BY orders DESC;

You never write that query — clicking the nodes builds it for you — but it is the exact meaning of the path, which is why the numbers on the canvas always line up with what a report would show.

Column kinds

When you expand a table, each column is classified by how it should be explored — the type of the column is not the signal, its variety is. A five-value integer like rating is a great facet; a text column with a million distinct values is a search box, not a fan of circles.

Kind	How it behaves
Facet	Few distinct values — fans out into clickable value nodes.
Distribution	Many ordered values — summarised as ranges rather than one node each.
Portal	A key column — leads to another table rather than fanning out.
Search	Too many distinct values to draw — you search instead of browse.
Measure	A metric — belongs on the relationship, not as a value node.
Unclassified	Variety not yet known — press Measure to find its distinct count.

The Schema Graph

Alongside the Knowledge Graph, Studio offers a Schema Graph (command palette → Open Schema Graph). Where the Knowledge Graph is a drill-down into rows and values, the Schema Graph is a bird’s-eye map of your tables and foreign keys — pick a table, set a depth, and see how it connects to the rest of the database. Use the Schema Graph to learn a schema’s shape, and the Knowledge Graph to explore the data inside it.

Notes & caveats

Tip

A table-to-table hop appears only where a foreign key is declared between the tables, and the table you hop into needs a single-column primary key so its rows can be counted exactly. Declaring your keys makes the graph richer.

Tip

Low-variety columns — status, country, rating, tier — are the ones that fan out into values. High-variety columns like id or email offer search instead, so a single click can never paint a million circles onto the canvas.

Heads up

The Knowledge Graph is an evolving Studio exploration surface. Range histograms for high-variety columns and index-accelerated hops for very large relationships are still being rolled out; today it is at its best when you drill into a filtered subset rather than fanning out an unfiltered, billion-row table in a single step.

Graph-Relational Duality →

Declare tables as nodes and edges and query them with SQL and property-graph MATCH.

Graph Index →

Turn a selective relationship join into a direct lookup that scans neither table.

Aether Studio →

The web IDE where the Knowledge Graph and Schema Graph live.

Query Your Data →

The standard SQL surface over the same tables.