Which database best fits node.js?

[TiagoP]

Hi,

Which database do you usually use with your node.js projects? Is there
any that fits node better? Maybe Riak?

[James Carr]

I always use couchDB, but the real answer is highly subjective.

I'd say: go with what you are most comfortable with.

Thanks,
James

> --
> 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.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
>
>

[fuzzy spoon]

What fits the job?

Also, i use couch as well.

[JoshK]

I don't think any one is "better" then the other, however I find
myself using MongoDB for a lot of things. Fast, flexible, and the
community support is top notch as well as the documentation.

Additionally they have drivers for just about any language.

Regards,

-Josh

[Stephen Belanger]

This thread is giving me deja vu.

Seriously though, it all depends on the needs of the application and personal preference. There's not really any "ideal" database, but certainly there is some that are more suitable than others.

[ono]

Can you elaborate on that last part? thanks

> > nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
> > .

[nwhite]

Every job has different requirements for completion. To say technology X is best is oversimplifying the problem. It doesn't take into consideration the skill set of your developers, what tools your currently using nor learning curve or costs of switching to said technology. Picking any technology is always a battle of compromises. One team might pick a cutting edge solution because it makes their development faster while another team may pick another because documentation and community support is more complete. Neither one is wrong. Pick the solution that gives your team the least tradeoffs for your existing development process.  

To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.

[Jaime Bueza]

@Stephen 

Just wondering, in what situations (application for example) would you say MongoDB is a better choice than CouchDB? I'm just starting NodeJS development so it'd be great to hear some of your experiences.

Cheers

[Mihai Călin Bazon]

On Thu, Sep 9, 2010 at 7:42 PM, nwhite <change...@gmail.com> wrote:
> One team might pick a cutting edge solution
> because it makes their development faster while another team may pick
> another because documentation and community support is more complete.
> Neither one is wrong.

For the sake of discussion, I disagree with that. Betting on the
wrong technology will bite you hard, even if it gets you quickly to an
working product (but I don't think it would).

Speaking of languages: judging by community, PHP is still the
"superior" choice. But you don't want to use PHP, really.

Speaking of databases, again judging by the community size, MySQL
seems to be the winner. But with it, you'll lose.

See, speaking in general, the tools that manage to attract the biggest
communities are usually the crappiest ones. I'm not sure why this
happens, but it does. We're living in a "worse is better" world. [1]

Now back to the DB problem: I'd go with Postgres. For fun stuff,
check this too: http://howfuckedismydatabase.com/ ;-)

[1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.114.4096&rep=rep1&type=pdf

Cheers,
-Mihai

[Akzhan Abdulin]

Today I move all database functionality into separate service written in ruby.

So my Node.JS service correcly uses its http::client to access their REST API.

But we have other possibilities like node-mysqlclient.

2010/9/9 TiagoP <pix...@gmail.com>

Hi,

Which database do you usually use with your node.js projects? Is there
any that fits node better? Maybe Riak?

[Stephen Belanger]

I should let someone else answer that, I looked at both when I started on my current node projects, but ultimately went with Mongo. I haven't actually used couch though, so I wouldn't exactly consider that a reliable judgement to go by. I'd recommend taking the time to research whatever options you are considering until you can make the choice yourself. Then you can only blame yourself if difficulties arise at some later point.

[Joran Greef]

If it helps you, I used to use CouchDB, than I dropped it for Tokyo
Cabinet served by Tokyo Tyrant (with my own Lua extensions to add set
union and intersection support). I was happy with that. Then I
realized that Redis provides built-in sets, sorted sets, lists, union,
intersection etc. and it is evented, so I've just started using that
and I can say that I'm learning alot from the ideas implemented in it.
Basically Redis is NOT a key/value store, it's more like a data
structures service. You can create tries, queues, etc. in there, use
it for pub/sub, etc. Because of this focus on data structures, it has
pure and simple interfaces (similar to Tokyo). Redis makes sense in
terms of "turtles all the way down".

[Serge in Darkness]

Depends on the task, really. I used mostly Redis and CouchDB (though i
found CouchDB a little limiting). Riak is good too.

[djangst]

Not Node-specific, but this blog entry might be helpful as it attempts
to characterize some of the available NoSQL options (there's more
discussion in the comments):

http://blog.heroku.com/archives/2010/7/20/nosql/

[MilesTogoe]

On 09/09/2010 09:19 AM, fuzzy spoon wrote:
> What fits the job?
>
> Also, i use couch as well.

we also use couchdb - but really you need to pick the db whose features
fit your needs the best - at least several have a good node driver
(mysql, sqlite, postgres, mongo, ....

[Fabian Jakobs]

We moved away from couchdb to redis because couchdb was too limiting
for us. Redis is really nice. You can think of it as a low level
database engine without the SQL cruft on top of it. For another
project I tried to use MySQL but I couldn't find drivers of sufficient
quality. I don't know if that has changed sine then.

Best Fabian

[Eric Fong]

Hi

Any performance or any benchmarking which comparing for Redis,
MongoDb, CouchDb and Riak?
I know Mongo is faster than Redis and CouchDb. But lack of data for
Riak.

Also, I am looking for Pure JS Library which can store data in HTML5
Local Storage offline and sync with one of the above Db.
That will be a very nice platform for offline web app.

Eric Fong

On Sep 10, 3:33 pm, Fabian Jakobs <fabian.jak...@web.de> wrote:
> We moved away from couchdb to redis because couchdb was too limiting
> for us. Redis is really nice. You can think of it as a low level
> database engine without the SQL cruft on top of it. For another
> project I tried to use MySQL but I couldn't find drivers of sufficient
> quality. I don't know if that has changed sine then.
>
> Best Fabian
>
>
>
> On Fri, Sep 10, 2010 at 3:40 AM, MilesTogoe <miles.to...@gmail.com> wrote:
> >  On 09/09/2010 09:19 AM, fuzzy spoon wrote:
>
> >> What fits the job?
>
> >> Also, i use couch as well.
>
> > we also use couchdb - but really you need to pick the db whose features fit
> > your needs the best - at least several have a good node driver (mysql,
> > sqlite, postgres, mongo, ....
>

[Joran Greef]

Don't go the route of using LocalStorage. There is no indication that
browser vendors plan on implementing UI to enable the user to extend
the storage limits imposed on LocalStorage (currently 10mb I think).
In any event, I am under the impression that WebKit synchronously
loads LocalStorage into memory the first that LocalStorage is used, so
this would severely affect the UI if you put too much data in there. I
know from personal experience with the above issues.

Better to go with WebKit's SqlDatabase API, and implement a wrapper on
this to give you a key/value store with basic indexing. Then be ready
for Mozilla's IndexedDB, and include this in your wrapper when
IndexedDB is released.

[fuzzy spoon]

Opera has dialogs to control per site quota, btw
I use the local Storage and couch together, its mainly just a
save-in-case and commit to db later.

//semi topic
I i decided to write a super entry level post about couch.
http://blog.owned.co.za/?p=269
Ill be refining it over the course of tonight, suggestions welcome :)

[Orlando Vazquez]

On Fri, Sep 10, 2010 at 2:53 AM, Eric Fong <eri...@gmail.com> wrote:

> I know Mongo is faster than Redis.

With all due respect, you may want to re-check your facts... given
that Redis is an in-memory datastore I find this highly unlikely.
Comparing Redis to MongoDB, Couch and Riak is like comparing apples to
baseballs. The only benchmark I can find to support this is
http://milancermak.posterous.com/benchmarking-tornados-sessions-0 and
it seems pretty flawed.

--
Orlando Vazquez

[AJ ONeal]

but don't forget, no matter which db you use: vim is the best editor ever

(just thought I'd take us off track before this goes into a flame war)

--

[Joshua Kehn]

All hail VIM!

Regards,

-Josh

____________________________________

Joshua Kehn | Josh...@gmail.com

http://joshuakehn.com

[Stephen Belanger]

I've never been a fan of vim. I'm generally editing enough files at once, that a tabbed editor ends up being more efficient for me. Even for editing system files I don't tend to use it, I usually prefer to use nano.

On the note of Mongo being faster than Redis;

Really? Where did you get that idea? I was under the impression that Redis was much faster. I can't think of any particular situations where Mongo would be faster. I wouldn't really compare them though. I think they can be complimentary in many projects, having Redis function somewhat like memcache to store frequently accessed data.

[Arnout Kazemier]

Redis smokes MongoDB in every way, sets and gets. 

Arnout Kazemier

in...@3rd-Eden.com

[Karl Tiedt]

Seriously people, its not about "what fits NODE", look at what you are
trying to do and pick the best database for your project... some DBs
focus on speed over data reliability, some on reliability over speed,
etc etc.. whats best for one is not always best for another... learn
it, live it, and let this pointless thread die already.

-Karl Tiedt

[Andi]

I fully agree with Karl.
On the other hand, going the NoSQL is preferable for the most cases,
especially in node - because of communicating JSON objects. I like
MongoDB a lot, for computing geo data I still use Postgres/PostGIS.

[Mikeal Rogers]

Someone should really just link to last months thread about this.

I think the concensus was that Redis is the shit if your problem fits
it's use case. CouchDB is a great general purpose db with great node
support. Postgres wins for relational with good node support. MongoDB
is great at losing data but good for analytics. Riak wins for
distributed db with good node support.

You need to figure out your use case and pick one that fits. There is
good node support for all databases right now compared to other
languages except for mongo and mysql because the standard c drivers
use blocking io. There are some pure js drivers but the maturity and
reliability of those are concerning compared to the tried and true c
drivers that have been in use in all languages for a while.

-Mikeal

[Timothy Caswell]

Also, for simple cases it's not hard to make something like nStore or node-dirty for fast, in-prcess persistence. I hope to soon make nStore rock solid and be a serious contender/compliment to other great systems like CouchDB, PostreSQL, and Redis.

Strengths of my 4 favorite solutions.

- CouchDB - Rock solid (durable, etc), replicates (this truly is awesome for mobile situations), and the protocol is HTTP based so using it from node is trivial even without a special client.
- Redis - Super awesome fast, super simple tcp protocol. You can telnet in and use it directly using text. There are solid node clients too.
- nStore - Super fast, persists to disk, in-process (100% pure node, uses the same process as the rest of your server)
- PostgreSQL - The best (IMHO) relational database for almost any relational use case. Very powerful and mature. You can do very complex queries since it has proper joins and query optimizers.

Weaknesses

- CouchDB - Somewhat heavy and a little slow for a nosql (but slow is relative, these are all pretty fast)
- Redis - It's not good for general purpose database or complex queries. Also it's optimized for the in-memory case
- nStore - not quite mature yet. No indexes yet (queries will be slow)
- PostgreSQL - Relational (This could be good or bad depending on your use case) Drivers for node are not quite mature.

Example use cases it's ideal for

- CouchDB - Lots of things, especially when you want to sync data for offline-online mode in the client (couch in the client too) Document oriented, some query ability through views. Also CouchApp style techniques are neat.
- Redis - Cache, event queues, other data structures, basically super high speed data that doesn't usually need to stick around forever or have complex queries against it.
- nStore - Aims to fit the same use cases of couch, but be simpler to set up and much faster. For simple persistence (think sqlite for node, but nosql)
- PostgreSQL - Large systems, traditional CRUD apps, anything with complicated queries/reports. There are addons for everything from GIS to full-text search. Native array data types and all sorts of other advanced use cases. Basically any use case that can fit into the relational model well will work great with postgres.

Like others have said. It depends on your use case. I would use all four of these (sometimes a couple in the same app at once) depending on my use case.

It's not about what fits node, but it is does matter what works from node. Binary protocols like postgres, mysql, mongo, etc are going to be harder to write solid drivers from node and have different levels of maturity since node's ecosystem as a whole is still quite young.

[siculars]

I use riak primarily and have contributed to the nodejs riak module,
riak-js (http://riakjs.org). For comparisons take a look at the Basho
(makers of riak) comparisons wiki page http://wiki.basho.com/display/RIAK/Riak+Comparisons.

-Alexander

[Felix Geisendörfer]

> For another
> project I tried to use MySQL but I couldn't find drivers of sufficient
> quality. I don't know if that has changed sine then.

Have you tried http://github.com/felixge/node-mysql ?

It probably still has a few bugs, but some people already seem to
successfully use it, and if you report an issue I'll promptly fix it.
I'll start using it in production mysql very soon (basically when I
have the time to rip out my old "hack" that transloadit is currently
using to talk to mysql).

--fg

On Sep 10, 9:33 am, Fabian Jakobs <fabian.jak...@web.de> wrote:
> We moved away from couchdb to redis because couchdb was too limiting
> for us. Redis is really nice. You can think of it as a low level
> database engine without the SQL cruft on top of it. For another
> project I tried to use MySQL but I couldn't find drivers of sufficient
> quality. I don't know if that has changed sine then.
>
> Best Fabian
>
>
>
> On Fri, Sep 10, 2010 at 3:40 AM, MilesTogoe <miles.to...@gmail.com> wrote:
> >  On 09/09/2010 09:19 AM, fuzzy spoon wrote:
>
> >> What fits the job?
>
> >> Also, i use couch as well.
>
> > we also use couchdb - but really you need to pick the db whose features fit
> > your needs the best - at least several have a good node driver (mysql,
> > sqlite, postgres, mongo, ....
>

[fuzzy spoon]

Timothy, thats a great coverage of the pro's cons.
Would you or anyone else mind if i posted this on my blog as a common link?
Or perhaps anyone can, as a point to guide for this super FAQ.

2010/9/11 Felix Geisendörfer <fe...@debuggable.com>:

[Tim Caswell]

Maybe we should have a wiki page on ry/node's github. That way people
new to node can know the options. There is the modules list and npm's
repository, but that doesn't explain the pros and cons of the
different options nor the maturity of the libraries. This thread is
not new, it's already been had a few times already.

[fuzzy spoon]

Yea, i think a FAQ in wiki form (that actual node users with logic can edit),
Where these sort of FAQ's can be covered would be awesome.

[Tim Smart]

On Sep 11, 5:28 am, Stephen Belanger <cyruzdr...@gmail.com> wrote:
> I've never been a fan of vim. I'm generally editing enough files at once,
> that a tabbed editor ends up being more efficient for me. Even for editing
> system files I don't tend to use it, I usually prefer to use nano.

Vim has always had tabs ( :tabedit/:tabe :tabnext/:tabn ... ). Vim +
screen <3.

> On the note of Mongo being faster than Redis;
>
> Really? Where did you get that idea? I was under the impression that Redis
> was much faster. I can't think of any particular situations where Mongo
> would be faster. I wouldn't really compare them though. I think they can be
> complimentary in many projects, having Redis function somewhat like memcache
> to store frequently accessed data.

Anyway, I have been feeling the Redis vibe lately. It's like a
screaming low-level machine. Just like Node.

Tim.

[Stephen Belanger]

But they aren't so pretty, with fancy rounded corners, filenames and handy close buttons. :P

--

[Charlie]

Mikeal, what is the experience you've had with MongoDB losing data?
Is this related to the fact it doesn't yet have single server
durability (apparently coming in 1.8?) I'm interested in using Mongo
on my next project due to it's querying abilities but have been
investigating the reports of lost data.

On Sep 11, 6:37 pm, Mikeal Rogers <mikeal.rog...@gmail.com> wrote:
> Someone should really just link to last months thread about this.
>

> I think the concensus was thatRedisis the shit if your problem fits

> it's use case. CouchDB is a great general purpose db with great node
> support. Postgres wins for relational with good node support.MongoDB
> is great at losing data but good for analytics. Riak wins for
> distributed db with good node support.
>
> You need to figure out your use case and pick one that fits. There is
> good node support for all databases right now compared to other
> languages except for mongo and mysql because the standard c drivers
> use blocking io. There are some pure js drivers but the maturity and
> reliability of those are concerning compared to the tried and true c
> drivers that have been in use in all languages for a while.
>
> -Mikeal
>
>
>
> On Saturday, September 11, 2010, Andi <andreaskal...@gmx.de> wrote:
> > I fully agree with Karl.
> > On the other hand, going the NoSQL is preferable for the most cases,
> > especially in node - because of communicating JSON objects. I like

> >MongoDBa lot, for computing geo data I still use Postgres/PostGIS.

[Mikeal Rogers]

I've actually already written a pretty detailed article about MongoDB's view of durability and how that compares the rest of the database world.

http://www.mikealrogers.com/2010/07/mongodb-performance-durability/

-Mikeal

[Elijah Insua]

On Fri, Sep 17, 2010 at 6:09 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:

I've actually already written a pretty detailed article about MongoDB's view of durability and how that compares the rest of the database world.

http://www.mikealrogers.com/2010/07/mongodb-performance-durability/

-Mikeal

as a followup: http://www.thebuzzmedia.com/mongodb-single-server-data-durability-guide/