When picking a database, I think it's a bad idea to start by looking at all the databases available to you and comparing their features. That's like comparing all the vehicles available to you for a trap, picking a supersonic jet because of its speed, when all you needed was a bike to cycle 5 minutes down the road.
All these databases, key-value stores and search engines are built to solve different problems, and without a problem to solve you can't make an informed decision. Working from the problem to a tools that can fix it is the only way to find the right data store. Here's some examples... You're building a javascript-heavy website that needs to work offline and on mobile. This problem suggests that you need the following attributes: - good syncing & conflict resolution support, because changes can be made offline; - if possible, a client-side version so that you can use the same data storage API whether online or offline; - real-time event support, so that you can, for example, show notification to your users when another user makes a change to some data. What might you pick in this scenario? CouchDB is the obvious choice, as at its core it's about syncing and replication, and you can transparently support offline usage with the client-side implementation, PouchDB. You're building a web application where user's interactions are minimal but you serve alot of data, and the data you provide has a clear hierarchy: This suggests: - good support for relations between data, to allow you to turn raw data into data structures on the database side - transaction support, where you can batch together a set of operations to make sure you can rollback if something goes wrong - redundancy, where every write you make can also be made in other places so that, if you master database falls over, you can quickly restore access In this case, you could pick something like PostgreSQL or MySQL (yep, still a good option). Mongo also wouldn't be a bad option, although its (lack of) transaction support has had me quite frustrated recently. To quickly cover some other things you mention: ElasticSearch isn't a database as such – it's an engine for searching your data. If you need to provide search over a ton of data, take a look at it. MongoDB is a document storage engine, and is generally useful, reliable and easy to set up. Redis, LevelDB and other key-value data stores do not offer, natively, support for storing and manipulating data structures because they are just key and value stores. But, as Mikeal said, there's a community around Level (and probably Redis) that's adding these things on top – and in that sense you can 'build your own database'. I don't know anything about RethinkDB - at a cursory glance, it doesn't look like they've rethought much, and it's a young platform so don't expect every problem you come up with to be Googleable. You only get that with mature systems like MySQL, Postgres - but Mongo and Couch are catching up in this area. Both have active and helpful communities, like Node does. On the hosted/self-hosted question – I personally go for hosted databases where the problem suggests it. I'm not an operations guy and I don't know about database system administration. I'm a developer, and I'm concerned with the application logic – keeping a database running, and running fast, is just a distraction. However, if you're working in a team and have servers (& ops people) available, there are good reasons to go for a self-hosted option. As you can tell, there's a lot to picking a data store – but I think one thing's for sure: you have to base a decision on your particular problem. Cheers, Tom On Wednesday, August 28, 2013 6:14:57 PM UTC+1, Dylan Hassinger wrote: > > These posts really cleared it up for me. Cool stuff. Thank you so much!! > > > On Wed, Aug 28, 2013 at 1:12 PM, Mikeal Rogers > <mikeal...@gmail.com<javascript:> > > wrote: > >> I would phrase this differently. As you write your own database using >> node.js and LevelDB you can host it pretty much anywhere that you can run a >> node.js program. Its deployment and management is identical to how you >> manage your node.js application. This means that you avoid most of the pain >> that goes with running infrastructure, like traditional databases, and it >> means you don't really need/want specialized "database hosting." >> >> On Aug 28, 2013, at 7:37AM, vladimir....@gmail.com <javascript:> wrote: >> >> so there there is no such thing as hosted LevelDB >> >> >> -- >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to nod...@googlegroups.com<javascript:> >> To unsubscribe from this group, send email to >> nodejs+un...@googlegroups.com <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "nodejs" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to nodejs+un...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
