My team is planning to migrate our e-commerce backend from MySQL to MongoDB to handle our growing horizontal scaling needs. I’m concerned about losing ACID compliance and how to handle complex joins that we currently rely on. Is the transition to a document-oriented structure worth the effort for a catalog with millions of SKUs, or are we overcomplicating our tech stack?
3 answers
I led a similar migration in late 2023 for a logistics platform. The biggest shift isn't the technology, it's the mindset. In SQL, you normalize everything; in MongoDB, you "embed" data that is frequently read together. Regarding ACID compliance, MongoDB has supported multi-document transactions since version 4.0, so your financial integrity is safe. For an e-commerce catalog, the flexibility to add new product attributes without running a heavy ALTER TABLE command is a total game-changer. We saw a 40% improvement in read performance after optimizing our document structures.
That sounds like a massive undertaking! Are you planning to use the MongoDB Atlas Live Migration Service, or are you building a custom ETL pipeline to transform your relational data into JSON documents?
Start by identifying your most expensive JOIN queries. If you can model those as single document reads in Mongo, your performance will skyrocket immediately.
Joshua is right. Data modeling in NoSQL is driven by your application's access patterns, not the data's relationship. It's a "query-first" design approach.
Steven, we are actually leaning towards a custom ETL process using Python. We need to restructure our "Orders" and "Users" tables into a single nested document to reduce the latency we’re currently seeing with multiple JOIN operations. It's a lot of work upfront, but based on Margaret’s experience, it seems like the performance gains for our mobile app users will be worth the development overhead.