D2 now allows you to create architecture diagrams with TALA locally, save code in Git, and compare three engines without rewriting the file.
What Changed in D2 v0.9.0?
TALA became open source under the MPL-2.0 license and is now included in D2 v0.9.0. Previously, Terrastruct distributed it separately as a proprietary engine.
The practical change is more interesting than the license announcement: a D2 project can now use TALA locally without an additional proprietary installation. You can also render the same code with TALA, Dagre, or ELK and compare the results directly.
TALA was designed specifically for software architecture diagrams. Instead of treating each diagram as a hierarchy that flows in a single direction, it optimizes aspects like symmetry, spacing, grouping, and orthogonal connections.
What Are D2 and TALA?
D2 is a declarative language for creating diagrams: you describe the components and their relationships as text, and D2 generates the visual representation.
TALA is one of the engines that decides where each component appears. D2 includes three main options:
- Dagre, the default engine, quickly generates hierarchical or layered layouts.
- ELK is a more mature engine for directed graphs, with good support for complex hierarchies, ports, and compound graphs.
- TALA focuses on architecture diagrams with a layout similar to what an engineer would draw on a whiteboard.
This separation is important. The .d2 file describes the architecture; the selected engine determines its visual layout.
How Can You Create an Architecture Diagram with D2?
Start with a small architecture containing several groups and shared dependencies:
direction: right
client: Web client
edge: Edge {
gateway: API gateway
}
services: Services {
auth: Authentication
orders: Orders
}
data: Data {
database: PostgreSQL
cache: Redis
}
client -> edge.gateway
edge.gateway -> services.auth
edge.gateway -> services.orders
services.auth -> data.database
services.orders -> data.database
services.orders -> data.cache
Save the code as architecture.d2. After installing D2 v0.9.0 or later, verify the installed version:
d2 version
Next, render the same file with each included engine:
d2 --layout=tala architecture.d2 architecture-tala.svg
d2 --layout=dagre architecture.d2 architecture-dagre.svg
d2 --layout=elk architecture.d2 architecture-elk.svg
SVG is D2’s default output format. The CLI can also export to PNG, PDF, PPTX, GIF, and text formats, though compatibility may vary depending on the engine and format.
You can check available engines with d2 layout and engine-specific options with a command like d2 layout dagre.
What Changes When You Choose a Different Layout Engine?
The components and relationships stay the same, but the way the architecture is visually presented changes.
| Engine | Best Starting Point | Main Advantage | Main Disadvantage |
|---|---|---|---|
| TALA | Service and infrastructure architectures | Balanced and orthogonal diagrams with greater spatial control | Slower and less visually stable on large diagrams |
| Dagre | Simple request flows and dependency chains | Fast and predictable hierarchical output | Less flexibility for non-hierarchical architectures |
| ELK | Large directed graphs and nested systems | Mature handling of layers, ports, and compound graphs | Can produce a more mechanical result |
Graphviz dot |
Existing workflows with DOT and highly configurable graphs | Mature ecosystem and extensive layout controls | Requires a separate DOT file instead of D2 code |
| Mermaid | Diagrams embedded in Markdown and documentation platforms | Convenient integration with documentation and support for various diagram types | Less direct control over architecture positioning |
TALA, Dagre, and ELK offer the most direct comparison because D2 can send exactly the same diagram to all three engines.
Graphviz and Mermaid are included in the comparison for another reason: they are alternatives that many developers already use. They are not interchangeable engines within D2, so reproducing the architecture requires equivalent files in DOT and Mermaid.
Is TALA or Graphviz Better for Architecture Diagrams?
TALA is a better starting point when the spatial organization of the diagram communicates important information about the architecture.
For example, TALA lets you place one object near another, apply different directions within containers, and pin some nodes using top and left while continuing to automatically organize the others. This hybrid control is useful when automatic layout is close to the desired result, but some components need deliberate positioning.
Graphviz remains a compelling option when you already have a DOT-based workflow or need its mature collection of engines and attributes. Its dot engine works especially well with directed hierarchies: it organizes nodes by ranks, orients connections in a coherent direction, and tries to reduce crossings and line length.
So the decision is not just visual. It also depends on your source language, tools, and the degree of control you want to maintain.
When Should You Use Dagre or ELK Instead of TALA?
Use Dagre when speed and a clear top-to-bottom or left-to-right flow are more important than architectural composition. It’s a good starting point for small dependency graphs and simple pipelines.
Use ELK when the graph is large, deeply nested, or dominated by directed relationships. ELK Layered offers support for compound graphs, ports, multiple connection styles, and numerous configuration options.
Even TALA’s author recommends considering Dagre or ELK for large acyclic directed graphs. A specialized architecture engine doesn’t automatically win with all datasets that represent an architecture.
Where Does Mermaid Fit In?
Mermaid remains a practical alternative when the diagram needs to live directly within a Markdown-based documentation workflow.
It offers diagram-specific syntax for architecture based on groups, services, connections, and junction points. Mermaid can also use Dagre or ELK with various diagram types. This demonstrates why “Mermaid versus TALA” is not a pure comparison between engines: Mermaid is a language and rendering ecosystem, while TALA is an engine used by D2.
For teams already using Mermaid, migration only makes sense when D2’s code model or TALA’s architecture-oriented layout solves a specific limitation. Our earlier analysis of Mermaid architecture diagrams provides more context for making that decision.
What Are TALA’s Limitations?
TALA presents three important trade-offs.
First, it performs multiple runs with different seeds and selects the best-scoring result. The same input with the same seeds produces a deterministic result, but adding a node can generate a considerably different layout. Dagre and ELK typically better preserve previous visual structure.
Second, TALA is not the best choice for all large directional graphs. Pipelines and long chains of dependencies usually adapt better to Dagre or ELK.
Third, its execution time scales non-linearly. Large diagrams can take longer to arrange, so it’s worth testing with representative production examples and not judging it solely by a small example.These limitations are not reasons to dismiss TALA. They are reasons to keep the diagram code separate from the engine decision and compare several options before adopting one as a standard.
Should You Use D2 and TALA for Your Architecture Diagrams?
D2 with TALA deserves a try if you want to maintain your architecture diagrams as versioned code without handing all spatial control to a generic hierarchical engine.
The most robust workflow is also the simplest: describe the architecture once, render it with TALA, Dagre, and ELK, and keep the result that communicates the system most clearly. Use Graphviz and Mermaid as broader workflow comparisons, especially if DOT or Markdown integration are already important to your team.
TALA’s open source code makes this evaluation considerably easier. Now you can run the entire D2 engine stack locally, study its behavior, and keep both the source code and generated files within the same engineering workflow.