Meanwhile, my Django sites have response times in the 10-20ms range. (And that's without caching.)
[1] https://github.com/ronaldbradford/schema/blob/master/wordpre...
[2] https://codex.wordpress.org/images/2/25/WP4.4.2-ERD.png
[EDIT: Corrected myself about the number of KV tables]
wp_options is a key/value table, and seems to be abused a lot.
storing "transient" data in wp_options - what's up with that? why not at least have a 'transient' table, separate from the table that stores my ... options?
and... when you've got plugin systems that store everything in postmeta... it's hard to do "normal" relational queries. woocommerce seems to be a good example of this - order info in postmeta?
"find all orders in tennessee with more than $10 tax"
can only be done with multiple self-joins on wp_postmeta.
Perhaps they shouldn't have built it that way, but in my experience most plugin authors use what's provided, and what's provided makes them jump through hoops to do basic stuff, and is not well suited for larger scale apps (but people get suckered in to it anyway because it's "easy to get started"). Who do you blame for these decisions/mistakes? WP? Plugin authors? End users?
That's where the meat is. Literally, if you're an e-commerce deli.
I'm not terribly concerned about WP performance, it's just a blog, after all - it's the security issues.
Isn't that the crux of the whole NoSQL "revolution"?
That's why the term "NoSQL" (or even worse: "non-relational") is often pretty much useless: many people think it refers to one category of databases like SQL/relational does.