In previous Lightning 201 articles we have written about changing how our Lightning nodes database works. Currently both Eclair and C-lightning use a SQLite3 database by default to store information related to their channels. Since SQLite cannot be used as a remote database, we added support for PostgreSQL in Eclair.
The next question is; what is the performance impact of switching to a different database?
Lightning is meant to be a fast way to send bitcoin between two parties. At Suredbits we think a successful use case for Lightning will be high frequency trading in cryptocurrency. Performance matters with trading software, so we thought we would begin benchmarking Eclair to get an idea of its performance profile.
This benchmark involves 11 eclair nodes. 10 of these nodes are attempting to send 2,000 payments to one node. It is important to note that all of the nodes and their respective databases were on one machine. There is no network latency simulated in this benchmark. There are two types of network latency to be worried about with a lightning node:
- Latency between peers
- Latency between the node and the database
We expect that network level latency would dominate any “real world” payment. Database latency will not be an issue if your database is local, if it is remote you should make sure that the node and database are not too far apart geographically.
Each node only has one channel open with the destination, therefore all payments from a single node are sent across a single channel. However, each of the 10 nodes can be sending payments at the same time to the server node.
Eclair v0.3.2 no backups
Eclair v0.3.2 with backups
As you can see, there is a dramatic decrease in performance if you have backups enabled with eclair. The median payment is 4x slower, while the average payment is 4.3x slower with backups. It is unclear why performance suffers as much as it does when backups are enabled in eclair.
PostgreSQL performs slightly better than eclair with backups enabled. On average, it is 102 milliseconds faster, while the median is 71 milliseconds faster. It is important to note that during this benchmark Postgres is not being backed up or replicated. The worst case performance of PostgreSQL is 1.75 seconds which is dramatically worse than any version of SQLite.
If backups are not enabled on eclair, PostgreSQL is much slower than sqlite, which is what we expected to find. On average, PostgreSQL is 3x slower than eclair with SQLite and no backups.
While Postgres is slower than SQLite, it does give other benefits such as the ability to create multiple lightning nodes that have compatible invoices. You can read more about that here
In future blog posts, will be researching how time to process a payment is effected by
- Different locking schemes on the database
- Latency between the node and database
- Latency between lightning nodes
It takes 4 round trips on the network to fully settle a lightning transaction which means that will likely be a huge performance cost. We expect this to be the largest constant that we have to deal with when thinking about performance.
We will be researching both of these areas in further blog posts.
Get in touch with the team on Twitter:
All of our API services, for both Cryptocurrency APIs as well as Sports APIs, are built using Lightning technology and the Lightning Network. All API services are live on Bitcoin’s mainnet. Our fully customizable data service allows customers to stream as much or as little data as they wish and pay using bitcoin.
You can connect to our Lightning node at the url:
If you are a company or cryptocurrency exchange interested in learning more about how Lightning can help grow your business, contact us at [email protected].