WordPress Default Tables Explained

·

·

When you install WordPress, one of the first things it does is create a set of default database tables. These tables act as the foundation for storing your website’s content, users, comments, settings, and much more.

Understanding these tables helps you:

  • Troubleshoot database errors
  • Optimize performance
  • Safely customize your site with plugins or custom queries

In this article, we’ll break down all 12 default WordPress tables so you know exactly what each one does.


📌 Overview of WordPress Default Tables

WordPress uses MySQL (or MariaDB) to manage its database. By default, it creates 12 tables with the prefix wp_ (unless you changed it during installation).

Here’s the full list:

  1. wp_posts
  2. wp_postmeta
  3. wp_users
  4. wp_usermeta
  5. wp_comments
  6. wp_commentmeta
  7. wp_terms
  8. wp_termmeta
  9. wp_term_taxonomy
  10. wp_term_relationships
  11. wp_options
  12. wp_links

Let’s dive into each one in detail.


1. wp_posts

This is one of the most important tables. Despite its name, it doesn’t just store blog posts.

Stores:

  • Posts
  • Pages
  • Revisions
  • Custom post types (e.g., products, portfolios, events)

Key columns:

  • ID → unique identifier for each post
  • post_title → title of the post/page
  • post_content → main body content
  • post_status → published, draft, pending, etc.
  • post_type → post, page, or custom type

👉 Anytime you create or edit content in WordPress, it goes here.


2. wp_postmeta

This table holds extra information about posts.

Example:

  • SEO plugin data (meta descriptions, keywords)
  • Custom fields (price, rating, etc.)
  • Featured image IDs

Key columns:

  • post_id → links to wp_posts
  • meta_key → name of the custom field
  • meta_value → the field’s value

👉 Without this table, WordPress wouldn’t support custom fields or plugin data.


3. wp_users

This table stores information about all registered users.

Stores:

  • Username
  • Encrypted password (hashed)
  • Email address
  • Registration date

👉 Each user has a unique ID that links to other tables.


4. wp_usermeta

Just like wp_postmeta, this table stores extra data about users.

Examples:

  • User roles (administrator, editor, subscriber)
  • Plugin-specific settings
  • Profile options

Key columns:

  • user_id → links to wp_users
  • meta_key → name of the option
  • meta_value → the stored value

5. wp_comments

This table handles all comments left on posts/pages.

Stores:

  • Comment text
  • Comment author name/email
  • Comment approval status (approved, pending, spam)
  • Post ID the comment belongs to

👉 If comments are enabled, every new comment goes here.


6. wp_commentmeta

Stores metadata related to comments.

Example:

  • Spam detection flags (from plugins like Akismet)
  • Extra plugin data about comments

7. wp_terms

This table contains categories, tags, and custom taxonomies.

Examples:

  • Blog categories (News, Tutorials)
  • Tags (SEO, WordPress, Marketing)
  • WooCommerce product categories

8. wp_termmeta

Stores extra information about terms.

Example:

  • Category images (added by plugins)
  • Custom taxonomy metadata

9. wp_term_taxonomy

Defines the type of taxonomy for each term.

Example:

  • Category
  • Tag
  • Custom taxonomy (like “Genre” for movies)

👉 It connects terms (wp_terms) with taxonomies.


10. wp_term_relationships

This table links posts to categories and tags.

Example:

  • A blog post assigned to “WordPress” category and “SEO” tag → stored here.

👉 Think of it as the “bridge” between content and taxonomy.


11. wp_options

This table stores site-wide settings.

Examples:

  • Site URL
  • Active theme
  • Plugin configurations
  • Widget settings

👉 It’s one of the most commonly used tables for plugins.


12. wp_links

Originally used for the “Blogroll” feature (deprecated in modern WP).
Some plugins may still use it to manage external links.


📌 Why Should You Care About These Tables?

  • Performance → Cleaning unused data keeps your site fast.
  • Security → Understanding what’s stored where helps prevent vulnerabilities.
  • Customization → Developers often query these tables directly for advanced features.