At this point why not just:
apt-get install postgres psql < "CREATE TABLE mongodb (key varchar[1024] NOT NULL PRIMARY KEY,value jsonb);"
then you get the best of both worlds.
It's better to say "key text" instead of "key varchar(1024)" and primary key already implies not null.
How many QPS does it perform?
What's your read/write balance?
And I still wouldn't use Mongo!
As a long time observer of the database market with no skin in this particular game, in terms of regaining market momentum it is difficult to get past the reputation of being technically defective once that perception is broadly in place. To make matters worse, needing to completely replace the storage engine with a proper design will be viewed by some as an admission of that rather than an upgrade per se. It may be too little, too late for its long term prospects. By contrast, PostgreSQL is doing great right now; just about every company I talk to is using it somewhere.
Putting on my database engine designer hat, MongoDB did need to start from scratch with that storage engine; the original one was a naive design with a lot of problems. The sharding/replication design is still quite dodgy, which will hinder practical scalability. A new storage engine is a start but not enough if MongoDB wants to regain their momentum.
* SQLite - it's everywhere thanks to mobile phones.
* Oracle.
* Microsoft's thing has to have a big following.
* Mysql.
* DB2 is not as big as Oracle, but IBM isn't some lightweight, either.
MongoDB gets talked about a lot, and probably used among people trying new stuff out, but I think a lot of mostly silent people wouldn't touch something like that for their important data with a 10 foot pole.
From the article:
"In addition to compression and record-level locking, WiredTiger also gives MongoDB multi-version concurrency control (MVCC), multi-document transactions, and support for log-structured merge-trees, or LSM trees, for very high insert workloads"
I'd also love to see them add document joins at some point. That's a a big differentiating feature for RethinkDB, although I've found Rethink's syntax to be difficult to reason through.
This result is particularly relevant for MongoDB, since a document store tends to have large records containing multiple fields, as opposed to individual values being stored as separate small records.
And in cases where that applies (large records), nothing comes anywhere close to LMDB's performance.
(A preview of the on-disk test results I mentioned was presented at BuildStuff.LT last week http://symas.com/mdb/20141120-BuildStuff-Lightning.pdf pages 103-on)
[1] https://github.com/couchbaselabs/forestdb/wiki/Performance-R...
