[shubber]

It seems like Mongo in particular is reinventing the RDBMS wheel entirely, except with a frustrating JSON query language. The benchmark blog post a couple of days ago versus an out-of-the-box Postgres deploy (i.e. memory crippled) was not very impressive.

And look: they've implemented clusters - by pushing a Slony equivalent into the DB itself.

Please forgive my bile - I was a little nonplussed with Mongo, and now I have to use it for a client. Now I'm a lot nonplussed.

[bsg75]

MongoDB gets points for including a query language (vs CouchDB), but loses a few for it being JSON/JavaScript.

I understand the choice, JSON and JavaScript being so popular in current web platforms, but the SQL developer in me wishes for something more "readable" (see Lua in Redis).

[FooBarWidget]

RDBMSes still do not provide easy support for sharding. That alone makes MongoDB different.

[defen]

Just an FYI - you're using the word "nonplussed" incorrectly.

[inportb]

Perhaps shubber is nonplussed after learning about MongoDB's query language design and the client's choice of database -- why would anyone actually want such a monstrosity?!

[taligent]

Because MongoDB is a fantastic database for developers whilst RDBMS can suck big time.

In this age of agile development requirements and schemas change very, very rapidly and MongoDB excels at being able to support that.

[bsg75]

I am genuinely interested in why schema changes in RDBMS' are such a point of contention. Is it the addition of new columns that are problematic, or the modification of existing column datatypes?

Having written more than one mechanism to automate schema upgrades in remote deployments, and numerous migration scripts, I know it is an extra step in the development process, but I have not considered it an onerous one.

[gcarre]

Try ALTER TABLE ADD COLUMN on a 100 million rows table :).

Jeremy Zawodny from Craigslist explained why it helped them a lot for Craigslist archives database, where an alter table could take up to 24 hours: http://www.10gen.com/presentations/mongosf2011/craigslist

[bsg75]

OK, a MySQL problem. Not so much with PostgreSQL, where adding new columns noes not need to touch every table row.

NoSQL ~= NoMySQL

[SystemOut]

For me, the lack of schema also means that during an upgrade on a large database I can upgrade my app, start batch updating the data in the database and then also perform on-access upgrades and minimize my app downtime. Changing a schema in a large database can potentially require a lot of downtime or other interesting gymnastics to keep downtime to a minimum. I'm not completely sold on Mongo but this is one area where not having a schema can really help.

[jeltz]

Would not any online schema update in a more complicated cases (not just simply adding or removing columns) require interesting gymnastics or downtime in MongoDB too? The application needs to support both the old and new (and possible an intermediate) schemas during the online upgrade.

PostgreSQL supports transactional schema modifications. fast adding and removing of columns, and lockless index creation. So in simple cases upgrading the schema is trivial. For complicated cases it can be a mess, but my guess is that that applies to any database.

[taligent]

Simple. To add a new attribute with MongoDB I simply add a new variable in my Java model and that's it. Done.

With RDBMS. I have to write an update SQL script, rollback SQL script, run it against my dev environment, ensure it is applied through test environments and hope the DBA doesn't forgot to run it in production (it happens).

[wahnfrieden]

I use an RDBMS with Django. When I want to add a new attribute to a schema, I just add the variable to my model, and South picks up on the change and writes the update script for me.