How to enhance performance on my ledger ?
Last updated: April 23, 2025
Performance Limiting Factors
To achieve high performances, there is some architecture aspects to lookout
ledger architecture itself Single ledger vs multi-ledger will have a strong impact.
Chart of account - bottleneck can happen on high nb of transactions from same source account
Database configuration and resources
For better performances, ledger should be carefully upgraded to v2.2.
The Ledger will need to go through all the minor versions to execute the migrations. Therefore, if you are migrating from a 1.1 it will need to be upgraded in this order: v1.10.14 => v2.0.24 => v2.1.5 => v2.2.x.
Bulk for large import
When creating a large number of transaction, endpoint _bulk shall be considered. Transaction creation is optimized, large script file can be streamed too via this endpoint, and parallelization can be set.
Set of features
Each usage of the ledger service, is different. Some usage involve a high write throughput, some other involve high read throughput, custom aggregation etc...
So, each ledger can be configured with a set of features. By default, when creating a ledger, all features are enabled. See possible configurations and meaning of each feature.
Further information can be found Ledger repository here
Current set of feature is not stable, some can be added, or removed.
Name | Default value | Possible configuration | Description |
ACCOUNT_METADATA_HISTORY | SYNC | SYNC | DISABLED | Historize metadata changes on accounts |
TRANSACTION_METADATA_HISTORY | SYNC | SYNC | DISABLED | Historize metadata changes on transactions |
HASH_LOGS | SYNC | SYNC | DISABLED | |
INDEX_ADDRESS_SEGMENTS | ON | ON | OFF | Index accounts addresses segments |
INDEX_TRANSACTION_ACCOUNTS | ON | ON | OFF | Index transactions accounts set |
MOVES_HISTORY | ON | ON | OFF | |
MOVES_HISTORY_POST_COMMIT_EFFECTIVE_VOLUMES | SYNC | SYNC | DISABLED | Compute and maintains post commit effective volumes |
Database Considerations
The Ledger's performance is directly tied to PostgreSQL performance in a linear way. Both AWS RDS and Aurora are supported, with Aurora being used in our hosted solution.
this also means that PostgreSQL needs to be optimized to get the most out of its performance — the more CPU you add, the faster it will go
Performance test
Note: Actual performance may vary based on your specific implementation, chart of accounts, and infrastructure configuration. We recommend running performance tests using our test suite available at GitHub Performance Tests to determine the optimal configuration for your use case.