Every serious WordPress build needs custom fields. The first WooCommerce product page is the moment the developer realizes that title-and-content is not enough — the project also needs a vehicle compatibility table, a list of related downloads, a video embed, a custom CTA, a regional pricing override. The post_content field cannot hold that semantically. You need real custom fields.
The three plugins that have dominated this space for the last five years are Advanced Custom Fields Pro, Toolset, and Pods. We have shipped builds on all three in 2018 and 2019. They are not equivalent. Each one bets on a different theory of how a WordPress site should grow.
ACF Pro: the developer’s first choice
ACF — Advanced Custom Fields — is the default in our shop. It has been for years. The plugin does one thing well: it gives developers a UI to define custom fields against post types, taxonomies, users, options pages, and front-end forms, and an API to read those fields back in PHP templates.
The reason it works is that it stays out of the way. The fields are stored in wp_postmeta with predictable keys. The template code calls get_field() or the_field() and the data comes back as a PHP type — string, array, object, post object, image array. The plugin does not generate front-end markup. It does not control layout. It does not assume anything about how the data should be displayed.
For an agency that ships custom front ends — which is most of our work — this is the right contract. ACF defines the data model. The theme defines the presentation. Switch themes, switch front ends, switch to a headless setup, and the data model still works the same way. The latest 5.8 release this summer added support for ACF Blocks, which we have started using on every Gutenberg build.
Toolset: the editor’s first choice
Toolset is the opposite bet. The plugin defines custom fields, but it also defines templates, views, archives, and forms — through a UI, in the admin, without writing code. It is meant for builders who want to ship a custom application on WordPress without writing PHP.
For the right project, this is genuinely powerful. Real estate sites, directory sites, classifieds, learning management — Toolset lets a non-developer wire up the entire CRUD experience for a domain-specific application. We have a client who built a small property-management portal entirely in Toolset over three weekends.
The catch is the same catch as every visual builder. The output is opinionated. The markup is generic. The performance is what the plugin decides it is. And the data, while stored in wp_postmeta like ACF, is wrapped in a layer of view definitions and template assignments that does not portable to a different builder cleanly.
If the project is a content-publishing site where the editing team wants to author from the admin without ever opening the theme, Toolset is worth a hard look. If the project is going to grow a custom front end or a headless layer, ACF is the safer bet.
Pods: the third option
Pods has been around as long as the other two and has a smaller, dedicated user base. It treats every custom post type as a ‘pod’ and gives the developer a unified API for defining, storing, and querying that data, with the option to store it in custom database tables rather than the WordPress meta tables.
The custom-tables option is genuinely interesting. wp_postmeta is a notoriously inefficient store for large datasets — every row is a key-value pair, queries against multiple meta keys mean multiple joins, and a 50,000-product WooCommerce site can see meaningful slowdowns in the admin. Pods lets you opt those data structures out of postmeta entirely.
The cost is that the data is no longer in the standard WordPress location. WP_Query does not see custom Pods tables natively. Plugins that read post meta — most of them — will not find Pods-stored fields. WP CLI, exports, migrations all need Pods-specific handling.
For most projects this is a worse trade than it sounds. For a specific class of project — high-volume data that is genuinely unsuited to the EAV pattern, like a 200,000-row property database — it might be the right call. We have not had that project come up often enough to make Pods our default.
How we choose
The decision tree, on every project:
- Will the front end be custom-coded PHP templates or a headless layer? → ACF Pro.
- Is the project a content-publishing site with a typical post-and-page structure plus a few custom post types? → ACF Pro.
- Is the project a domain-specific application that the client wants to extend through the admin without developer involvement? → Toolset is worth evaluating, but be honest with the client about the trade-offs.
- Is the data volume genuinely too large for postmeta to handle? → Pods, with eyes open about the ecosystem cost.
In practice, ACF Pro wins about ninety percent of the time. The annual license cost is small, the API is stable, the migration path off it is clean — fields stored in postmeta survive an ACF uninstall, just without the UI. That is the kind of safety net that matters on a three-year build.
The block-editor implication
One thing that has shifted in 2019 is the rise of ACF Blocks. The ability to define a Gutenberg block in PHP, with ACF fields driving the block attributes, is now mature enough to ship on production. We have built more than a dozen client block libraries this way in the last twelve months. It is the path we recommend for any new build.
Toolset is shipping a similar feature. Pods has its own Gutenberg story. But ACF Blocks have the developer experience that comes from years of iteration on the underlying field API, and the block markup is HTML you control rather than HTML the plugin decides for you. That tips the same way the rest of the decision tips.