4 ms·

So if I understand this correctly, they didn’t have the correct understanding/skills to manage a Mongo DB, so they switched to one they were more familiar with.

by KMnO4 6y ago

So if I understand this correctly, they didn’t have the correct understanding/skills to manage a Mongo DB, so they switched to one they were more familiar with. I wonder what this ultimately cost. Migrating from a document model to a relational DB requires code change in pretty much every single location it’s used. That’s a lot of engineer time to develop, test, and do the data migration.

afavour 6y ago
> they didn’t have the correct understanding/skills to manage a Mongo DB According to the post they paid Mongo a lot of money for support and they didn’t have the correct understanding/skills either. It sounds to me like the core problem is their requirement to run Mongo on their own AWS stack rather than Mongo’s, and while Mongo claimed to support it seems like they didn’t really. No doubt this was a huge migration but from my personal perspective going from Mongo to Postgres feels like a move in the right direction in the long term. For one you have a lot more options for support!
jpz 6y ago
If you hire a room full of developers at high salary and nobody is capable of acquiring "the correct understanding/skills" then maybe it's not such a straightforward technology. It is reasonably straightforward to deal with relational databases in comparison, this is a well-known space.
znpy 6y ago
> So if I understand this correctly Clearly you don't. They did have the correct understanding/skills to manage a Mongo DB, and on top of that they bough the MongoDB-Inc-recommended management tools and the MongoDB-Inc-recommended support plan. Basically they were doing everything by the book, as advertised and advised by MongoDB itself. Yet they were having problems, so much so that even MongoDB Inc's own support engineers weren't able to help. After a great lenght of discomfort they evaluated that MongoDB was not a good fit for them, and moved to PostgreSQL.
znpy 6y ago
> I wonder what this ultimately cost. > That’s a lot of engineer time to develop, test, and do the data migration. Downtime is more expensive. EDIT: Also, the article says that they spent at least two months a year planning and executiting database upgrades, since the OpsManager tool from MongoDB Inc wasn't able to help.
- sokoloff 6y ago
  Two months a year planning and executing upgrades isn't that outrageous-sounding to me. We did that for years on a commercially supported RDBMS (MS-SQL Enterprise in our case). It wasn't the whole engineering organization, but the overall "scale existing capabilities" effort was a 3K-10K hour project every year depending on how extensive the work was.
  - znpy 6y ago
    Well it kinda is if you bought a product that supposedly lets you do upgrades easily, from the vendor itself, and also have the support package from the vendor.
deleted 6y ago
[deleted]

by KMnO4 6y ago

afavour 6y ago

> they didn’t have the correct understanding/skills to manage a Mongo DB According to the post they paid Mongo a lot of money for support and they didn’t have the correct understanding/skills either. It sounds to me like the core problem is their requirement to run Mongo on their own AWS stack rather than Mongo’s, and while Mongo claimed to support it seems like they didn’t really. No doubt this was a huge migration but from my personal perspective going from Mongo to Postgres feels like a move in the right direction in the long term. For one you have a lot more options for support!

jpz 6y ago

If you hire a room full of developers at high salary and nobody is capable of acquiring "the correct understanding/skills" then maybe it's not such a straightforward technology. It is reasonably straightforward to deal with relational databases in comparison, this is a well-known space.

znpy 6y ago

> So if I understand this correctly Clearly you don't. They did have the correct understanding/skills to manage a Mongo DB, and on top of that they bough the MongoDB-Inc-recommended management tools and the MongoDB-Inc-recommended support plan. Basically they were doing everything by the book, as advertised and advised by MongoDB itself. Yet they were having problems, so much so that even MongoDB Inc's own support engineers weren't able to help. After a great lenght of discomfort they evaluated that MongoDB was not a good fit for them, and moved to PostgreSQL.

znpy 6y ago

> I wonder what this ultimately cost. > That’s a lot of engineer time to develop, test, and do the data migration. Downtime is more expensive. EDIT: Also, the article says that they spent at least two months a year planning and executiting database upgrades, since the OpsManager tool from MongoDB Inc wasn't able to help.

sokoloff 6y ago
Two months a year planning and executing upgrades isn't that outrageous-sounding to me. We did that for years on a commercially supported RDBMS (MS-SQL Enterprise in our case). It wasn't the whole engineering organization, but the overall "scale existing capabilities" effort was a 3K-10K hour project every year depending on how extensive the work was.
- znpy 6y ago
  Well it kinda is if you bought a product that supposedly lets you do upgrades easily, from the vendor itself, and also have the support package from the vendor.

deleted 6y ago

[deleted]