Custom Database Tables by JetEngine and Metabox Plugins Compared

A well-planned website data structure is key to good performance and makes it easier to build on and add features later. If the structure is poorly done, adding new functionality can cause performance issues, and you might end up redoing the whole project from scratch.

Using custom tables in WordPress is a great way to boost overall performance.

Table of Contents

• Why Could Custom Tables Be a Game Changer?
  • Benefits of using custom database tables for WordPress websites
  • When not to use custom database tables
• MetaBox Custom Tables Extention Overview
  • Models
  • Querying data from MetaBox custom tables
• JetEngine Custom Database Tables Feature Overview
  • Custom Content Types
  • Custom Meta Storage
  • Querying data from JetEngine custom tables
• JetEngine vs. MetaBox Custom Database Tables Functionality Comparison
  • MetaBox vs. JetEngine custom database tables structure
• FAQ
• Takeaway

Why Could Custom Tables Be a Game Changer?

Let’s start with the basics, which would be very useful for WordPress newcomers. If you are a seasoned user, just scroll to the next paragraph.  

Any CMS, including WordPress, uses the relational database type with its predefined schema to efficiently interconnect all the data on the website. 

This is the default database tables that every WordPress website has after the installation:

• wp_posts – stores posts, pages, and other custom post types;
• wp_postmeta – stores metadata for posts (default and custom meta fields);
• wp_users – stores user information;
• wp_usermeta – stores metadata for users;
• wp_comments – stores comments;
• wp_commentsmeta – stores metadata for comments;
• wp_term_taxonomy – is used for taxonomies;
• wp_terms – is used for taxonomy terms;
• wp_termmeta – are used for term meta fields;
• wp_term_relationships – links terms to posts;
• wp_options – stores global data;
• wp_links – the table that is almost never used nowadays. 

After adding some plugins, creating additional post types, or creating other elements programmatically, other tables are added to this default structure. 

The wp_postmeta is most commonly the largest database table due to extensive use by custom fields and plugins. It grows because it stores metadata for all post types (posts, pages, custom post types including WooCommerce products, orders, etc.). Each custom field value or additional attribute is stored as a separate row. These are examples of data stored there in addition to default fields:

• custom fields (e.g., product prices, user preferences);
• WooCommerce data (e.g., product attributes, variations, order details);
• plugin-specific data (e.g., SEO metadata, form submissions).

Now, let’s do the math: each default post or page can have three to five default fields. Let’s say we need another five custom fields, so there are at least eight in total. 

As a result, if there are 1000 posts with five custom fields each:

• standard metadata: around 3000–5000 rows;
• custom fields: 5000 rows;
• total: 8000–10,000 rows.

Now, if you need to query a meta field across all posts (e.g., using meta_query to find specific values), the database may need to scan the entire table, and it can lead to performance bottlenecks when querying large datasets.

The wp_posts table can also become really big, as it stores all content types, including posts, pages, custom post types, revisions, menus, attachments, etc.

Revisions can quickly inflate this table, especially if they are not limited. Media-heavy sites also contribute significantly to its size.

Actually, almost every database table can grow quite large over time, which may lead to performance issues. 

There are other challenges with default tables, for example:

• complex queries – meta queries often require multiple JOINs between wp_posts and wp_postmeta, which can be resource-intensive;
• limited flexibility – the default schema is not optimized for custom relationships or highly specific data types.

Long story short, if you create a simple website, stick to the default schema. But if you plan to have a content-heavy website with complex structure and good scalability, consider using custom database tables. They address the challenges I’ve mentioned above by allowing you to store data in a dedicated table with a schema tailored to your project’s needs. This eliminates the need for heavy meta queries and ensures faster data retrieval.

In the example above, where 1000 posts would result in 8000-10000 rows when the default WordPress tables are used, a custom table will store them in just 1000 rows (if one post takes just one row – all the custom fields are stored in that row) or 2000 rows – if posts are stored in the wp_posts table and all the custom fields in the custom table. 

Benefits of using custom database tables for WordPress websites

There are many benefits to using custom tables, but it’s important to carefully plan your website structure to make the most of each feature. Here’s a checklist to guide you. 

Let’s get back to the main topic. Here are eight main benefits of using custom database tables. 

1. Performance optimization.
   By default, WordPress stores most data in the wp_posts and wp_postmeta tables, which can become bloated as your site grows. Custom tables let you avoid overloading these default tables, leading to faster queries and improved performance, especially on large sites.
2. Efficient data management.
   With custom tables, you can structure your data logically, making it easier to retrieve and manipulate. For example, if you run a directory or a membership site, custom tables can store user-specific data (like membership levels or directory entries) in a clean and organized way.
3. Scalability.
   As your site scales, custom tables handle large amounts of data better than the default WordPress schema. Instead of performing complex and slow meta queries, you can use direct database queries optimized for your custom table structure.
4. Improved query speed.
   Standard WordPress queries often join multiple tables, like wp_posts and wp_postmeta, which can slow down the database. Custom tables reduce the need for these joins, resulting in faster query execution.
5. Flexibility for complex applications.
   Custom tables allow developers to design a database schema that meets the application’s requirements. They are particularly useful for advanced features like reporting, analytics, and custom data relationships.
6. Reduced risk of data clutter.
   Keeping unrelated data out of the default tables avoids clutter and makes it easier to maintain the database. It also reduces the risk of conflicts when WordPress core updates or plugins modify the default tables.
7. Better control over data.
   Custom tables give you control over how data is stored, indexed, and queried. This control allows you to fine-tune your database for better performance and reliability. You can also define custom indexes and data types that align with your application’s needs, which is not possible with WordPress’s default structure. 
8. Easier maintenance and export/import of the table.
   Debugging or maintaining a database with custom tables is often simpler since the data is well-organized and purpose-built. You can easily archive or delete outdated data without worrying about breaking WordPress’s core functionalities.
   Also, you can easily import and export such tables.

As you can see, custom tables are a really cool asset. They are especially useful for use cases like job boards, booking systems, or inventory management, where standard tables don’t fit well. Also, they come to the rescue when your application requires relationships that are not supported by the default WordPress schema.

When not to use custom database tables

The idea here is quite straightforward: 

• They are not for simple use cases where default WordPress structures are sufficient.
• If your project doesn’t require performance optimization or custom queries, custom tables might be overkill.
• If you’re relying heavily on plugins that may not support custom table integration.

MetaBox Custom Tables Extention Overview

MetaBox is a popular plugin for managing highly dynamic WordPress websites. Actually, it’s more a framework for developers than anything else. 

While it’s marketed as a freemium plugin, its free version offers only basic, limited functionality. The full value of MetaBox comes from its premium (and quite pricy if bought separately) modules. 

This plugin is better suited for experienced developers who can fully appreciate its features and approach, and I guess beginners might find some of its tools and interface overwhelming.

MB Custom Table is the add-on for creating custom tables for custom field sets. After the installation, you will see the option to store the fields in a custom table in MetaBox > Custom Fields > [your field group] > Settings tab. There, activate the Save data in a custom table toggle, create the table name, and activate the Create table automatically toggle. 

When you start adding data to the corresponding custom fields, you will see a new database table appear (if you check it with phpMyAdmin). You can add custom fields with custom tables for their storage to: 

• posts (any post type);
• users;
• comments;
• taxonomies.

Models

In case you don’t need to display data on the front end, the best solution is to create a custom model. 

Custom models let you store data in custom tables instead of relying on WordPress’s default tables for posts, terms, or users. They work like WordPress posts but keep all the data in one table, making things more efficient and easier to manage.

Pros:

• With custom models, you can create a table that perfectly suits your needs, keeping things clean and separate from WordPress’s core tables. You also get full control over your data, with features to create, edit, or delete models quickly. 
• They work with all MetaBox field types and have a familiar interface, so managing them feels like managing regular WordPress content. Plus, they work great with the MB Admin Columns extension, which allows you to show fields directly in the admin area.

Cons:

• The downside is that custom models don’t have front-end templates like posts do, so you won’t get permalinks or archives for them. They’re best for managing data behind the scenes. If you need templates or public pages, sticking with standard custom tables connected to WordPress is a better choice. 
• Another drawback of models is limited compatibility with some MetaBox extensions such as MB Relationships and MB Views.
• Handling models is possible only with code; there’s no UI. 

Here is an example of code for registering a model:

add_action( 'init', function() {

    mb_register_model( 'transaction', [

        'table'  => 'transactions',

        'labels' => [

            'name'          => 'Transactions',

            'singular_name' => 'Transaction',

        ],

        'menu_icon' => 'dashicons-money-alt',

    ] );

} );

Then, you should register a custom table and programmatically add fields to it. The good news is that you can easily find the code examples in the documentation. 

Querying data from MetaBox custom tables

To fetch data from fields stored in MetaBox custom tables, you will need this helper function:

$args = [

    'storage_type' => 'custom_table',

    'table'        => $table_name,

];

$value = rwmb_meta( $field_id, $args, $post_id );

echo $value;

Alternatively, you can use a shortcode: 

[rwmb_meta id=”field_id” storage_type=”custom_table” table=”table_name”] 

If you want to use WP_Query, you will first need to create an extra query to hook post IDs.  

Fetching data from a model is quite traditional:

$value = rwmb_meta( $field_id, [

    'object_type' => 'model', // Must be 'model',

    'type'        => $model,

], $model_id );

// Example: returns 'Completed'

$status = rwmb_meta( 'status', [

    'object_type' => 'model',

    'type'        => 'transaction',

], 3 );

JetEngine Custom Database Tables Feature Overview

There are two ways to create custom database storage using JetEngine: 

• by using the Custom Content Types (CCT) module;
• by checking the Custom Meta Storage toggle when creating a set of meta fields for a post type. 

Custom Content Types

JetEngine’s Custom Content Types (CCT) module has been around for a few years, and the Custom Meta Storage for posts was introduced quite recently. CCT is similar to the MetaBox module, but you don’t have to write any custom code to activate it, as it has a convenient UI, so you create the CCT entity and a set of fields just like you do it for custom post types. 

Things to know about CCT:

• CCT uses custom tables by default.
• It doesn’t have a single page, but you can connect it to the existing post type and map which fields will be replaced by the CCT data.
• You can easily set up admin columns and adjust the quick edit functionality for CCTs. 
• You can easily export data to a CSV file by pressing the “Export items to CSV” button. 

Custom Meta Storage

Now, let’s move on to the Custom Meta Storage for posts. You can select an option to store meta fields in a custom table for custom and default post types. Go to JetEngine > Post Types, and you will see a switcher at the top to see all post types. They are supported to add fields and store them the way you want. 

Querying data from JetEngine custom tables

JetEngine has a unique Query Builder tool for visually querying any data from a database without any coding involved: just select the parameters you need and get a result. 

You can also create complex SQL queries using this tool. Merged and combined queries are supported as well.

After querying data, you can create a loop template (in JetEngine, it’s called a Listing Template) for posts or CCTs and then display them on the templates. 

Queried data is also available when creating Single/Archive templates. 

JetEngine supports Elementor, Bricks, Block Editor, and Timber/Twig, so the process doesn’t require PHP knowledge. 

However, if you want to use the CCT data in PHP templates or any custom builder, there is a shortcode generator (JetEngine > JetEngine > Shortcode Generator tab). Also, these developer docs might be useful.

JetEngine vs. MetaBox Custom Database Tables Functionality Comparison

JetEngine and MetaBox are two plugins that can handle manipulations with custom post types and custom fields efficiently. 

However, they take different approaches – while MetaBox is more a framework and requires at least basic programming skills, JetEngine offers an intuitive UI to handle everything visually, from the first step of adding custom fields to querying data using the handy Query Builder. Thus, programming skills are not required at all. 

But for now, let’s examine the custom database structure both plugins create. 

MetaBox vs. JetEngine custom database tables structure

MetaBox uses the ID column as a unique identifier in the table. It corresponds to the post/user/taxonomy ID to which the fields are related (or it’s a unique ID if it’s used as a custom model). Then, we have columns with custom fields you’ve added. 

JetEngine offers a slightly different approach if it’s a custom table for posts. Its data structure is more comprehensive, as two identifiers are used: meta_ID and object_ID. Meta_ID is what MetaBox doesn’t have: the unique ID for each row. Object ID corresponds to the post the field is related to. This approach gives more flexibility for complex data relationships and more freedom in querying data, which is especially useful for large and complex projects. 

But for CCTs, JetEngine uses only IDs, keeping it simple. 

If you connect a related Single, there’s one more column for the related post IDs:

FAQ

Takeaway

In this article, I discussed the advantages and use cases for using WordPress custom database tables and powerful instruments for adding and managing them: JetEngine and MetaBox plugins. 

Both plugins get the job done but take slightly different approaches. 

If you need a framework and aim to incorporate custom post types, fields, and other entities directly into your PHP code, MetaBox might be your first choice.

However, if you prefer an intuitive GUI for even the most complex tasks or work with Elementor, Bricks Builder, the Block Editor, or Twig, JetEngine is the better option. One more advantage here is the ecosystem of 20 more Crocoblock plugins that are seamlessly compatible with the data structures created with JetEngine.