Skip to main content
Easy Digital Downloads Documentation
Documentation, Reference Materials, and Tutorials for Easy Digital Downloads

Database Table Structures

Easy Digital Downloads (3.0+) and it’s extensions take advantage of custom database tables to ensure that we can provide a scalable solution that offers complex reporting features. Below is a list of our custom database tables that we use and their schema. While we attempt to maintain this list, there may be slight differences as we find improvements, and the most recent database table schema can always be found in EDD core’s codebase on GitHub.

All example tables here are prefixed with the standard wp_ table prefix. Your table prefix may be different.

Our ‘meta’ tables follow the standard format of the standard WordPress Meta table format, and consist of an ‘id’ column that is Auto Incremented, an ‘object ID’ column (the column name may differ depending on the object type), a meta key, and a meta value. The meta tables are registered with the WordPress Meta API for the object types.

Easy Digital Downloads Core

Order Data

These tables hold the transactional order data including the order overview, transaction IDs from the gateway, items ordered, any physical address information related to the order, and adjustments made to the order (IE: Taxes, discounts, fees)


This table is the primary storage for an order record.


Holds any meta data about the order, so that developers can extend EDD.


This table contains a record of any transaction IDs from the payment gateway for safe keeping. Since an order can have multiple transaction IDs or have no Transaction ID at all, they are stored separate of the orders themselves.


This is the ‘cart details’ of an order, containing a list of downloads that were purchased.


If a developer needs to add specific items to the order item, it can be done here. Previously this would have been the ‘options’ array on the order item.


Adjustments are anything non-product related that affect the contents. This means (but is not limited to) discounts used, taxes collected, or any fees associated with the order.


Allowing developers to extend adjustments, this table contains the meta for the individual order adjustments.


As a customer may use different addresses for each order, we maintain a list of physical addresses used on each order, to aid in reporting. This can also be extended to add supplemental addresses (like shipping addresses) for extensions like ‘Simple Shipping’.


EDD uses a ‘notes’ concept to be able to store a thread of information about a specific object. For example, orders or customers. Notes are similar to WordPress comments, however, since notes are inherently not a public data set, we created a custom table for them, instead of including them as a custom comment type, in order to aid in front end performance.


Many objects in EDD have notes, like customers and orders. This table holds the note information.


If additional details need to be stored on a note, the meta table can be used.


As an eCommerce platform, we understand that keeping logs of events on your store is important. Logs can help you resolve customer issues, detect fraud, and provide evidence for things like disputes and customer support.


This is the generic logging database table, which can be used to log any information necessary that does not have a specific table.


Logs can contain meta to provide additional informaiton.


This is the record of each file download that happens.


Any additional file download information can be saved in this meta table.


This table holds a record of any API requests that have been made to the EDD REST API.


If any additional information is needed, it can be stored as meta.


EDD treats customers separate of WordPress users, as a store can allow guest purchases. The customer is our canonical reference point for who orders belong to.


This table contains the main customer record.


Any additional information about a customer that does not have a column can be saved as meta.


As a customer may use different email addresses for subsequent purchases, we maintain a list of email addressers associated with each customer.


As a customer may supply different physical addresses for each purchase, we also maintain a list of all physical addresses a customer uses and associate them with their customer ID.


In EDD, we treat any non-product modification to an order as an ‘adjustment’. This currently includes (but is not limited to, in the future) discounts codes (coupons) and tax rates.


The primary table for adjustments.


If any additional data is needed to be stored, meta can be used by developers.