Advanced Custom Fields Scalability

it's limits and why we decided not use it for GeoDirectory...
Advanced Custom Fields Scalability limits

Advanced Custom Fields is fantastic plugin used by millions that converts WordPress into a full stack CMS, allowing to create unlimited custom field groups, types and add them to any type of custom post type. However not many know about Advanced Custom Fields Scalability limits.

Quite often we get asked if GeoDirectory uses Advanced Custom Fields to manage listings custom fields. When we we reply that GeoDirectory has its own Custom Field System built in, they wonder why we decided to “reinvent the wheel”.

While the answer for us is crystal clear, Advanced Custom Fields Scalability is quite limited when it comes to building directories. We thought that maybe, being users, they are not aware of what is going on under the hood and about the scalability challenges that a web directory could present.

However, not too long ago, we stumbled upon a poll on a popular WordPress group on Facebook, where the option to vote for the “Best Directory” were : GeoDirectory, a few other Directory Themes available on popular marketplaces and there was also the option ACF + FacetWP.

When we saw the results, we were perplexed to say the least, ACF + FacetWP had a lot more votes than we would have thought.

People who voted were not supposed to be just simple users, but website developers and WordPress experts.

For this reason we decided it was time to explain why it is NOT a good idea to use Advanced Custom Fields for a directory and why Webbies shouldn’t offer that solution to anyone, unless they don’t care about providing fast, scalable solutions to their customers, that can grow in a sustainable way.

WordPress Custom Fields Scalability Limits

WordPress by default uses the wp_postmeta database table to store custom fields data and it creates 1 row for each custom field used in a post. Other than that WordPress adds a lot of extra data in this table for each post, each of which will use 1 row of the table.

If you spent some times optimizing SQL queries, you’ll know that’s not an ideal scenario for things like directories and filtering.

In fact the default database structure is potentially a huge bottle neck for websites with many posts and custom fields, it is considered one of WordPress’s weak points.

This is because to filter posts by custom fields, you’ll have to join the wp_post table with the wp_postmeta table in your query and the bigger the tables will grow, the slower the queries will become, worst of all if you want to filter by two meta values you would need to join the post_meta table twice to do it in the one query, this can eat up system memory and really slow things down for anything but a small directory.

Advanced Custom Fields Scalability Limits

Advanced custom fields is perfect for any website with a low or moderate number of posts, pages and custom fields in general.

However, except few rare cases, directories are just the opposite, they have a very high number of posts with potentially a very high number of custom fields too.

The main Advanced Custom Fields scalability issue is that it creates 2 rows in the wp_postmeta table of your database for each custom fields added to a listing, it will also add several postmeta rows belonging to its own settings.

This means that it will add more than twice the rows in the wp_postmeta table of your database compared to using the default WordPress custom field system.

We did a quick test that should help us better explain this matter.

We created a new WordPress website, we delete the hello world post, the sample page and we installed Advanced Custom Fields.

We created 1 group and 5 custom fields and we published 3 posts each using the 5 custom fields.

After this our wp_postmeta table already counted 83 rows. That’s insane, imagine the number of rows for a directory with 300,000 listings and 5 custom fields. With ACF your wp_postmeta table would count minimum 3,000,000 rows

How does GeoDirectory Scale?

That is very simple, we create a custom table for each of our custom post type.

Example: wp_gd_gd_place_detail

In this table we save all custom fields and their data, in a row for each post. We also built our own PHP API to query our custom tables just like WordPress has its own PHP API to query default wp database tables.

This means GD in most cases only has to join the post table to our own table, we can then filter those results by ANY custom field, we could filter by 20 custom fields where as ACF even with facetWP (which does speed things up but still has the core limitation) would have to join multiple tables over and over to do the same job in one query, using many times the server memory for the same query.

Conclusions

So if we compare GeoDirectory with WordPress or WP + Advanced Custom Fields, we see that:

WordPress
1) Requires an extra table JOIN for each custom field you want to filter by.
2) wp_postmeta quickly becomes big slowing down the queries

WP + ACF

1) Requires an extra table JOIN for each custom field you want to filter by.
2) wp_postmeta becomes twice as big compared to using WordPress alone

GeoDirectory

1) No join is required
2) GD does not add to the wp_postmeta info so does not create unnecessary bulk.
3) The database storing listings data counts 1 row per post

WordPress is known for this limitation in how it stores data, in most cases this system works fine but when it comes to large directories it’s just not the right solution that’s why with GeoDirectory you can create directory with millions of listings, while with WP + Advanced Custom Fields you are lucky if you can make a directory with few hundred listings without some serious hosting.

These are the Advanced Custom Fields scalability limits that made decide not to use it for GeoDirectory and this is why you shouldn’t use it too.

Published by Paolo

Paolo Tajani is the co-founder and growth hacker of AyeCode LTD. With his business partner Stiofan, they are the makers of the GeoDirectory, UsersWP and Invoicing plugins for WordPress. Paolo developed his first WordPress website in 2008. In 2011 he met Stiofan O'Connor and together they started building and marketing successful themes and plugins for WordPress. Today their products are used by +100.000 active websites.

Loading...