Since Wix is using MySQL as a key-store ... I wonder why they didn't look at using Postgres HStore [1].
HStore is a key value store built directly in the RDBMS of Postgres.
HStore is a key value store built directly in the RDBMS of Postgres.
HStore was released, we've migrated to PG and we can't be happier. Zero issues so far.
I agree with the Wix team. I've used Mongo in a very high volume site and it was a constant source of headaches. We even had an engineer we called "MongoDB" because he was constantly having to deal with scaling it. It didn't even handle more than 10% of the application data, it was strictly for timelines; the rest of it was in trusty old MySQL. If we'd just done blobs as JSON in MySQL in the first place we would have been completely fine.
Even though I prefer Postgres, knowing nothing else, I would prefer 100% SQL in MySQL than a Postgres backed application that splits the storage between tables and KV store.
Well, to be fair you would typically expect a database that's the equivalent of a remote hash table to be pretty much as fast as you can get. Now I don't have any experience with couch but most of the other key value stores I've used they scream with performance. But if you're doing anything beyond basic manipulations then it's going to require a lot of tuning depending on the solution you went with.
But RDMS can be very similar. Both are useful tools when used correctly and there is a huge amount of overlap in terms of capability.
Most applications are probably fine regardless of the underlying data store, and are better served by what works best for the model of the data, which can often be SQL. I'm more inclined to react for mongo or rethinkdb first, as I tend to think more in terms of more complex records/objects in most of the applications I've worked on.
Hstore is more k->k->v, which is the same but different, and also leads inexperienced developers to model entire relationships in a single column
I have some experience with this having worked on an experimental storage engine for mysql that we connected to a transactional in-memory k-v store. The performance penalty for simple k-v workload through mysql was quite substantial, though our storage engine code was probably not sufficiently optimized. It would be interesting to explore this for innodb though
[1] https://dev.mysql.com/doc/refman/5.6/en/innodb-memcached.htm...