Read the discussion on HN. A full-thread summary is not available yet.
meta
rocksdb
C++2013–2026
meta / rocksdb
rocksdb
A library that provides an embeddable, persistent key-value store for fast storage.
52Distinct people
58Mentions
0Explicit recommenders
32.3KGitHub stars
What to know before exploring
What it is
A library that provides an embeddable, persistent key-value store for fast storage.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 5:03:38 AM UTC.
Mentions over time
HN mentions by year58 dated mentions
Observed mentions: 2013-11-15 00:22:02 UTC to 2026-06-18 20:03:50 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 6 | 2 | 4 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 0 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
RocksDB: A Persistent Key-Value Store for Flash and RAM Storage
RocksDB is developed and maintained by Facebook Database Engineering Team.
It is built on earlier work on LevelDB by Sanjay Ghemawat (sanjay@google.com)
and Jeff Dean (jeff@google.com)
This code is a library that forms the core building block for a fast
key-value server, especially suited for storing data on flash drives.
It has a Log-Structured-Merge-Database (LSM) design with flexible tradeoffs
between Write-Amplification-Factor (WAF), Read-Amplification-Factor (RAF)
and Space-Amplification-Factor (SAF). It has multi-threaded compactions,
making it especially suitable for storing multiple terabytes of data in a
single database.
Start with example usage here: https://github.com/meta/rocksdb/tree/main/examples
See the github wiki for more explanation.
The public interface is in include/. Callers should not include or
rely on the details of any other header files in this package. Those
internal APIs may be changed without warning.
Questions and discussions are welcome on the RocksDB Developers Public Facebook group and email list on Google Groups.
License
RocksDB is dual-licensed under both the GPLv2 (found in the COPYING file in the root directory) and Apache 2.0 License (found in the LICENSE.Apache file in the root directory). You may select, at your option, one of the above-listed licenses.
Read the full README on GitHubWhat Hacker News says
10 sourcesNote that RocksDB is also dual licensed under Apache 2.0 and GPLv2 [1]. I believe they added GPLv2 to make it compatible with MySQL for MyRocks, because the original Facebook+Patents license might not have been GPL compatible. Then when the Apache Foundation decided that Facebook+Patents wasn't compatible they switched it out for Apache 2.0 [2].
But that doesn't clarify much. Specifically your question about dependency licensing. RocksDB only depends on gflags (BSD licensed) and various compression library choices (allowing a choice of licenses). osquery seems to depend on a lot more libraries [3], so the likelihood of running into a licensing conflict seems a lot higher.
[1] https://github.com/facebook/rocksdb/blob/master/db/db_impl.c...
[2] https://meshedinsights.com/2017/07/16/apache-bans-facebooks-...
[3] https://github.com/facebook/o
Read the rest
You can't do updates, but you can create tables using the AggregatingMergeTree table engine.
I've been working out how to use this for tracking count/first seen/last seen for data sets. With normal sql you need to do upserts, but with clickhouse you can just create the table using countState, minState, maxState and insert:
1, now, now
for count, first, last, and when it compacts the table it'll apply the aggregations.
Basically what you do with with https://github.com/facebook/rocksdb/wiki/merge-operator just with a few lines of SQL instead of a ton of custom code.
In Redshift vs. BigQuery vs. Snowflake benchmarkThey recently changed the RocksDB licence (https://github.com/facebook/rocksdb/commit/3c327ac)
This reopenned the discussion about React licensing (https://github.com/facebook/react/issues/10191) so maybe this will change soon.
In Things to learn in React before using ReduxRocksDB license changed to dual Apache2 and GPLv2
3 points · Open discussion(I meant that a bit rhetorically, sorry)
Definitely not :). In fact, all the LevelDB copyright notices now point to a dangling LICENSE file:
> // Copyright (c) 2011 The LevelDB Authors. All rights reserved.
> // Use of this source code is governed by a BSD-style license that can be
> // found in the LICENSE file. See the AUTHORS file for names of contributors.
CONTRIBUTING (https://github.com/facebook/rocksdb/blob/master/CONTRIBUTING...) presumably needs updating as well to cover the variations (including the GPLv2 addition that happened a few months ago apparently).
In Facebook relicenses RocksDB under Apache 2 licenseAmusingly, the commit removes the LICENSE file which had the original LevelDb (from Google) copyright and LICENSE notice:
https://github.com/facebook/rocksdb/commit/3c327ac2d0fd50bbd...
Did RocksDB finally remove every last piece of code from LevelDB?
Disclosure: I work at Google, but IANAL.
In Facebook relicenses RocksDB under Apache 2 licenseRocksDB has fixed this https://github.com/facebook/rocksdb/commit/3c327ac2d0fd50bbd... now and moved to Apache / GPL dual license.
In Apache Foundation disallows use of the Facebook “BSD+Patent” licenseFacebook relicensed RocksDB to dual Apache and GPLv2 3 hours ago: https://github.com/facebook/rocksdb/pull/2589
In Apache Foundation disallows use of the Facebook “BSD+Patent” licenseWell, there is already a lot of thought that goes into LSM trees on flash storage - check out RocksDB [0] for example, which goes to great lengths to allow the user to deal with Read / Write amplification, a problem specific to flash storage. So I don't think that more SSD adoption will fundamentally change anything.
The tradeoff from LSM tree to B-tree, very generally speaking, is more about access patterns: LSM trees lend themselves to insert-heavy workloads because the structure is conceptually just a big array that you very quickly append stuff to the end of without checking the rest of the array. That's the magic of why it's so fast for insertions - there's no overhead. You just ignore the older key/values. When doing a read, you read backwards from the end, reading only the newest values. When you fill your memory budget, you flush
Read the rest
your array to a lower layer, removing the duplicate old values. I encourage everyone to read the paper - it's not that arcane, just skip the difficult bits [1]. (nb: the original uses trees at each layer, but people have moved away from that for various reasons of changing hardware, scale, use cases)
Another point is that oftentimes these data structures span storage layers (or the "cache hierarchy" as database systems people like calling it) - e.g. you could have an LSM tree that has a top layer fitting in L3, then a bunch more in memory, then the majority of it spilling over to disk. Another example is the Bw-Tree [2], which introduces a mapping table that is a storage-agnostic lookup table that tells you wherever a record is, disk or memory or otherwise, and is smart about paging stuff in and out of memory based on hotness. So is this really one "data structure"? Is it a combo of many? Could we change each layer based on the storage type? It gets confusing.
When you squint, a lot of data structures start looking like each other, except for certain details that form the fundamental characteristics. Figure 4 in the Monkey paper [3] is one of my favourite figures ever - their observation is that there is a tradeoff continuum of read and lookup costs, and on one end of that continuum is logs (very easy to append to, hard to find things without searching the whole thing), the other end is a sorted array (very easy to find things with binary search, very hard to append to). This is already pretty cool, but then in the middle are tiered and layered LSM trees. And you can actually tweak the level of tiering and layering to reap the benefits of that tradeoff. Then when you start thinking about how big you want your layers to be, how you want to connect them, etc, you eventually arrive to binary trees, btrees, etc. It's sort of magical how related all the storage structures are.
[0] https://github.com/facebook/rocksdb/wiki/rocksdb-basics
[1] https://blog.acolyer.org/2014/11/26/the-log-structured-merge...
[2] https://pdfs.semanticscholar.org/7655/9c6cc259c6ab5baf7bd19d...
[3] https://stratos.seas.harvard.edu/files/stratos/files/monkeyk...
I've found the google/leveldb[1] source code to be immensely educational, authored by Jeff Dean and Sanjay Ghemawat. A relatively tiny codebase at that, used virtually everywhere and the basis for facebook/rocksdb[2].
[1]: https://github.com/google/leveldb
[2]: https://github.com/facebook/rocksdb
In Ask HN: What are some examples of good code?