I'd hesitate to call RAC a true example of "scaling out". As you've mentioned, RAC relies upon shared disk in a SAN to provide data storage. Exadata would be th

I'd hesitate to call RAC a true example of "scaling out". As you've mentioned, RAC relies upon shared disk in a SAN to provide data storage. Exadata would be the more appropriate comparison: there's also the "appliance" model and while Exadata was originally meant as an OLAP solution, it is claimed to be OLTP capable via SSDs and fast interconnect. You're also very correct in that a caching layer in front of a database that _itself_ includes a cache seems like added complexity and resources (similarly to using a query cache in front of InnoDB's own cache with MySQL). A true scale out solution should not require (or even significantly benefit) from a caching layer. However, I don't see how your product runs on commodity hardware: I can't buy a machine from Supermicro to run it, it makes use of high-speed interconnect (not something I can place in most data-centers). It seems more targeted at e.g., billing/accounting systems (which require strong transactional integrity) rather than storing high-scalability web application state (e.g., sessions, shopping carts, user histories, analytically derived data, CMS content, small pictures). "Appliances" generally have the stigma of being difficult to manage, requiring more admins for for the same number of machines than regular hardware. "Web scale" companies (e.g., Facebook, Google, Amazon, Yahoo) can run huge clusters with very few numbers of administrators (easily thousand machines per person) due to extensive automation of the whole process. Since the appliances running on a different OS image, the operations team can't manage them via their standard set of provisioning and configuration management tools: when one goes down, they can't use their main jumpstart/kickstart server to perform an unattended install; there will be difficulties managing its configuration via standard tools like puppet/cfengine/chef (much less custom tools that such companies write). From what I've seen, they end up typically relying on separate teams to manage their Oracle RAC installations due to these issues (these teams often have a much worse admin:machine ratio e.g., multiple-person teams for a <100 node RAC cluster). Facebook opts to stick with MySQL partly because their operations team know how to automate every bit of it. How do you plan to address these issues? That being said, I love seeing start-ups solve difficult problems. Congratulations on shipping a product that solves a tough problem.