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.


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

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


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


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.

14 thoughts on “Advanced Custom Fields Scalability

  1. No longer applies since this plugin was released:

    1. It would no longer apply if that plugin was an integral part of ACF or if it was free, but it cost more than $100.
      In addition, that plugin will not prevent cluttering the wp_postmeta table. So no, that’s not that good of an option IMHO.

  2. Let’s see some metrics to back up all these claims. Just because a table becomes large doesn’t always mean it’s slow. And splitting things up into separate tables also doesn’t guarantee speed. (Wait, what? GeoDirectory no join required, but separate tables get created?)

    1. Hi,

      if you use custom fields just to make data appear on a page, having a huge wp_post_meta table may not impact your site performance, especially if you server is fast enough.

      However, if you search and filter by one or more custom field, you’ll need to do 1 join for every custom field (which is already a huge bottle neck). With each join, the bigger the table, the slower the query.

      GeoDirectory uses 1 custom table and its custom PHP API to search and filter by custom fields and because each listing has all custom fields in 1 db row, we only need to join that table once, no matter how many custom fields you are using as filters.

      Just do some tests if you want to see metrics and you’ll see that this is correct and ACF or WP regular custom fields are not a scalable solution for a directory.

      Thanks for your comment!

  3. I read this when it first came out but didn’t fully understand it. So essentially for a non-developer like myself, the CPT add-on (which I use) is a GD-native version of one of these toolsets like ACF but optimized for GD correct?

    1. yes Mark, more or less that’s it…

  4. You are missing the point. ACF means I can apply a geolocation and attribute to ANY post/information. GeoDirectory only allows me to locate posts written by GeoDirectory. That’s why ACF and Facet gets supported

    1. And what has that to do with the fact that it does not scale???

  5. Stiofan/Paolo thanks for the nice and detailed post.
    Can you say how using CMB2 compares to ACF on the same custom fields matter? Thanks!

    1. Hi Fiabio,

      I never tested that plugin, once I’ll find 5 minutes to install it on a staging site I’ll let you know, but testing it easy if you want to check on your own.

      Try to add a couple of custom fields to any post via it’s UI and after check where it is saving them in the DB. If it adds 1 row per meta like it’s uses WP standards.

      In that case it’s good for a limited n of posts and custom fields, especially if custom fields must be used as filters in advance searches.


  6. One of the limitations that we have found with Geodirectory is that the Custom Post Types have a lot of default fields. 30+. That’s 30+ rows in the database for each post whether we use all of them or not.
    We seem to hit a max and started getting errors when we had 90+ database rows in a custom post type ( (1 for each custom field + default 30+ GD default fields)
    We were able to fix the problem somewhat by changing the default data type of some of the database rows / custom fields from varchar to text.

    There seems to be a lot of default fields in GD that we aren’t using and wish we could remove them to make space for custom fields we would actually use.

    Thanks for the post.

    1. Hi John,

      GD does not add a row for each custom field, that is the point 🙂
      GD has this as a column, it is very rare for someone to reach the max columns length, this in theory should be over 4k but in reality it depends on the data types, but if they do it’s usually a case of not adding CF the best way and as you say if they are stored as text they don’t count to wards the max length of columns.



  7. Thank you for the detailed post! Although I’ve used Geodirectory for few projects, I was looking to try out ACF + FacetWP for a new project just because I wanted to use native WordPress features.

    But this post explains nicely why that would be a pain long term, especially when the site starts getting popular with lot of people filtering/searching it!

    1. You are welcome Farhan, the ACF + FacetWP solution looks awesome until you put it under stress with high traffic tests. We started dealing with WordPress scalability way before ACF or FacetWP were even released… 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.