> For the complete documentation index, see [llms.txt](https://docs.catalyx.solutions/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.catalyx.solutions/catalyx-blockchain-manager/canton-network/version-2.0/architecture/performance-and-scalability.md).

# Performance & Scalability

## Network scaling

A Canton deployment can be scaled in several complementary ways.

When a single participant node hosts many parties, throughput can be improved by migrating parties to additional participant nodes. For instance, if 100 parties are transacting with each other, they can be distributed across 10 participant nodes with 10 parties each, or even across 100 nodes with a single party each.

Since most computation happens on the participants, a sync domain can handle significant load from multiple participants. If the sync domain itself becomes a bottleneck, its core components — the sequencer, topology manager, and mediator — can be separated onto dedicated compute to further increase throughput. New compute with additional Canton nodes can be added as needed, so the system scales horizontally.

For even greater throughput, Canton's multi–sync domain capability can be used. In large, active networks where a sync domain reaches its capacity limit, additional sync domains can be deployed and workflows sharded across them. This follows the standard load-balancing approach, where the client application distributes workload by sharding.

{% hint style="info" %}
Party migration between participants and multi–sync domain sharding are Canton protocol features. Check the [Canton documentation](https://docs.canton.network/) for the availability and maturity of each in the protocol version you run.
{% endhint %}

## Node scaling

Database-backed drivers such as PostgreSQL can operate in an active-active configuration, enabling parallel processing with multiple writer and reader processes, so nodes scale horizontally.

Enterprise participant nodes process transactions in parallel, with the exception of conflict detection, which must remain sequential by design. Canton uses multiple CPUs automatically, detecting the number of available cores; the level of parallelism can be tuned through the JVM property `scala.concurrent.context.numThreads`.

Performance of Canton nodes is generally constrained by storage I/O, making the throughput of the underlying storage layer critical to system scalability. Properly sizing and tuning the database is therefore essential for achieving the desired performance.

Daml interpretation is a pure operation without side effects, meaning each transaction can be interpreted in parallel, with only conflict detection requiring sequential execution.

***

## Database sizing and performance

Canton is database-heavy, and your PostgreSQL setup requires appropriate tuning to achieve the desired performance. Every use case is different: exact resource requirements cannot be predicted and have to be measured.

As a rule of thumb:

* **1 database core per 1 participant core.**
* **1 participant core per 30–100 ledger events per second**, depending on the complexity of the commands.

Memory requirements depend on the data retention period and the size of the data. Database monitoring should include the index cache hit/miss ratio — if the instance keeps loading indexes from disk, performance suffers. A reasonable approach is to start with 128 GB, run a long-running scale and performance test, and [monitor the cache hit/miss ratio](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STATIO-ALL-INDEXES-VIEW).

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.catalyx.solutions/catalyx-blockchain-manager/canton-network/version-2.0/architecture/performance-and-scalability.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.