[raverbashing]

"A migration is costly but also pretty rare. I migrate PostgreSQL with 100k+ rows as a matter of routine, it's over before you know it."

Not if your application is still on development.

100k+ rows? Not complicated. Try with 23M rows.

Nobody would risk migrating that table.

[zwily]

Usually a migration is adding a column. That takes the same time with 1M rows as it does with 1 row (in Postgres).

[acdha]

How does this change with MongoDB? The question of development support applies equally to both but it's usually MUCH safer to add a SQL column (default null, etc.) than to dive into a thicket of app-specific JS.

This has been happening for decades in the RDBMS world – even the ultra-conservative Oracle admins I've worked with were willing to come of out in-place retirement long enough to do something like that.

[raverbashing]

Changing code is one thing, changing the DB is another. A deployment that changes only the code is simpler than one that changes the DB.

How many DBs do you have? Testing (usually local), staging, production? For how many sites?

It works the same, if row['new_field'] do_something() else do_something_else()

You have unit tests to make sure it works.

And if it was so safer and easy to do it PostgreSQL wouldn't have added the json field.

[acdha]

> A deployment that changes only the code is simpler than one that changes the DB.

In your experience, perhaps, but that's reversed in many other places.

As for everything else your point is only accurate if you assume that migrations are done by hand. If use a migration library it's impossible to forget to apply a migration to a database so there's no problem working with copies or even forks of databases.

> And if it was so safer and easy to do it PostgreSQL wouldn't have added the json field.

You're implying causation incorrectly: hstore and JSON are useful for cases where you explicitly do not want schema enforcement or can't afford the performance impact of normalization. This is not saying that migrations are hard, merely that not all problems have the same best solution.

[yummyfajitas]

At my last job we did that on a regular basis, for the most part without even having downtime.

[raverbashing]

And at my last job no one would risk it because any issues with this would mean loss of revenue, angry customers and people having to revert code at a whim.

(Of course, not only migration issues, but any code issues as well)

[kasey_junk]

MongoDb is not going to solve development/operations issues, which is what you are describing. If anything, it makes those things worse as it is much more cavalier with your data.

[rsynnott]

> Nobody would risk migrating that table

People migrate tables a lot bigger than 23M rows all the time. On MySQL, even, though it's an offline task there.

[lsh123]

pt-online-schema-change, problem solved!

[AlisdairO]

What DB were you using?