Seeing the schema: TypeDB's approach to graph visualization

TypeDB’s new visualizer lets you view and explore your schema. Entities, relations, and attributes have distinct shapes, and every type can have custom styling.

Typically graph visualizers show data instances. This is the specific data within your database and how it is connected.

TypeDB’s visualizer shows your schema – the type system that defines your domain. What entity types exist? What relation types connect them? How does your model organize? When you click employment, you’re not seeing John’s job – you’re seeing how employment relations are structured across your entire domain, what roles they define, what types they connect.

Property graphs made deliberate tradeoffs. Binary edges are simpler to implement and reason about. Flat labels are more flexible than inheritance hierarchies. For many domains, these work well, but for complex domains with frequent n-ary relationships and deep type hierarchies, the modeling workarounds accumulate – and they often show up in visualization.

TypeDB has first-class n-ary relations and a type system that distinguishes entities, relations, and attributes. The schema visualizer leverages this structure.

Visual grammar from the type system

In property graphs, everything is fundamentally a node or an edge. You can add labels and color them, but the visualization is decorating a uniform structure. Nodes are circles, edges are lines, hierarchy is whatever the force-directed layout decides.

TypeDB distinguishes entities, relations, and attributes at the type-system level. The visualizer uses this:

• Entities render as rounded rectangles (people, companies, places)
• Relations render as diamonds (employment, following, marriage)
• Attributes render as ovals (usernames, dates, descriptions)

The visualization shows your data model’s structure without artifacts.

Property graphs can approximate this by creating nodes that represent relations, then connecting them with edges. Property graphs model this through conventional patterns:

• It’s a modeling pattern, not a primitive – the database doesn’t enforce it
• Queries have to know about the pattern – you write different code for binary vs n-ary relationships
• The visualization shows nodes and edges, not “this semantically represents a relation”

In TypeDB, relations are primitives. The database enforces role constraints. The visualizer renders them distinctly because the type system knows what they are.

Type inheritance enables semantic styling

Property graph labels are flat tags. A node can have multiple labels (:Person :Employee), but there’s no inheritance. You can’t define “Employee is a subtype of Person” and have the database enforce it or let you query polymorphically.

TypeDB has proper subtyping with single inheritance. An employee entity is a subtype of person. Queries against person automatically include employees. Queries against social-relation include friendship, following, and marriage.

The visualizer exploits this. You can:

• Style entire type hierarchies with related colors
• Filter to show all subtypes of a relation at once
• Collapse or expand type families based on what you’re exploring

When you have dozens of relation types in your schema, inheritance lets you organize them visually. All location-based relations use one color family. All social relations use another. The visualization reflects your domain’s semantic organization, not just individual node properties.

Exploration by semantic structure

Graph visualization has two competing goals: show overall structure (what are the important concepts), and show local detail (what’s this specific entity connected to). Most tools pick one. Force-directed layouts show structure but become unreadable hairballs. Drill-down interfaces show detail but lose the big picture. Click any type to see its connections.

Overview with connectivity sizing:

One of the new views allows you to size nodes by their type’s connectivity across the entire dataset. High-connectivity relations become visually prominent – these are your domain’s structural hubs. In a social network schema, you might see following and friendship relations as large central nodes because thousands of instances connect through them. You can see at a glance which concepts structure your data.

Local detail through click-to-explore:

Click any type and everything else fades to gray. You see just that type and its immediate connections – what roles it plays, what it relates to, what attributes it owns. No query needed. The type system gives you navigable structure.

This works because TypeDB knows the difference between entity types, relation types, and attribute types. Clicking a person entity shows you all the relation types that people participate in. Clicking an employment relation shows you the employer and employee roles, plus any attributes the relation owns (start date, job title, department).

In a property graph, you’d be clicking generic nodes and seeing generic edges. Property graph visualizers can show semantic meaning through conventions and tooling – labeling edges, coloring by property values – but it’s not native to the model. You’re decorating nodes and edges, not navigating a type system that distinguishes entities from relations from attributes.

Why this only works with strong types

Property graphs typically model complex relationships through conventions – intermediate nodes, edge properties, application-layer patterns. TypeDB enforces them structurally: n-ary relations are primitives, type inheritance is native, entities/relations/attributes are distinct at the database level.

The visualizer works because it renders structural information the database actually enforces. You’re not styling nodes based on conventions. You’re looking at the type system directly.

Layered schema navigation

The visualizer supports moving between levels of semantic detail:

Schema-level overview – see all types and how they relate. Which entity types exist? What relations connect them? What does the domain model look like?

Type-level exploration – click a type to see its neighborhood. What roles does person play? What relations involve company?

Instance-level detail – drill into specific entities and relations. Query results render with full context, showing how instances conform to the schema.

For example: you’re debugging why a specific employee isn’t appearing in a department report. In the schema view, click the employment relation type to see its structure – employee role, employer role, owns start-date and end-date attributes. Run a query for that employee’s employment instances. The results render in the visualizer showing the employment relation connected to the person, the company, and all attributes. You spot the issue immediately: the end-date is set when it should be null. Three clicks, no manual query construction.

Each level shows structure appropriate to that granularity. The schema view shows type-level connections. Query results show actual data conforming to those types. You’re not just zooming spatially – you’re navigating semantic layers.

These constraints enable visualization that shows your actual semantic model. The shapes aren’t decoration. The size-by-connectivity isn’t just a layout trick. The click-to-explore isn’t manual filtering. They work because the database knows what entities, relations, and attributes are – and the visualizer can leverage that knowledge.

For domains where relationships regularly involve more than two participants, where type hierarchies matter, where understanding the semantic model is critical – this difference shows up immediately. You’re not fighting the visualization to show your model. You’re exploring the schema the database actually enforces.

What you can do now

The new visualizer is available in TypeDB Studio. Open any database and you’ll see:

• Schema-level visualization showing all entity, relation, and attribute types
• Automatic styling based on type distinctions
• Size-by-connectivity to surface structural hubs in your domain
• Click-to-explore for any type’s neighborhood
• Full type hierarchy navigation with inheritance
• Role-labeled edges on all relations
• Customizable styling per type