Anyone who is looking for an alternate to SQL should check MongoDB out. Now that they have reached a stable milestone it seems like a no brainer for write-often read-rarely types of applications (logging, metrics). It's lightning fast.

Setup is a breeze now that they have distributable packages for Mac/Linux/Windows in both 32 and 64 bit versions available.

I do wish they would create an officially supported C# driver. I think it would really give their adoption rate a boost.

It would be interesting to write a command line script for piping Apache logs in to MongoDB, using Apache's "piped logs" feature: http://httpd.apache.org/docs/2.0/logs.html#piped

I'll probably be re-writing some logging functionality in it, actually. I love asynchronous operations. AKA, "YAY! NEW TOYS!"

Ups:

  * No in-process cache required.
  * Very clean design.

  * Every read from disk would bring a lot more data than required.
  * 64-bit process required to support large files.
    * Since they use a JavaScript VM this would consume 40-60% more memory
      because of double pointer size.
    * V8 is x86 only so they switched to SpiderMonkey
      (slower, even with upcomming tracing.)

I am not any kind of authority in this area so please take this comment with a grain of salt.

* At least on my 64-bit linux box, mmap page size is 4k. So if you have to read 100 bytes vs 4k, in the end I don't think its a big difference. From the drives point of view, 100 bytes and 4k are basically the same, and with os file caches, it'll cache the 4k anyway most likely

* The JavaScript support is very optional (only db.eval and $where). When it used it uses very little memory because nothing is really stored in it. Its basically processing 1 record at a time and we've written a very efficient wrapper. Also, v8 actually just released a 64-bit version, so we may look into switching back to that as well if it turns out to be a lot faster than trace monkey.

Why do you think its green and small? Its actually been used in production for over 18 months (www.businessinsider.com for example)

  > At least on my 64-bit linux box, mmap page size is 4k. So if you have to read
  > 100 bytes vs 4k, in the end I don't think its a big difference. From the
  > drives point of view, 100 bytes and 4k are basically the same, and with os file
  > caches, it'll cache the 4k anyway most likely

  > The JavaScript support is very optional (only db.eval and $where). When it used
  > it uses very little memory because nothing is really stored in it. Its
  > basically processing 1 record at a time and we've written a very efficient
  > wrapper.

  > Also, v8 actually just released a 64-bit version, so we may look into
  > switching back to that as well if it turns out to be a lot faster than
  > trace monkey.

BTW, I couldn't find a stable release of Spidermonkey with Tracemonkey. But it could be my fault entirely.

  > Why do you think its green and small? Its actually been used in production
  > for over 18 months (www.businessinsider.com for example)

Again, I think it has all the potential and has a fantastic team. And maybe a bit of hard testing and some presentations could dispel [my opinion on] memory usage. As I said in my previous comment, take my opinion with a grain of salt!

[Edit: formatting, little rephrasing]

> and with os file caches, it'll cache the 4k anyway

Usually in a high-end database direct I/O is used on Linux.