>Why would you say that? It works well enough here. Well, both projects are rather new and changing. So not a very stable base to base a business on. Node.js

>Why would you say that? It works well enough here. Well, both projects are rather new and changing. So not a very stable base to base a business on. Node.js is best suited for long-running, evented type web apps (games, chat, interaction etc), so a CMS would not be a good fit. Mongo is also known to lose data, and needs several (3 at least) servers to be somewhat stable with this. A CMS is also not particularly read or write heavy, so a standard DB would fit even better. I assume the data already have some specific form, so the free-form (schema-less) of Mongo doesn't buy much (and you have to replicate some relational-es on top of Mongo anyway, if you want to avoid inefficient queries returning tons of unneeded data with the response that happen to be on the same level in the "tree"). In a CMS you also have a power-law distribution of read articles, or even worse, with the top page stuff getting the most hits, and older pages being statistical noise. So some caching should provide very good speed with very little memory needs. (Funny aside/rant: once I've implemented a custom CMS for a large bank in my country, with plain ole Java and DB2. The bank people had fallen for some IBM crap, and wanted the backend to be Domino, which, at the time (2003) was, well, let's say, inadequate. Our team implemented a CMS on top of Domino, and, as it naturally was slow as molasses, I convinced them to let us rewrite it in a sane way, which I did by myself in 1/5 the time it took to build the BS Domino version (about 2-3 months). It even had fancy things like being able to have them just upload an Excel file and automatically populating currency rates and stuff from it, with proper Decimal support, fail-rollback, etc). Hah, I also used Lucene for FTS, which was at version < 1.2 at the time IIRC.