WordPress Database Structure Explained

WordPress stores most content, settings and relationships in a relational database.

The table prefix is configurable, so code should use the properties provided by the global $wpdb object rather than hard-coded names.

Core Content Tables

wp_posts stores several object types, including posts, pages, attachments, revisions and custom post types.

wp_postmeta stores key-value metadata associated with those objects.

This flexible model supports many features but can become inefficient for large analytical or transactional workloads.

WordPress separates terms, taxonomy context and object relationships.

The principal tables are:

A term name can participate in a category, tag or custom taxonomy context.

User records are stored in wp_users, with additional data in wp_usermeta.

Comments use wp_comments and wp_commentmeta.

In Multisite, users are generally shared across the network while capabilities and site relationships are represented through metadata.

wp_options stores site-level settings and cached or operational data.

Selected options can be autoloaded during many requests. Large values and uncontrolled option creation can affect performance and maintainability.

A custom table can be appropriate when data has:

A custom table also requires schema versioning, migrations, deletion policy, backup coverage and API ownership.

Multisite adds network-level tables and creates site-specific table sets for each additional site.

Code must distinguish network data from site data and switch context carefully.

dbDelta() can create and update plugin tables, but it has formatting requirements and is not a complete migration framework.

Store a schema version and run explicit, testable upgrades.

No. The table stores several object types identified by post_type.

No. Evaluate access patterns, volume, relationships and lifecycle first.