Yes. Custom database tables can be defined for field groups that have a User Form in their location settings.

Absolutely. Whilst the plugin supports the built in types of post and page, it is ideally suited for storing custom post type meta data in structured tables.

At this time, only one object mapping is supported per field group, so selecting more than one object (post type, user) at a time will deactivate the custom table definition settings.

We are working on support for multiple objects per table. This should ship with a subsequent 1.x release.

For now, if you need the same field group on multiple objects, you’ll need to duplicate the field group and have a custom table for each.

The plugin doesn't currently support the taxonomy form location rule, so field groups used in this context cannot be saved to custom database tables at this time.

However, the plugin does support the ACF taxonomy field. The data from this field can be stored either as a serialised JSON string in a single column or it can be configured to create a relational table where each selected term has its own table row.

Taxonomy form location rule support is something we are open to adding should there be a demand for it. If you would like to request this feature, please let us know.

The plugin parses all table definition (JSON) files and creates SQL table schema from the contained JSON. It then passes the SQL through WordPress' built-in dbDelta() function, which performs modifications to the database. The plugin also rebuilds the cached table map as part of this process.

This is a non-destructive process. It won’t delete columns or tables, but it will modify them where instructed to do so. You should always take a backup of your database before you run any sort of database schema modification, just to be safe.

The table create/update process uses WordPress' internal dbDelta() function to process the table schema. dbDelta() does not currently remove indexes, so you shouldn't lost any custom indexes you have manually created on your table.

Important: As with anything that manipulates your data, you should take a full backup before running the procedure in case something does go wrong.

The table create/update process uses WordPress' internal dbDelta() function to process the table schema. dbDelta() does not currently remove columns, so you shouldn't lost any columns that you have removed from your table definition files.

Important: As with anything that manipulates your data, you should take a full backup before running the procedure in case something does go wrong.

If you rename an ACF field, a new column will be added to the database table the next time you run the update process.

The plugin won’t know about this change of field name, so you will likely have issues with data retrieval on already saved fields. Any subsequent data updates will be saved to the new column.

If you need to do this on a live site, you’ll need to get existing data moved from the original column into the new column.

Repeater support is currently in beta testing and will ship with version 1.1

Support for other complex fields such as groups will ship in a later version. At this time, data from unsupported fields will pass through the plugin to be handled by ACF in the normal fashion.

The plugin has the potential to make your database activity more efficient by reducing the amount of data you have in your post and user meta tables.

Additionally, the plugin has built in mechanisms that query and cache an entire row of data at a time in WPs object cache. This means that, when you use ACFs API functions – e.g; get_field() and update_field() – in a template file, only the first call to the function will call the database provided all other data in subsequent calls is from the same database table and for the same parent object (post, page, user). There is a slight overhead here, but we are currently working on ways to further improve the efficiency and performance of the plugin.

If using some custom SQL or some other custom search mechanism to search your custom tables, you should be able to yield faster results using well-organised tables than if you were searching the post meta table with lots of data.

We are currently working on tools to help developers query their custom tables. If you have requests or suggestions for tools/functionality you would like to see, please let us know.

We are currently working on a migration tool to handle just this. At present, existing data will remain in the core meta tables which the plugin will fall back to where custom table data does not exist. When you next save the post/object, the data will be saved to the appropriate custom tables.