-
Notifications
You must be signed in to change notification settings - Fork 368
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor CometBFT to use a single underlying database #1039
Labels
P:storage-optimization
Priority: Give operators greater control over storage and storage optimization
Comments
5 tasks
jmalicevic
added
the
P:storage-optimization
Priority: Give operators greater control over storage and storage optimization
label
Jun 27, 2023
Duplicate of #48 ? |
@melekes the benchmarks are imo really important to understand. |
Also, would you want something like this? |
This was referenced Jan 27, 2024
Anyhow if we are doing this it makes most sense, imo, to just do it.... |
melekes
added a commit
that referenced
this issue
Apr 15, 2024
until we have settled on a single database - #1039. Note I still think RocksDB is faster even thought I don't have data to back it up. Anyway, I don't think we should "endorse" any database in the meantime. Refs #2786 (comment)
github-merge-queue bot
pushed a commit
that referenced
this issue
Apr 15, 2024
until we have settled on a single database - #1039. Note I still think RocksDB is faster even thought I don't have data to back it up. Anyway, I don't think we should "endorse" any database in the meantime. Refs #2786 (comment)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
P:storage-optimization
Priority: Give operators greater control over storage and storage optimization
Based on the analysis done in #64 and discussion with users in #68, we remove cometbft-db and refactor CometBFT to use only one database backend.
DoD:
The text was updated successfully, but these errors were encountered: