In my previous post, I showed you how to import programmatically defined ACF data. However, I also mentioned that there are some issues you may encounter when dealing with large datasets, such as those that use the Repeater field.

The Repeater field provides a neat solution for repeating content – think slides, team members, CTA tiles and alike.

This field type acts as a parent to a set of sub fields which can be repeated again and again. What makes this field type so special is its versatility. Any kind of field can be used within a Repeater, and there are no limits to the number of repeats either (👨‍💻 unless defined in the field settings).

Repeat, ACF Manual

The Repeater field allows you to create a set of fields that can be repeated an unlimited number of times. While this is great for flexibility, it also means that there is no limit to the number of rows or fields that can occur. As a result, you may run into the upper limit of what the database can store.

For those who are familiar with the implementation of the Repeater field, you know that each time a new entry is added to the post that the Repeater is attached to, a new set of records is added to the postmeta table. Over time, this can become a scalability issue.

That is, the post table will hold the post to which the repeater is attached. Then every time a new entry is added to said post, a set of new records will be added to the postmeta table.

Overtime, this won’t scale. More specifically, you’re going to hit a point as to where adding a new row in the repeater won’t work. And this is where the alternative solutions for custom data tables tables for ACF comes into play.

Custom Database Tables For ACF

Once upon a time, this would have been one of those challenges that I would have set aside about half a day to build but one of the best things about working in software is that if you’ve encountered a problem, you’re likely not the first.

And when it comes to something like ACF, there’s likely going to be a situation someone else has encountered and thus solved. This is one of those situations.

For those who love to do it all, creating a table schema, writing the code to create the table, and begin testing writing and reading data to it from ACF – not to mention all of the validation and sanitization needed – sounds like a fun technical problem to solve.

But when working under ‘real world’ constraints, we’re far more limited. After a lot of research (and seriously considering just doing it myself 🙃) I ended up using ACF Custom Database Tables.

The two main reasons on this is because:

Store your Advanced Custom Fields data in custom database tables for faster search queries, structured data, & easy exports! Storing ACF fields in custom tables is ideal for anyone using ACF at scale.

And because:

Store repeater field data in normalised, structured tables of their own.

Done and done, right?

Of course, the proof is when it actually works. So after purchasing the plugin, exporting the data as noted in the previous post, and then running the migration it worked flawlessly and it continues to do so.


If you’re looking for an off-the-shelf solution for managing data that scales well especially as it relates to setting up custom database tables for ACF, I highly recommend ACF Custom Database Tables.

It’s worth the price, it does the job, does it well, and I’ve had no problems since implementing it.