Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"Everything is a key-value pair" is flat out wrong[1,2]: There are four key-value tables (commentmeta, postmeta, termmeta and usermeta), but most of the meat of Wordpress is stored in regular tables.

[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]



if you're just using WP as a blog engine only, with basic functionality, you're fine. that's what it was built for, and shines.

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?


I see your point and share your pain about key-value tables in SQL systems.


Those 4 tables are where all the add-on data goes, for anything that's not a blog.

That's where the meat is. Literally, if you're an e-commerce deli.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: