- Article
- 4 minutes read
- Reviewed August 3, 2026
WordPress stores content as related records rather than complete finished web pages. The database holds content, settings, users, classifications and metadata, while uploaded files are normally stored in the filesystem.
Understanding this conceptual model helps explain why different post types can share APIs, why metadata is separate from the main content record and why deleting a plugin does not always remove the content it created.
The Posts Table as a Shared Content Store
Posts, pages, attachments, revisions and most custom post types are stored as post records. A post_type value identifies the kind of object, while fields such as title, content, excerpt, author, date, status and parent describe common properties.
This shared model allows WordPress functions and queries to work with many kinds of content. A custom post type does not usually receive a new database table simply because it has a new administration menu.
Metadata Extends an Object
Post metadata stores additional key-value information associated with a post ID. A property listing might use metadata for price, floor area and availability.
Metadata is flexible, but flexibility can produce inconsistent keys, formats and duplicated values. Important fields should be registered, sanitized and documented so every component interprets them in the same way.
Taxonomies Store Reusable Classification
Taxonomies and terms are stored separately from post records. A taxonomy defines a classification system, while terms are the selectable values inside it.
Relationship records connect a post to one or more terms. Because terms are reusable objects, they can have names, slugs, descriptions, parents and metadata of their own.
Users and Ownership
Users are stored in their own tables and can have separate user metadata. A post record can reference its author through a user ID.
Authorship is one relationship between users and content. Capabilities determine whether a user can read, edit, publish or delete particular content; those permissions are not stored as a simple field on each post.
Options and Configuration
Website-wide settings are commonly stored as options. Plugins may use options for configuration, but they should not treat a single option as an unlimited database for all content.
Options can be loaded automatically on requests, so storing large content collections in autoloaded options can create performance and maintenance problems.
Uploaded Files and Attachment Records
Media files are normally stored beneath the uploads directory. WordPress creates attachment records that reference the files and store descriptive information.
A database backup without the uploads directory is therefore incomplete, and copying files without their database records does not recreate the full Media Library.
Serialized and Complex Values
Metadata and options can store arrays or objects as serialized values. This is convenient for configuration, but individual values inside a serialized structure are difficult to query efficiently.
When information must be sorted or filtered independently, storing each queryable value in an appropriate field or relationship is usually clearer.
When Custom Tables May Be Appropriate
The standard post, taxonomy and metadata APIs are appropriate for many publishing models. A custom table may be justified when a project has very large transactional datasets, intensive relational queries, strict schemas or records that do not behave like content.
Custom tables increase implementation and maintenance responsibility. They require their own schema management, CRUD operations, permissions, APIs, backups and migration strategy.
Storage Is Not the Same as Presentation
The database does not store the final theme page as one record. WordPress queries data, selects a template and renders output for the current request.
This separation allows one content item to appear in a single template, archive card, search result, feed and REST response without copying the source information.
Practical Storage Principles
- Use post types for primary content objects.
- Use taxonomies for reusable classification terms.
- Use metadata for attributes belonging to one object.
- Register important metadata and document its expected type.
- Avoid placing queryable collections inside opaque serialized values.
- Keep files and database backups together.
- Choose custom tables only when the data and query requirements justify them.
Frequently Asked Questions
Are custom post types stored in wp_posts?
Standard custom post types are normally stored in the posts table and distinguished by the post_type column.
Where are custom fields stored?
Post custom fields are generally stored as post metadata associated with a post ID.
Does WordPress store images in the database?
The file itself is normally stored in the uploads directory. The database stores an attachment record, paths and related metadata.