<p>The compaction is only relevant for <a href="https://github.com/etcd-io/bbolt" rel="nofollow noreferrer">bbolt</a> database files, which are very common with lnd. In this case, the channel database is stored as a bbolt file named <code>channel.db</code>. Note that you can also use PostgreSQL with lnd to persist this information, in which case you don't need compaction (PostgreSQL has a concept named &quot;vacuum&quot; which can run in the background).</p>
<p>During operation of lnd changes (especially deletions) to the bbolt database cause gaps in the database file, which cannot easily be filled with new data. As such, after a while, the database file consumes lots of disk space, even though a fraction of it is just empty space inside the file. Deduplication/compression features of your filesystem might help to reduce the actual storage footprint.</p>
<p>When you trigger the compaction, a new database file is created and filled with the data from the original file by copying everything over. This way the actual information is identical, but gaps in the original file are skipped and do not consume space in the resulting file. This is somewhat similar to file system defragmentation from the Windows 9x (and before) era.</p>
<p>This compaction does not change (or interpret) the data in any way, i.e. no data is compressed or deleted. Every information persisted in the original database is copied over to the new database, bit by bit. The only difference is that the internal database structure changes, which you do not see from the outside (aside from the intended benefit of reducing the storage footprint of the file).</p>
<p>As compaction is bbolt specific, I don't think other implementations make use of this. In general all databases should already have some means of freeing up space of deleted data, and I guess that all node implementations delete most unnecessary information after a while.</p>

CC BY-SA 4.0
2024-08-30T14:12:45.100Z
How does the compacting algorithm work? On my node, during compacting a 60G channel.db, a file temp-dont-use.db is created. Its size grows up to 20G and then drops to about 0-1G. Then the process continues several times. If it was just defragmentation, a single linear scan should have been sufficient.
Tasos Sidiropoulos
CC BY-SA 4.0
2024-08-30T16:50:37.660Z
That's part of my answer already.
C-Otto
CC BY-SA 4.0
2022-12-01T09:35:44.993Z
2022-12-01T09:40:49.343Z
2022-12-01T09:40:49.343Z
C-Otto
<p>As lightning network channels route payments, channel updates require the 2 channel peers (Alice &amp; Bob) to do a round of signing and trade commitment transactions for the most up-to-date channel balance.</p>
<p>Is this the primary reason that <a href="https://bitcoin.stackexchange.com/questions/110331/why-is-lnds-channel-db-so-huge-and-when-will-it-stop-growing">the channel.db file may grow so dramatically</a>?</p>
<p>For each update, Alice must keep a full record of all revocation keys from all past commitment transactions in case Bob broadcasts an invalid past channel state. If these keys are deleted, Alice would not be able to create &amp; broadcast the correct penalty transaction to punish Bob.</p>
<p>Database compaction is typically run on startup of the node, but what exactly is involved in that compaction? Are the revocation keys being indexed / compressed in some lossless/recoverable fashion?</p>
<p>Do other implementations than LND have the same process?</p>

<lightning-network-daemon><database><hash-time-locked-contract><channels>
What is involved in the "database compaction" of a LND node?
oz21m
# What is involved in the "database compaction" of a LND node?

(Asked by: username_0 on 2022-11-16)

As lightning network channels route payments, channel updates require the 2 channel peers (Alice & Bob) to do a round of signing and trade commitment transactions for the most up-to-date channel balance.

Is this the primary reason that [the channel.db file may grow so dramatically](https://bitcoin.stackexchange.com/questions/110331/why-is-lnds-channel-db-so-huge-and-when-will-it-stop-growing)?

For each update, Alice must keep a full record of all revocation keys from all past commitment transactions in case Bob broadcasts an invalid past channel state. If these keys are deleted, Alice would not be able to create & broadcast the correct penalty transaction to punish Bob.

Database compaction is typically run on startup of the node, but what exactly is involved in that compaction? Are the revocation keys being indexed / compressed in some lossless/recoverable fashion?

Do other implementations than LND have the same process?

**Tags:** lightning-network-daemon, database, hash-time-locked-contract, channels


---

## 1 answers

### Answer by username_1 on 2022-12-01. Score: 4 | Accepted answer

The compaction is only relevant for [bbolt](https://github.com/etcd-io/bbolt) database files, which are very common with lnd. In this case, the channel database is stored as a bbolt file named `channel.db`. Note that you can also use PostgreSQL with lnd to persist this information, in which case you don't need compaction (PostgreSQL has a concept named "vacuum" which can run in the background).

During operation of lnd changes (especially deletions) to the bbolt database cause gaps in the database file, which cannot easily be filled with new data. As such, after a while, the database file consumes lots of disk space, even though a fraction of it is just empty space inside the file. Deduplication/compression features of your filesystem might help to reduce the actual storage footprint.

When you trigger the compaction, a new database file is created and filled with the data from the original file by copying everything over. This way the actual information is identical, but gaps in the original file are skipped and do not consume space in the resulting file. This is somewhat similar to file system defragmentation from the Windows 9x (and before) era.

This compaction does not change (or interpret) the data in any way, i.e. no data is compressed or deleted. Every information persisted in the original database is copied over to the new database, bit by bit. The only difference is that the internal database structure changes, which you do not see from the outside (aside from the intended benefit of reducing the storage footprint of the file).

As compaction is bbolt specific, I don't think other implementations make use of this. In general all databases should already have some means of freeing up space of deleted data, and I guess that all node implementations delete most unnecessary information after a while.

> **Comments:**
> **username_2**: How does the compacting algorithm work? On my node, during compacting a 60G channel.db, a file temp-dont-use.db is created. Its size grows up to 20G and then drops to about 0-1G. Then the process continues several times. If it was just defragmentation, a single linear scan should have been sufficient.  
> **username_1**: That's part of my answer already.  

---

