You were already losing credibility due to your inattention to detail. I never mentioned performance anywhere in this thread. It's stupid to even talk about it since a hash doesn't do ordered lookups. But now that you're raising the topic: https://github.com/hyc/leveldb/tree/benches/doc/bench

"Spanks the living crap" - must be some heretofore unknown definition of "spanks".

./db_bench_mdbm
MDBM: version 4.11.1
Date: Mon Dec 15 04:39:20 2014
CPU: 4 * Intel(R) Core(TM)2 Extreme CPU Q9300 @ 2.53GHz
CPUCache: 6144 KB
Keys: 16 bytes each
Values: 100 bytes each (50 bytes after compression)
Entries: 1000000
RawSize: 110.6 MB (estimated)
FileSize: 62.9 MB (estimated)
------------------------------------------------
fillrandsync : 40.627 micros/op 24614 ops/sec; 2.7 MB/s (1000 ops)
65604	/tmp/leveldbtest-1000
fillrandom : 16.356 micros/op 61137 ops/sec; 6.8 MB/s
122056	/tmp/leveldbtest-1000
fillrandbatch : 5.499 micros/op 181850 ops/sec; 20.1 MB/s
121936	/tmp/leveldbtest-1000
fillseqsync : 40.163 micros/op 24898 ops/sec; 2.8 MB/s (1000 ops)
65604	/tmp/leveldbtest-1000
fillseq : 16.424 micros/op 60886 ops/sec; 6.7 MB/s
175724	/tmp/leveldbtest-1000
fillseqbatch : 5.648 micros/op 177041 ops/sec; 19.6 MB/s
175724	/tmp/leveldbtest-1000
overwrite : 16.290 micros/op 61385 ops/sec; 6.8 MB/s
175724	/tmp/leveldbtest-1000
readrandom : 0.598 micros/op 1672444 ops/sec; (1000000 of 1000000 found)
readseq : 0.096 micros/op 10370216 ops/sec; 1147.2 MB/s

./db_bench_mdb
LMDB: version LMDB 0.9.14: (September 20, 2014)
Date: Mon Dec 15 04:41:37 2014
CPU: 4 * Intel(R) Core(TM)2 Extreme CPU Q9300 @ 2.53GHz
CPUCache: 6144 KB
Keys: 16 bytes each
Values: 100 bytes each (50 bytes after compression)
Entries: 1000000
RawSize: 110.6 MB (estimated)
FileSize: 62.9 MB (estimated)
------------------------------------------------
fillrandsync : 12.818 micros/op 78015 ops/sec; 8.6 MB/s (1000 ops)
224	/tmp/leveldbtest-1000/dbbench_mdb-1
224	/tmp/leveldbtest-1000
fillrandom : 4.275 micros/op 233923 ops/sec; 25.9 MB/s
116548	/tmp/leveldbtest-1000/dbbench_mdb-2
116548	/tmp/leveldbtest-1000
fillrandbatch : 3.490 micros/op 286502 ops/sec; 31.7 MB/s
126384	/tmp/leveldbtest-1000/dbbench_mdb-3
126384	/tmp/leveldbtest-1000
fillseqsync : 14.972 micros/op 66791 ops/sec; 7.4 MB/s (1000 ops)
172	/tmp/leveldbtest-1000/dbbench_mdb-4
172	/tmp/leveldbtest-1000
fillseq : 2.231 micros/op 448145 ops/sec; 49.6 MB/s
125872	/tmp/leveldbtest-1000/dbbench_mdb-5
125872	/tmp/leveldbtest-1000
fillseqbatch : 0.425 micros/op 2355457 ops/sec; 260.6 MB/s
125872	/tmp/leveldbtest-1000/dbbench_mdb-6
125872	/tmp/leveldbtest-1000
overwrite : 4.881 micros/op 204857 ops/sec; 22.7 MB/s
125872	/tmp/leveldbtest-1000/dbbench_mdb-6
125872	/tmp/leveldbtest-1000
readrandom : 1.166 micros/op 857624 ops/sec; (1000000 of 1000000 found)
readseq : 0.059 micros/op 17092556 ops/sec; 1890.9 MB/s
readreverse : 0.042 micros/op 23814626 ops/sec; 2634.5 MB/s

Feel free to submit a patch if I got anything wrong in that driver; it was a pretty hasty patch. This is running on tmpfs, so no I/O involved. MDBM is faster on random read, which is what you'd expect since it's a hash and doesn't have to navigate down a tree to locate a record. Aside from that, it's pretty pedestrian.