Goodbye global lock – MongoDB 2.0 vs 2.2

Re:Goodbye global lock – MongoDB 2.0 vs 2.2 by jeltz on Wednesday May 23, 2012 @08:12PM (#4016029)

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.

[ Parent | on HN ]

Re:Goodbye global lock – MongoDB 2.0 vs 2.2 by taligent on Wednesday May 23, 2012 @11:18PM (#4016601)

Schema changes are exclusively an application-layer change in MongoDB. So MongoDB can support as many schemas as you want at the same time whilst you are migrating.

Also don't forget that MongoDB can have arrays and sets as a "column" type. Which if you tried to replicate in RDBMS would mean a multi-table migration.

[ Parent | on HN ]

Re:Goodbye global lock – MongoDB 2.0 vs 2.2 by jeltz on Thursday May 24, 2012 @07:43AM (#4017872)

> Schema changes are exclusively an application-layer change in MongoDB.

Which is not by itself an advantage. You still need to write the code which does the schema change if you for example rename a field.

> Also don't forget that MongoDB can have arrays and sets as a "column" type. Which if you tried to replicate in RDBMS would mean a multi-table migration.

So can PostgreSQL. The sets are not as general as in MongoDB though since they can only store strings.

[ Parent | on HN ]