Advanced Custom Fields does not scale

Advanced Custom Fields is a fantastic plugin used by millions that convert WordPress into a full-stack CMS, allowing you to create unlimited custom field groups, and 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 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 in building directories.

We thought that maybe, being users, they are not aware of what is going on under the hood and 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 options 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 Web Developers shouldn’t offer that solution to anyone unless they don’t care about providing fast, scalable solutions to their customers, that can grow sustainably.

WordPress Custom Fields Scalability Limits

WordPress by default uses the wp_postmeta database table to store custom field 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 time 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 bottleneck 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.

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 one query.

This can eat up system memory and drag things down for anything but a small directory.

Advanced Custom Fields Scalability Limits

The Advanced custom fields plugin, 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 primary Advanced Custom Fields scalability issue is that it creates 2 rows in the wp_postmeta table of your database for each custom field 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, deleted the hello world post, and 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 five custom fields.

With ACF, your wp_postmeta table would count minimum of 3,000,000 rows

How does GeoDirectory Scale?

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

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 table.

We can then filter those results by ANY custom field.

We could filter by 20 custom fields, whereas 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 a directory with millions of listings, while with WP + Advanced Custom Fields, you are lucky if you can make a directory with a few hundred listings before starting to see major performance problems.

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

If you have any questions, feel free to ask in the comment down below.