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.