|Developer(s)||Jeffrey Dean, Sanjay Ghemawat, Google Inc.|
1.23 / 23 February 2021
|Size||350 kB (binary size)|
|License||New BSD License|
LevelDB is an open-source on-disk key-value store written by Google fellows Jeffrey Dean and Sanjay Ghemawat. Inspired by Bigtable, LevelDB is hosted on GitHub under the New BSD License and has been ported to a variety of Unix-based systems, and macOS, Windows, and Android.
LevelDB stores keys and values in arbitrary byte arrays, and data is sorted by key. It supports batching writes, forward and backward iteration, and compression of the data via Google's Snappy compression library.
LevelDB is not a SQL database. Like other NoSQL and dbm stores, it does not have a relational data model and it does not support SQL queries. Also, it has no support for indexes. Applications use LevelDB as a library, as it does not provide a server or command-line interface.
LevelDB is based on concepts from Google's Bigtable database system. The table implementation for the Bigtable system was developed starting in about 2004, and is based on a different Google internal code base than the LevelDB code. That code base relies on a number of Google code libraries that are not themselves open sourced, so directly open sourcing that code would have been difficult. Jeff Dean and Sanjay Ghemawat wanted to create a system resembling the Bigtable tablet stack that had minimal dependencies and would be suitable for open sourcing, and also would be suitable for use in Chrome for the IndexedDB implementation. They wrote LevelDB starting in early 2011, with the same general design as the Bigtable tablet stack, but not sharing any of the code.
LevelDB is used as the backend database for Google Chrome's IndexedDB and is one of the supported backends for Riak. Additionally, Bitcoin Core and go-ethereum store the blockchain metadata using a LevelDB database. Minecraft Bedrock Edition uses a modified version for chunk and entity data storage. Autodesk AutoCAD 2016 also uses LevelDB.
Google has provided benchmarks comparing LevelDB's performance to SQLite and Kyoto Cabinet in different scenarios. LevelDB outperforms both SQLite and Kyoto Cabinet in write operations and sequential-order read operations. LevelDB also excels at batch writes, but is slower than SQLite when dealing with large values. The currently published benchmarks were updated after SQLite configuration mistakes were noted in an earlier version of the results. Updated benchmarks show that LevelDB also outperforms Berkeley DB, but these tests also show that OpenLDAP LightningDB is much faster (~10 times in some scenarios) in read operations and some write types (e.g. batch and synchronous writes, see the link above), and is almost equal in the rest of the test.
Bugs and reliability
LevelDB has history of database corruption bugs. A study from 2014 has found that, on older (non-checksummed) file systems, the database could become corrupted after a crash or power failure.
- "Release 1.23". 23 February 2021. Retrieved 13 March 2021.
- "Google Research Scientists and Engineers: Jeffrey Dean". Google, Inc.
- "Research Scientists and Engineers: Sanjay Ghemawat". Google, Inc.
- "Google Open-Sources NoSQL Database Called LevelDB". ReadWriteWeb. July 30, 2011. Archived from the original on August 16, 2011. Retrieved July 30, 2011.
- "Google Open Source Blog: LevelDB: A Fast Persistent Key-Value Store". Google, Inc.
- LevelDB storage engine
- Jeff Dean. "LevelDB mailing list: "Current Status of LevelDB"".
- LevelDB. Docs.basho.com. Retrieved on 2013-09-18.
- Andreas M. Antonopoulos. "Chapter 7. The Blockchain". Retrieved 8 January 2015.
- "LevelDB Benchmarks". Google, Inc. Archived from the original on 2011-08-20.
- "LevelDB Benchmark discussion".
- Database Microbenchmarks Archived 2014-08-09 at the Wayback Machine, Symas Corp., 2012-09. Retrieved 22 October 2016
- Repairing LevelDB
- Issues · google/leveldb · GitHub
- Unrecoverable corruption in Chromium
- Corruption in syncthing
- Corruption after power loss
- Corruption in Ethereum
- "All File Systems Are Not Created Equal: On the Complexity of Crafting Crash-Consistent Applications".