> 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/technical-documentation-canton/performance-and-scalability-approach.md). # Performance and Scalability Approach ## 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 (a feature currently available in early access with manual configuration). 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 a 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 servers to further boost throughput. This approach allows new compute servers with additional Canton nodes to be added as needed, enabling the system to scale 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 can be sharded across them (currently in early access). This follows the standard load-balancing approach where the client application distributes workloads via sharding. ## Node Scaling Database-backed drivers such as Postgres and Oracle can operate in an active-active configuration, enabling parallel processing with multiple writer and reader processes. This allows nodes to scale horizontally. Enterprise participant nodes also process transactions in parallel, with the exception of conflict detection, which must remain sequential by design. In contrast, the community edition processes all transactions sequentially. Canton leverages multiple CPUs automatically, detecting the number of available cores, while 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 - whether a database or a distributed ledger - critical to system scalability. Properly sizing and tuning the database is therefore essential for achieving the desired performance. Additionally, 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 & Performance Note that your Postgres database setup requires appropriate tuning to achieve the desired performance. Canton is database-heavy. Ultimately, every use case is different and the exact resource requirements cannot be predicted, but have to be measured. To achieve optimal performance we ensure the database is properly sized. The rule of thumb is: * 1 db core per 1 participant core. * 1 participant core for 30-100 ledger events per second (depends on the complexity of the commands). The memory requirements depend on the data retention period and the size of the data.. Database monitoring includes index cache hit/miss ratio. If your instance needs to keep on loading indexes from the disk, performance suffers. It might make sense to start with 128GB, run a long-running scale & 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: ``` GET https://docs.catalyx.solutions/catalyx-blockchain-manager/canton-network/version-2.0/technical-documentation-canton/performance-and-scalability-approach.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.