The overhead that makes RDBMS's so slow, is guaranteeing atomicity, consistency, isolation, durability, also known as ACID. Some of these properties are pretty critical for applications that deal with money. You don't want to lose a single order when the lights go out.

NoSQL databases usually sacrifice some or all of the ACID properties in return for severely reduced overhead. For many applications, this is fine -- if a few "diggs" go missing when the lights go out, it's no big deal.

For an e-commerce site, you need to ask yourself what you really need.

Do you really need a level of performance that a RDBMS can't deliver? Do you need the reliability that an RDBMS provides? Honestly, the answer to #2 is probably "yes", which rules out most NoSQL solutions. And unless you're dealing with traffic levels comparable to amazon.com's, an RDBMs, even on modest hardware will probably satisfy your performance needs just fine, especially if you limit yourself to simple queries, and index properly. Which makes the answer to #1 "no".

You could however, consider using a RDBMS for transaction data, and a NoSQL database for non-critical data, like product pages, user reviews, etc. But then you'd have twice as much datastore software to install, and any relationships between the data in the two data-stores would have to be managed in code -- there'd be no JOINing your NoSQL database against your RDBMS. This would likely result in an unnecessary level of complexity.

In the end, if an RDBMS offers features you must have for reliability, and it performs acceptably for the sorts of load you'll be experiencing, an RDBMS is probably the best bet.

Others have mentioned transaction capabilities in MySQL as a reason to choose it. I agree.

I also suggest you evaluate comparative deployment costs for web properties based on MongoDB vs. MySQL. There are dozens of hosting services offering MySQL services; competition is fierce between them; MySQL has years of experience delivering decent quality multi-tenant service; MySQL is widely understood among tech support people and network engineers. You say this is a personal project. Unless one of your purposes is to learn to configure and administer your own web property on your own, you should consider using the more widely deployed technology.

docs.reactioncommerce.com/reaction-docs/master/fa…

I found the following on the reactioncommerce docs:

Is MongoDB/NoSQL best suited for ecommerce?

We think so! We believe that the common SQL schema for legacy ecommerce platforms isn’t just >unnecessary; it’s overkill. By rethinking the way the database is architected, there are numerous >benefits of Mongo/NoSQL – from speed to simplified code.

We enforce all of the typical joins, cascades, schemas, validation, etc., with functionality that we >have included (collections, schemas, hooks, helpers). But instead of trying to join a bunch of stuff >together, we simply have an object that is a product. There are huge advantages to this >approach, such as speed + easy code + the schema can be easily modified to accommodate any >data requirements. This is unlike legacy platforms and their use of the entity - attribute - value >lookup that is so complex and slow. In fact, legacy platforms have tried to architect their way >around these very real limitations of SQL that NoSQL easily handles (using EAV). By using NoSQL, >we remove the very complex layer of looking up and joining attributes, and also the complexity >of adding new field/values. (You just do it to the main object, and that’s going to persist >throughout the life of the object.) We also don’t have to deal with the continuous translation of >database structure to a code object.

In reality, in our use, the DB is just the persistent storage of the JavaScript objects. For example, a >product is a collection of variants (objects) like blue, green, etc., and are each their own object >contained within a “product” object.

In localization (l10n), this can also mean different pricing, taxes, etc., for different regions, so >pricing is at the variant level not at the product level. This is even true with just one language >when you have “Blue XXL” being more expensive than “Green XL.”

MariaDB

Explanation of MySQL Transactions

As others have stated, the point of using MySQL or any other RDBMS is to have transactions. With transactions, you can ensure everything you need to get done, gets done properly and in the right order where as using something like MongoDB doesn't really ensure that.

What others have touched on but haven't elaborated on is that we live in a much different world now then we did 5 years ago.

You could very well read in your product catalog from a MongoDB or Firebase. Firebase, would allow you to show how many products are in stock in real time and if a product is in limited quantity, show the user that and lock them out from purchasing it if it sells out.

If you were to use something like Stripe to process the CC, then there really is no need for MySQL here. Process the payment with Stripe, ensure that it went through correctly via the backend code they provide and update MongoDB or Firebase to reflect the purchase.

MySQL and Transaction "could" and "probably should" be used for eCommerce, but now a days don't need to be.

Transactions are vital to the banking industry where if someone transfers money to another account the bank needs to be 100% positive the funds were removed from 1 account and added to the other or the entire transaction fails.

If you don't need to maintain accurate inventory - ie: your printing on demand with something like printful then a transaction probably isn't needed.

I'd go with a relational database over Mongo for an eCommerce site, but I wouldn't use MySQL if you're looking to scale since you'll face performance bottlenecks. I'd personally recommend Postgre.

You will need MySQL because you will frequently perform transactions in an eCommerce app. MongoDB doesn't support "multi-document" transactions. Although you could do a two phase commit to overcome this problem, I don't think this is the right approach. Instead you should go with a relational DB like MySQL to support transactions/rollbacks etc.

So, the bottom line is that MySQL is definitely a better choice for financial transactions (which is your case). You could also have both MySQL and MongoDB. For instance, MongoDB will work well for certain parts of your web app such as product catalogs. And you can use MySQL for handling transactions, storing customer details, order tracking etc.