The Berkeley DB license issue has caused major GNU/Linux distributions such as Debian to completely phase out their use of Berkeley DB, with a preference for LMDB. There are wrappers for several programming languages, such as C++, Java, Python, Lua, Go, Ruby, Objective C, Javascript, C#, Perl, PHP, Tcl and Common Lisp. A complete list of wrappers may be found on the main web site. Howard Chu ported SQLite 3.7.7.1 to use LMDB instead of its original B-tree code, calling the end result SQLightning. One cited insert test of 1000 records was 20 times faster (than the original SQLite with its B-Tree implementation). LMDB is available as a backing store for other open source projects including Cyrus SASL, Heimdal Kerberos, and OpenDKIM. It is also available in some other NoSQL projects like MemcacheDB  and Mapkeeper. LMDB was used to make the in-memory store Redis persist data on disk. The existing back-end in Redis showed pathological behaviour in rare cases, and a replacement was sought. The baroque API of LMDB was criticized though, forcing a lot of coding to get simple things done however its performance and reliability during testing was considerably better than the alternative back-end stores that were tried. An independent third-party software developer utilised the Python bindings to LMDB in a high-performance environment and published, on the prominent technical news site Slashdot, how the system managed to successfully sustain 200,000 simultaneous read, write and delete operations per second (a total of 600,000 database operations per second). An up-to-date list of applications using LMDB is maintained on the main web site. Many popular free software projects distribute or include support for LMDB, often as the primary or sole storage mechanism. LMDB makes novel use of well-known computer science techniques such as copy-on-write semantics and B+ trees to provide atomicity and reliability guarantees as well as performance that can be hard to accept, given the library's relative simplicity and that no other similar key-value store database offers the same guarantees or overall performance, even though the authors "explicitly state" in presentations that LMDB is read-optimised not write-optimised. Additionally, as LMDB was primarily developed for use in OpenLDAP its developers are focused mainly on development and maintenance of OpenLDAP, not on LMDB per se. The developers limited time spent presenting the first benchmark results was therefore criticized as not stating limitations, and for giving a "silver bullet impression" not adequate to address an engineers attitude "(it has to be pointed out that the concerns raised however were later adequately addressed to the reviewer's satisfaction by the key developer behind LMDB.)"