RocksDB: an embeddable LSM key-value store you link into your own process
A library that provides an embeddable, persistent key-value store for fast storage.
At a glance
- What is it?
- RocksDB is a C++ library, not a server, that stores keys and values on flash and RAM with tunable write, read and space amplification. It suits teams embedding storage in their own process and willing to own compaction tuning; it is the wrong choice if you want a database you can connect to over a socket.
- Who is it for?
- Adopt RocksDB if you are writing a C++ or C-ABI service that needs a persistent key-value store inside its own process and you can commit to tuning compaction. Do not adopt it if you need a network endpoint, SQL, or a storage layer you will never have to tune.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What RocksDB is, and the problem it removes
RocksDB is a library that provides an embeddable, persistent key-value store for fast storage. The README describes it as "the core building block for a fast key-value server, especially suited for storing data on flash drives." That phrasing matters: the project does not ship a server process, a wire protocol, or a query language. You link it into your own program and call its API in-process.
The problem it removes is the gap between an in-memory map and a full database server. If your data outgrows RAM, or must survive a restart, you either write your own log-structured storage or you run a separate database and pay for a network hop on every read. RocksDB occupies the middle: a persistent store with an LSM design that the README says offers "flexible tradeoffs between Write-Amplification-Factor (WAF), Read-Amplification-Factor (RAF) and Space-Amplification-Factor (SAF)."
Who it is for: engineers building storage engines, caches with durability requirements, or stateful services where the storage layer sits inside the same address space as the application. The README also states it has multi-threaded compactions, "making it especially suitable for storing multiple terabytes of data in a single database." That is a claim about scale, not a benchmark, and it is worth reading as a design intent rather than a measured result.
The LSM mechanism and where the three amplification factors come from
The README names the architecture directly: a Log-Structured-Merge-Database design. Writes land in a log and an in-memory structure, and are later merged into sorted files on disk. The merge step is compaction, and the README says compactions run multi-threaded.
The three amplification factors are the cost model you are actually tuning. Write amplification is bytes written to storage divided by bytes of logical data, inflated because compaction rewrites data repeatedly. Read amplification is the number of places a lookup may have to check, since a key can live in memory, in a recent file, or in an older level. Space amplification is disk used divided by logical data size, inflated by stale versions waiting to be dropped.
These pull against each other. Merging aggressively lowers read amplification and raises write amplification. Merging lazily does the reverse and leaves more space occupied. The README frames this as "flexible tradeoffs," which is accurate but understates the work: the flexibility is exposed as configuration, and choosing it is your job, not the library's.
The README is also explicit about the API boundary. "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." Treat that as a hard rule when you plan upgrades. Anything outside include/ is not a contract.
Getting a database open: build, link, and the options that decide behaviour
The README points to the examples directory (https://github.com/facebook/rocksdb/tree/main/examples) as the starting point for usage, and to the GitHub wiki for further explanation. Those two links are the documented entry path; the README itself does not inline a build command or a code sample.
What the README does pin down is the interface location. Public headers live under include/, and the options that govern WAF, RAF and SAF are exposed through that interface. The natural first file to read is the options header under include/rocksdb/, because every tradeoff described above is expressed there as a configurable field rather than as a fixed policy.
The licence files sit at known paths: COPYING holds GPLv2 and LICENSE.Apache holds Apache 2.0. The README states the project is dual-licensed and that "You may select, at your option, one of the above-listed licenses." That is a choice you make in your own distribution, not one the library makes for you.
Because the README defers build instructions to the examples directory and the wiki, the exact compile or link commands are not stated there, and I will not guess at them. Verify the build path against the examples directory for the release you pin before you plan integration work.
The tuning burden is the real adoption cost
The honest limitation of an LSM store with configurable amplification factors is that the configuration is load-bearing. A default that suits a write-heavy ingest pipeline can be poor for a read-heavy lookup service, and the same database will pass through both phases over its lifetime as data accumulates and compaction falls behind.
The README presents the tradeoff space as a feature, and it is one, but it is also an admission that the library does not pick for you. There is no single setting that is correct across workloads, and the failure mode is not a crash. It is a database that stays correct while reads slow down, or disk fills with data that has not yet been merged away, because compaction cannot keep pace with ingest.
A second constraint is the API boundary quoted earlier. Internal headers may change without warning. If your integration reaches past include/, an upgrade is a rewrite risk rather than a version bump. This is a normal tradeoff for a library at this scale, and the README is unusually direct about it, which is preferable to ambiguity.
A third point is scale-dependent. The multi-terabyte suitability the README claims comes with multi-threaded compaction, which means CPU and I/O consumed by background work inside your process. That is capacity you are not spending on request handling.
When RocksDB is the wrong tool, and what to use instead
If you want to connect to a database over a network from several languages, RocksDB is the wrong shape. It is a library. There is no port to connect to and no protocol in the README. You would be building the server yourself around the library.
For that case, the direct alternative in the same lineage is LevelDB, which the README credits as the earlier work RocksDB is built on: "It is built on earlier work on LevelDB by Sanjay Ghemawat and Jeff Dean." The difference in approach is scope. LevelDB is the smaller, simpler embedded store. RocksDB adds the multi-threaded compaction and the explicit WAF, RAF and SAF tradeoff surface that the README describes, which is what lets it target multiple terabytes in one database. If your dataset fits comfortably in memory or on one fast disk and you do not want a tuning surface, the smaller engine is the easier dependency. If you need the tuning surface because your data is large and your workload is mixed, that added surface is the reason to choose RocksDB.
If you need SQL, joins, or a query planner, neither is the right layer. An embedded key-value store gives you keys and values and nothing above them.
Licence, releases and the maintenance question
The repository is dual-licensed under GPLv2 and Apache 2.0, and the README states you may select either at your option. The practical consequence is that the Apache 2.0 path exists and is named in the README, so a team that cannot ship under GPLv2 has a stated alternative rather than a negotiation. I am not giving legal advice; your counsel should confirm which file governs your distribution and how the choice interacts with your own licensing.
The release cadence visible in the repository is frequent: v11.8.1 in August 2026, v11.1.2 in June 2026, v11.1.1 in April 2026, with the default branch receiving pushes as recently as September 2026. Frequent releases mean frequent upgrade decisions. Combined with the README's warning that non-public headers may change without warning, the maintenance cost is not in the licence but in the upgrade discipline: pin a release, track what changed in the options you set, and keep your integration inside include/.
What the README does not tell you is the size of the maintenance team, the support policy for older releases, or how long a given version receives fixes. Those are open questions, and they matter more for a storage library you embed than for a service you can restart.
Where to look before you decide
The README routes questions to two places: the RocksDB Developers Public group on Facebook and the email list on Google Groups. If your decision hinges on whether a specific compaction or amplification behaviour matches your workload, those channels are where the maintainers and other users are, according to the README.
The concrete verification list is short and comes straight from the README. Read include/rocksdb/ for the options that govern the three amplification factors. Read the examples directory for a working integration. Confirm the licence choice against COPYING and LICENSE.Apache. Then decide whether your team wants to own compaction tuning, because that is the recurring cost of adopting an LSM store with a configurable tradeoff surface, and no release note removes it.
Editorial conclusion
Adopt RocksDB if you are writing a C++ or C-ABI service that needs a persistent key-value store inside its own process and you can commit to tuning compaction. Do not adopt it if you need a network endpoint, SQL, or a storage layer you will never have to tune. Before you commit, read include/rocksdb/options.h for the options that apply to your workload, check the examples directory for a build that matches your toolchain, and confirm which of the two licences (GPLv2 in COPYING, Apache 2.0 in LICENSE.Apache) your legal review accepts, because the repository lets you pick either.
Community notes