If I may share some advice - don't bother. As another commenter pointed out, relationships are inherent in a lot of the data you'll store for your platform, and for those elements that you'd like to keep the full data hash, just use jsonb in Postgres.

Once you're at several million in revenue, then you can think about splitting off some parts of your data into document storage solutions for certain efficiency reasons, but that is by no means necessary.

This is a great video on the topic: https://www.youtube.com/watch?v=HaEPXoXVf2k

eCommerce needs a hybrid data model. There are inherent relationships between various parts of eCommerce entities and it becomes very hard if just using noSQL with all the integrity constraints defined in application.

This is one of the reason many companies moved back to relational model after dabbling with noSQL. I believe the best way to model it is to use something like PostgreSQL with jsonb docs for some type of data.

If you are interested in noSQL database may be give a try to reactioncommerce (acquired recently), you will begin to hit limitations soon, given integrity constraint and ACID compliance becomes very important for some type of eCommerce data e.g. changing prices and inventory in real time which are consistent and correct. It becomes extremely hard and complex to manage it in application code, which comes free with relational database model.

You're going to want to run analytics, and to do that you need comparable data. Legacy data was a huge problem for the e-commerce giant I used to work at, even in The SQL database with a schema. NoSQL would be a silly non starter for any serious data modelling effort after a couple years of migrations outages, and code changes.