Yes, it’s lack of support per my understanding (from Bricks’ part). But I ended up not using a custom table anyway, as a kind WP expert told me there are no meaningful advantages of using it. I will paste his replies below, so people can benefit:
Absolutely do not use a custom table. First you can’t just use a custom table. There is really no way to get around WordPress using default post meta tables to store the basic post relationship meta like _postmeta, _posts, _termmeta . . . I can go on and on.
Unless the custom table addon has changed, the default behaviour of it does not allow you stop using the built in WordPress tables like _postmeta. So a post that saved fields to a custom table also saves the default WordPress tables.
The custom table addon is not a replacement for WordPress default db tables. It’s meant as a way to save fields that would otherwise be saved as post meta and options separately from the post. For example, it you build a plugin and have fields that are not post related you can create a private table and store the data there as opposed to storing it in the default options table.
Wordpress can handle hundreds of thousands of posts just fine. There are years of case studies proving this.
You haven’t provided enough data to even say you need a super host or a “separate db server.” That is determined by the total payload of the db get requests and site traffic.
In the last 17 years I have not had an instance where I needed a seperate server for the db. Generally a host that is setup for high use sites will manage that for you. Meaning there arectiture is setup with option to throw more memory or processors at the db. I have had separate db servers, but that was part of the hosting package. Not a design requirement.
If your site will be subject to slow db transactions consider an amazon server instance. Otherwise I have had sites thats do hundreds of thousands of dollars a month never need a full db instance. This includes full on directory search sites.
I assume you meant to use a comma not a dot and it’s 50K to 100K posts. That is noting for WordPress.
then he continued (another reply to my question):
I can’t see any reason to use a custom table. There is really no advantage. Plus your CTPs will still have data in the default WordPress tables so you not really circumventing anything your just adding a second lookup because meta like post id, title, etc., etc. will still force a lookup on the default WordPress tables. 12 fields is nothing. Especially, if you just displaying a single post.
If you are displaying posts in the loop and need filertig a custom table will do nothing “really.” In this case the fact tool you use + caching will way more than sufficient because queries can cached.
Agin 50K posts is not a big deal at all.
another one:
It’s a false positive on hype mostly spread by non-developers and repeated because the addon description talks about offering a speed advantage to using a custom table.
There is no meaningful difference between fetching data from a custom table via wpdb{} verses fetching data from a post table via get_post_meta{}.
Custom tables are great when data is not directly post related or you need to organize it differently then stacking it within the post options.
There is so much to consider when thinking about performance for fetching data and how to mitigate speed when it’s an issue. Like, if it really matters you can store all 12 fields in an array and store the array in a single field, that is if you really need all 12 fields every time a page is loaded. You can use WordPress transients to cache, you can pre-query data and cache it when queries are large enough to cause a lag, is the data mostly displayed in the admin or public facing site of the site, etc.
In my opinion your performance focus should be on page load time and traffic frequency not how many posts or fields. If there is a lag in page load then it’s time to develop a performance plan. Unless you know for sure that you will have a huge amount of traffic and high cpu cycles than build your site normally meaning use the default WordPress structure.
Then someone else asked him about use cases for a custom table… Here’s the reply to that:
Mostly when I code a custom feature that is not so much post related or a feature that is more computationally/data mapping like the _term_relationships table or specific plugin features; however, dumping custom fields in the _options and _postmeta tables is perfectly fine. So is dumping the fields for a settings page into the _options table.
I prefer to go the the _postmeta table when I want to get any fields from a post. Or I store purchase invoice #'s directly in the users profile instead of a custom mapping table.
I always prefix my custom fields with “_” so they don’t show up in the custom fields post edit page followed by a unique ID so I can do a wildcard search in the db to find every custom entry like "%wppasc%.
Or if I want to get all the purchases a user has made (or whatever) I can get the info with one call as opposed to getting the user ID and passing passing it to a custom table search queries for all their purchases or whatever I store in there.
Bottom line if you don’t have a solid and sound reason to store data in a custom table, don’t. Most likely the data will fit just fine in a default WordPress table.
You will know for sure when it’s time to use a custom table.
