Seeing the schema: TypeDB's approach to graph visualization

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

Click any type to see its connections. Size nodes by connectivity to surface domain hubs. This facilitates deep and intuitive exploration of your TypeDB data model.

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)

This isn’t arbitrary styling – it maps directly to your schema. When you see a diamond node with five connections, that’s an actual n-ary relation with five roleplayers. Not an intermediate node you created to work around binary-edge constraints. 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. Technically possible, but:

• 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.

TypeDB’s visualizer does both by using type-based navigation.

Overview with connectivity sizing:

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.

This isn’t degree centrality of individual nodes – it’s semantic importance of types. The large nodes in the center aren’t highly-connected individuals, they’re relation types that organize your domain. 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 have made deliberate tradeoffs. Binary edges are simpler to implement and reason about. Flat labels are more flexible than inheritance hierarchies. These are valid engineering decisions for certain domains.

But they constrain what visualization can show. Here’s the concrete difference:

N-ary relations: In a property graph, relations are edges between two nodes. When you need to model a relationship with more than two participants, you create an intermediate node representing the relationship, then connect it to participants with edges. All of these are workarounds. Instance visualizers show the workaround – extra nodes, multiple edges – not the semantic fact you’re modeling.

TypeDB relations can connect arbitrary numbers of participants in explicitly defined roles. An employment relation connects an employee (a person), an employer (a company), plus owns attributes: start-date, end-date, job-description. This renders as a single diamond node with labeled edges to each participant. The roles are explicit: “employee”, “employer”, not generic “connected to”.

When you model a meeting with ten participants, each in different roles (organizer, required attendee, optional attendee, note-taker), the relation node connects all ten with role-labeled edges. Property graphs would force you to create an intermediate “meeting” node and ten binary edges, losing the role distinctions in the process or encoding them as edge properties that visualization tools can’t natively leverage.

Type hierarchy: Property graph labels are flat tags. A node can have multiple labels, but there’s no inheritance. TypeDB has proper subtyping – an employee is a subtype of person. The visualizer can style type hierarchies, filter by supertypes, and show polymorphic structure that property graphs can’t express at the schema level.

Entities vs relations vs attributes: When your database doesn’t distinguish between “node representing an entity” and “node representing a workaround for an n-ary relationship”, the visualizer can’t either. TypeDB’s type system makes these distinctions explicit, so the visualizer can render them accurately.

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.

(For pure data instance exploration – browsing all employees, traversing connection paths without queries – TypeDB has the Data Explorer with nested table views. The graph visualizer focuses on understanding and navigating your domain model.)

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

Try it on a schema with n-ary relations and see the difference. Employment with employee/employer/role. Transactions with buyer/seller/item/price. Meetings with multiple participants in different roles. You’re not reverse-engineering your schema from a graph – you’re looking at it directly.