Client node pruning deletes data from the relational database.


Data pruning is irreversible. After the data is pruned from the Client nodes, the data is no longer available. As a best practice, back up the Client nodes before you initiate a pruning process.



  1. Identify the current ledger offset.
    image=$(docker images --format "{{.Repository}}:{{.Tag}}" | grep "daml-ledger-api");docker run -v /config/daml-ledger-api/environment-vars:/config/daml-ledger-api/environment-vars --network blockchain-fabric $image -- --dump-index-metadata | grep WARN | cut -d "|" -f 10 | cut -d "(" -f 1 | grep "ledger_end:" | cut -d ":" -f 2

    You can set up a cron job to query the current offset using the command and record the output. Schedule the cron job to run daily or at a designated interval.

    Record the ledger offset output, time, and results so that you can specify up to what time you can prune.


    You cannot query for the past events that happened on the ledger offset.

    The ledger offset output has 32 digits with leading and trailing zeros, such as 00000000000074180000000000000000.

  2. Initiate the pruning operation using gRPC and define the recorded offset as a prune_up_to parameter.
    grpcurl -plaintext -d '{"prune_up_to": "<offset>"}' <ClientIP>:<ClientPort> com.daml.ledger.api.v1.admin.ParticipantPruningService.Prune

    The pruning operation starts from the oldest smart contracts and stops at the provided offset time. You can optionally set an identifier submission_id used for logging.

    When the prune request ends successfully, the command returns an empty response.

  3. If the pruning operation fails, fix the error and rerun the pruning operation.

    You might see one of the following error messages:

    • INVALID_ARGUMENT- the Client node payload, specifically the offset, is faulty or missing.

    • UNIMPLEMENTED- the Client node is based on a ledger that has not implemented pruning.

    • INTERNAL- the Client node encountered a failure and might have partially implemented pruning.

  4. (Optional) Compress the indexDB to reclaim storage space for reuse.
    docker exec daml_index_db psql -d daml_ledger_api -U indexdb -c "VACUUM"
  5. (Optional) Verify the indexDB disk size after compression.
     du -s /mnt/data/db/base

    The current indexDB disk size value should be less than the value before pruning.

  6. (Optional) Check that the daml_index_db PostgreSQL metrics statistics from the pg_stat_database table is pruned.
    docker exec daml_index_db psql -d daml_ledger_api -U indexdb -c "SELECT * FROM pg_stat_database WHERE datname in ('indexdb', 'daml_ledger_api');"

    The metrics statistics might span multiple tables. The tup_deleted value shows an increase in pruning activity.


When the pruning process is successful, you can see the following changes in the system:

  • IndexDB disk size decreases after the PostgresSQL vacuum command was used.

  • Active smart contracts are not affected regardless of their age.

  • PostgreSQL metrics, especially the tup_deleted column value in pg_stat_database, indicate that the DAML archived smart contracts and transaction records were deleted from the daml_ledger_api.