I'm fairly new to writing wordpress plugins, but I've jumped in the deep end already and I want to make sure I'm doing it "right" on my upcoming big project.

I'm going to be heavily extending wordpress into a pretty big web app and want to keep my data structures as native as possible to rely on the wordpress framework, but I don't know if it is better to create my own custom database tables or try to make use of custom post types.

I don't know all my data yet, but there will be a number of tables (or cpts) relationally linked. I get the "vibe" from my research that I should avoid custom database tables, but I'm not sure how to determine the best solution.

Specifically I'm concerned about three areas:

  • the number of post metafields I'll need for my extra fields per cpt if I go that route, and if that will make things "tricky"
  • how well I can get back queries using semi complex relational filters for reports
  • how to best manage relationships, especially if I have many to many relationships

Is there a "right" way? Thanks for your input.

1 Answer 1


You should be skeptical of anyone who says that there is a single "right" way. The right way depends on the situation. Using the CPT infrastructure has a number of notable benefits:

  • You get the Dashboard UI for free
  • You automatically take advantage of WP's caching, including any persistent cache plugins that the installation may be using
  • You automatically get goodies like post revisions
  • You get access to the WP_Query class, which means that, in theory, you don't have to write any (or at least not much) likely-to-be-buggy-and-vulnerable-and-inefficient SQL
  • If you're planning on distributing the plugin or opening it up for open-source development, you may find that developers are more comfortable using custom post types and the associated API functions than your own custom stuff

The problems with the CPT API mostly stem from the fact that it is highly married to the metaphor of 'posts', and all the aspects of that data type that come along with the metaphor. From the MySQL command line, run DESCRIBE wp_posts. WP assumes that your content has a title, that it has a (single) author, that you only need to keep track of the created date and the last-edited date, that you'll need space for an unindexed post_content, etc. This works well for some kinds of content, but not necessarily for others. You've already gestured in the direction of some potential problems:

the number of post metafields I'll need for my extra fields per cpt if I go that route, and if that will make things "tricky"

There are two ways to augment the wp_posts schema through the CPT API: postmeta and taxonomies. Postmeta is unindexed key-value pairs, which is great for storing a bunch of miscellaneous data, but not at all optimized for doing complex lookups. Taxonomies are somewhat more flexible in this regard, but you'll still face lots of potentially costly subqueries if you have very complex lookups. (The meta_query and tax_query arguments and their query constructor classes are very nice and handy, though.)

If, as you suggest, you only need to do these kinds of "semi complex relational filters" in the case of occasional reports, then this architecture is probably OK for you. It's when you start exposing the filters to users, so that you have to run many complex JOINs and subqueries all the time, that things get out of hand quickly.

how to best manage relationships, especially if I have many to many relationships

Many-to-many relationships are a longtime sticking point in the WP dev community (see https://core.trac.wordpress.org/ticket/14513). You can fake it without using custom tables by mapping taxonomy items onto post_ids (so that, eg, you can say that 'P3 has the relationship Y to P5' by saying that P3 has the tag 'Y-P3') but this gets confusing (and inefficient) very quickly. You also may consider creating your own relationships table that links together CPTs - you'd still get the benefit of CPTs, and only be creating a single DB table. For a nicely-executed version of this method, see the Posts 2 Posts plugin: https://wordpress.org/extend/plugins/posts-to-posts/

So, in the end, you should decide based on:

  • The kind(s) of data you'll be storing - how "post"y are they
  • The kinds of queries that will be required - how complex will they be
  • Scale - how complex is your desired schema, how many total objects will you have, and how many users do you anticipate

If the answers are: Very posty, not too complex, and don't have to scale super-huge, go with CPTs. Otherwise consider your own tables.

  • 3
    Excellent summary.
    – JCL1178
    Apr 4, 2012 at 3:22
  • 1
    double that. well answered +1
    – kaiser
    Apr 4, 2012 at 14:13
  • Wow, great answer Boone, thank you! Very knowledgeable and well explained, with a very actionable summary checklist. I think this gives me the direction I need. Maybe I can make some of my objects cpts and others custom. I was considering the posts 2 posts style relationship table too to get get the best of both worlds. And you tip on the meta_query arg is great too!
    – Jeff
    Apr 4, 2012 at 16:58
  • 2
    This series by Pippin Williamson is definitely worth reading over if you're considering custom tables: pippinsplugins.com/series/building-a-database-abstraction-layer Oct 16, 2015 at 16:23
  • 12 years later this is still the best summary I have found. Too many developers are interested in convenience to develop and not performance. IMO, performance should be the number one question followed by convenience. WELL PUT Boone!
    – gwc
    Apr 24 at 21:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.