I am in the process of writing a plugin that allows end-users to submit a form that includes customer information. Upon submission, I am notified that a new customer has submitted the request form. If I approve the account, I am going to create a WordPress user account.

I am at the beginning stages of this plugin and want to know if I should use custom database tables to store my user information, or if I should go the route of just simply using a custom post type and adding meta-data to the post type?


Wow, down-vote already! Anyway, an update to my question, let me word it this way...I have now attempted to create a custom post type of customer, and for customer, I wanted to only have a meta-box that contained First Name and Last Name. When I did this and disabled all of the supports options for the custom post type, it was a nightmare listing the posts due to the missing Title value. It would always set the Title to "Auto-Generated" and that doesn't work for me. I ran into this GREAT Plugin (super-cpt) that makes the creation of custom post types and meta-boxes a breeze.

So, I'm not so sure custom post types will work for me since so much custom UI work needs to be done to convince the front-end and admin dashboard to work for me. I'm leaning more and more on custom data tables but would like more info on customizing the edit form for a custom post type. Anyone have a link they could share?

  • If you need help with your custom post type form, make a new question or edit this one to reflect that. So far it seem you are only asking for advice, not tech support.
    – Androliyah
    Commented Feb 27, 2013 at 12:43

2 Answers 2


I don't know if we are allowed to link to other answers but there is another question very similar to yours and the accepted answerer stated these things:

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.

source: Here

  • I actually saw that post this morning but didn't really know if there were any limitations on a custom post type vs. using database tables and wanted to get some opinions. But, I guess yours is as good as any. Thanks!
    – clockwiseq
    Commented Feb 26, 2013 at 17:21
  • 1
    I vouch for CPT's. A Major BuddyPress Plugin was once DB driven and recently migrated to CPT to allow super flexibility. Its much better than it was before, plus, because it is now CPT driven, it can be used with or without BuddyPress (it used to be BuddyPress only)
    – Androliyah
    Commented Feb 26, 2013 at 17:43
  • Anyway there is no rush. You can wait for others to answer and then click to accept the answer you like best. As the other answer said, there is no one 'right way'.
    – Androliyah
    Commented Feb 26, 2013 at 17:44
  • 1
    I'd say we are encouraged to link to other Q&A's! Simply grab the Question permalink, in the share button, paste in your Answer and it will render the Q title automagically. This doesn't work for A's, though. The linked Q&A also shows up in the Linked column here at the right.
    – brasofilo
    Commented Feb 27, 2013 at 5:29

If there is more than 1-2 meta related to your custom post type, the possibility (or necessity) of complex user searches based on that custom data, then custom table. Otherwise complex JOINs done on meta tables to pull posts by querying 2-3 criterion at the same time on meta table will slow the site down. Considerably, based on concurrent users. If you have ~5,000-10,000 such data entries, you will enter a query hell.

If around 1-2 meta, OR, there wont be complex user searches for your meta data, and the data does not need to be displayed dynamically (can be cached without loss of user experience), then go with WP's post and postmeta.

Incidentally you can also do something quite out of the way, you can create a custom table to mirror all your post entries with its complex meta data in a flat, relational table and hook to search function (or other necessary functions) to do the search from this custom 'search cache table' and then go read the result set from wp_posts and wp_postmeta, you can go with wp tables for massive complex data sets as well. But then you will need to divert any problematic query operation to this cache table of yours.

I believe popular search plugin Relevanssi does something like that - cache complex post and postmetas in a flat, relational table and pull out search results from there.

*correction - incorrect: relevanssi does not create a datastore for faster search. It just improves the search quality.

But really, that's going too out of the way in my opinion. Just go with separate tables if your data is big and complex.

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.