Considering most CMS systems barely reach 100req/s (uncached), I think we can say raw database speed is less of a problem than bad query patterns. Or if you prefer, the use of a SQL db is no guarantee for performance.
Maybe mongodb will perform better, free of joins, than MySQL/Wordpress/whateverCMS... or maybe the data access pattern will suck and make it slow (and maybe it would be slow with a SQL db too, like other CMSs).
Ideally (in terms of performance), a single K/V request would be needed for each page, and the CMS would handle all the denormalization (and tens of thousands of req/s). I don't know how they've designed their data model...
All in all, a CMS is the most cachable web app ever, as it's more or less meant to replace static pages ;-) The poor performance of existing CMSs has always been hidden by caching layers...
100% agree. But there is not a single word about caching or how to integrate it with Relax either. I understand it is a young project but if I need a CMS I want it to have it a little tested and scaling questions not open. Caching is totally NOT trivial with React,Redux,GraphQL (at least I totally don't know how to do it but maybe I'm not smart enough) ... maybe it is even harder with such an architecture. I'm just saying I doubt a littlebit the cool and shiny architecture justifies the purpose (many questions open).
Despite that, can't say for a fact that's the case for Relax since I haven't test both on it. Mongo is behaving really well though, our demo instance has been getting a pound lately (dozens of users at a time) and it's running smoothly even though our machine is not really powerful.
Having this said, not entirely against having different database layers supported in Relax. Since we're using GraphQL would be a matter of creating an abstraction when accessing the data on the queries and mutations resolves. Not on our priorities for now but we're always open for contributions :)
Maybe mongodb will perform better, free of joins, than MySQL/Wordpress/whateverCMS... or maybe the data access pattern will suck and make it slow (and maybe it would be slow with a SQL db too, like other CMSs).
Ideally (in terms of performance), a single K/V request would be needed for each page, and the CMS would handle all the denormalization (and tens of thousands of req/s). I don't know how they've designed their data model...
All in all, a CMS is the most cachable web app ever, as it's more or less meant to replace static pages ;-) The poor performance of existing CMSs has always been hidden by caching layers...