Pods 1.x

You may not have been aware of this, but Pods 1.x installs custom tables to store it’s information in a way that’s usually standard for standalone PHP projects. Here’s the table list we had in Pods 1.x, 7 core tables in all:

• wp_pod – This table was used to store an index of every pod item you create, along with some core information. It was like a ‘wp_posts’ table in a way. It wasn’t my decision but I believe the reason behind it was the same as wp_posts, but it could also have been the fact that the old Manage Content interface had all of the items together (but filterable by pod), which proved to be harder to manage in certain circumstances. Since around Pods 1.10 when we merged Pods UI, our interface has been separated out for a better UX while the table itself remained in place.
• wp_pod_types – This table was used to store a list of all of the Pods you created and their corresponding options.
• wp_pod_fields – This table was used to store a list of all of the fields for the Pods you created and their corresponding options.
• wp_pod_templates – This table was used to store a list of all of the Pod Templates you created.
• wp_pod_pages – This table was used to store a list of all of the Pod Pages you created.
• wp_pod_helpers – This table was used to store a list of all of the Pod Helpers you created.
• wp_pod_rel – This table is used to store a information on each relationship or file field you have for a pod, on a per-item basis. It makes it easy (and perform better) for MySQL queries to do more complex things with fewer joins and hacks.
• wp_pod_tbl_* – These tables are created for every Pod you create. Every non-relationship and non-file field you create, gets it’s own table column sculpted around the field type it is. A number field becomes a number column, a date field becomes a date column, and so on.

Pods 2.0 Alpha

In Pods 2.0, we set out to develop code that performs better and to optimize our database table structures. In that process, we reduced the number of tables substantially down to 4 core tables in all:

• wp_pods – This table was used to store a list of all of the Pods you created and their corresponding options.
• wp_pods_fields – This table was used to store a list of all of the fields for the Pods you created and their corresponding options.
• wp_pod_objects – This table was used to store a list of all of the Pod Templates, Pages, and Helpers you created.
• wp_pods_rel – This table is used to store a information on each relationship or file field you have for a pod, on a per-item basis. It makes it easy (and perform better) for MySQL queries to do more complex things with fewer joins and hacks.
• wp_pod_tbl_* – These tables are created for every Pod you create or extend (opt-in, the default is to not create a new table and use native meta-based storage). Every non-relationship and non-file field you create, gets it’s own table column sculpted around the field type it is. A number field becomes a number column, a date field becomes a date column, and so on. The old Pods 1.x wp_pod table was merged into these, so each pod table is exactly what you want and need, letting you remove the name, created, updated, and author fields for the content types that don’t need it.

Pods 2.0 Alpha 32

While developing Pods 2.0, Automattic started giving us attention and moved forward to officially sponsor our development. We consulted with their server team over at their VIP hosting platform and determined that some of our 2.0 tables could be reduced even further. As a result, Pods 2.0 as of Alpha 32 now has only 1 core table in all:

• wp_pods_rel – This table is used to store a information on each relationship or file field you have for a pod, on a per-item basis. It makes it easy (and perform better) for MySQL queries to do more complex things with fewer joins and hacks.
• wp_pod_tbl_* – These tables are created for every Pod you create or extend (opt-in, the default is to not create a new table and use native meta-based storage). Every non-relationship and non-file field you create, gets it’s own table column sculpted around the field type it is. A number field becomes a number column, a date field becomes a date column, and so on. The old Pods 1.x wp_pod table was merged into these, so each pod table is exactly what you want and need, letting you remove the name, created, updated, and author fields for the content types that don’t need it.

Where did they all go? They’re now stored as post types and custom post meta fields. Don’t worry, you don’t have to learn new code, our API remains the same and you can now utilize our API to do even more. We interface with WP_Query and the WP object post/meta update functions. We’re also storing full Pods and their options in transients for even more performance and less MySQL queries per page.

• _pods_pod – Pods and their options
• _pods_field – Pod fields and their options
• _pods_object_template – Pod Templates and their options
• _pods_object_page – Pod Pages and their options
• _pods_object_helper – Pod Helpers and their options

Tableless Mode to be introduced in Pods 2.1

It’s still not ready for primetime on the VIP hosting service, but in Pods 2.1, we’ll make our custom core tables completely optional. Individual Pod tables are already only created as an opt-in process when creating / extending content types in Pods 2.0, so that option will be removed if the tableless mode is enabled in 2.1. The wp_pods_rel table will also not be created or used, and instead the native meta tables for each content type will be used to store that relationship information. Pods 2.0 already stores a backup copy of relationships in wp_postmeta to make that transition easier.

We’re looking forward to further improving Pods throughout 2.x, thanks for hanging in there throughout our ever evolving project.