WordPress stores custom fields in wp_postmeta as separate rows, an entity-attribute-value structure that lets plugins add fields without changing the database schema. The flexibility has a query cost: filtering or sorting by several meta values can require repeated joins, while unindexed LONGTEXT values complicate numeric comparisons. At scale, fields from WordPress core, page builders and other plugins also add rows to the shared table.

A JetEngine property-site example illustrates the accumulation: 21 published properties with 15 custom fields each account for 315 rows, but the records contain 751 metadata rows across 48 keys. JetReviews, WordPress core, geocoding and other plugins contribute the remainder. The example is modest in size, but it shows why metadata volume and query patterns can matter as custom post type datasets grow.

JetEngine’s Custom Meta Storage moves fields configured for a post type into a dedicated table, with a column for each field and the post ID as the key; the post itself remains in wp_posts. The option is available under Post Types > the relevant post type > General Settings. Existing values are not automatically moved: posts must be resaved or migrated with SQL, and field names containing hyphens may remain in wp_postmeta. Standard functions such as get_post_meta and update_post_meta remain usable, while metadata added by other plugins continues to use the standard table.

Author of the original text: Helena Ivanova (Crocoblock)