All three plugins let you add custom fields to WordPress posts, pages, and custom post types. That’s where the similarity ends. ACF Pro is the easiest to learn and integrates with every major page builder. Metabox is faster at scale and gives you control over database storage. Pods bundles custom post types, taxonomies, and fields into a single free tool. The right choice depends on your project’s complexity, budget, and who will maintain the site.
One Thing to Know Before You Pick: The ACF Fork
In 2023, WP Engine acquired Advanced Custom Fields. In late 2024, the WordPress.org team forked ACF as Secure Custom Fields (SCF) — a free, community-maintained version available in the plugin directory. The Pro version of ACF remains a WP Engine product and requires a WP Engine license to download.
This matters for your decision: if your budget is zero and you want the ACF interface with the core ACF field types, SCF is the current free path. If you want the Repeater field, Options Pages, ACF Blocks, and Flexible Content — those are Pro-only features that require a paid WP Engine subscription. Metabox and Pods are unaffected by this situation.
Quick Comparison
| Feature | ACF Pro | Metabox | Pods |
|---|---|---|---|
| Free version | Yes (SCF fork, limited) | Yes (core fields only) | Yes (full-featured) |
| Paid pricing | ~$149–$249/yr (WP Engine) | ~$149/yr all-access bundle | ~$49–$99/yr (Pods Pro) |
| Field types | 30+ (Pro), ~15 (free) | 40+ (with extensions) | 15–20 core types |
| API style | get_field(‘name’) | rwmb_meta(‘field_id’) | pods(‘type’, $id)->field(‘name’) |
| Custom DB tables | No | Yes (MB Custom Table) | No |
| CPT management | No (separate plugin) | Yes (MB Custom Post Type) | Yes (built-in) |
| Block editor (ACF Blocks) | Pro only | MB Blocks (paid ext.) | Limited |
| Page builder integration | Excellent (Bricks, Elementor, Divi) | Good | Basic |
| Best for | Content-heavy builds, page builder projects | High-volume data, WooCommerce | Budget projects, CPT + fields together |
ACF Pro: The Standard Most Teams Reach for First
ACF earned its market position because the field group UI is genuinely easy to learn — a developer can hand off a site to a non-technical client and the client can edit structured content without touching the database. That UX advantage compounds over time: less support, fewer mistakes, faster onboarding for new team members.
The Pro tier adds the four features that separate ACF from everything else in most workflows:
- Repeater field — repeating groups of sub-fields (team members, pricing tiers, testimonials) stored as serialized postmeta rows
- Flexible Content field — a layout builder that lets editors assemble sections from predefined field layouts
- Options Pages — site-wide settings stored outside of any single post, accessible via
get_field('field_name', 'option') - ACF Blocks — register custom Gutenberg blocks backed by ACF field groups, without writing React
The API is the cleanest of the three to write by hand:
// Get a single field value
$value = get_field('hero_heading', $post_id);
// Loop a repeater
if (have_rows('team_members', $post_id)) {
while (have_rows('team_members', $post_id)) {
the_row();
echo get_sub_field('name');
}
}
Where ACF Pro loses ground: data storage. Everything goes into wp_postmeta, one row per field value. A post with a Repeater containing 20 rows of 5 sub-fields writes 100+ postmeta rows. At scale — a directory site with 50,000 listings, a WooCommerce store with extensive product attributes — that table becomes a performance liability. If that scenario fits your project, read the Metabox section carefully.
Page builder compatibility is ACF’s real differentiator. Bricks Builder treats ACF as a first-class data source — you connect any field directly in the editor without writing a query. Elementor Pro and Divi do the same. If you’re working with a visual page builder, ACF Pro is the path of least resistance.
Pick ACF Pro if: clients will manage content themselves, you’re using a page builder, or you need ACF Blocks for Gutenberg-based projects.
Skip ACF Pro if: you need custom database tables for performance, your budget is zero, or you’re building a large data-heavy application where postmeta scale is a concern.
Metabox: The Performance-First Choice
Metabox takes a different philosophy: the core plugin is lightweight and free, and you add capabilities via extensions as you need them. The free version covers the basics — text, number, date, select, checkbox, radio, image, file, WYSIWYG — which is enough for a surprising number of projects. The paid extensions unlock the features that make Metabox worth paying for:
- MB Custom Table — stores field data in a dedicated custom table instead of
wp_postmeta. For a site with thousands of posts and many fields each, this dramatically speeds up queries - MB Relationships — bi-directional relationships between any content types
- MB Custom Post Type — register CPTs and taxonomies via UI
- MB Views — template-driven output without writing PHP
- MB Blocks — Gutenberg block registration backed by Metabox fields
The all-access bundle runs around $149/year and unlocks everything. Individual extensions are ~$59/year each. If you only need Custom Table and one other extension, buying individually is cheaper — but the all-access deal makes sense for any developer managing multiple projects.
The API is slightly more verbose than ACF’s but still straightforward:
// Get a single field value
$value = rwmb_meta('field_id', '', $post_id);
// Or the object-oriented approach
$value = RWMB_Field::get_value('field_id', [], $post_id);
The MB Custom Table feature deserves specific mention. When you register a custom table for a post type, Metabox creates a dedicated table (wp_your_post_type_data) and stores all field values there as columns. A query that would normally hit wp_postmeta with 50 rows per post instead reads one row from a single indexed table. For a WooCommerce catalog with custom product attributes, or a directory with geolocation fields you’re querying by, this isn’t a minor optimization — it’s a fundamental architectural difference.
Pick Metabox if: you’re building data-intensive sites (directories, WooCommerce, real estate listings), you need custom database tables for query performance, or you’re a developer-first team comfortable writing PHP.
Skip Metabox if: non-developer clients need to build their own field groups, or you’re using Bricks/Elementor and want native point-and-click integration.
Pods: One Plugin for Fields, CPTs, and Taxonomies
Pods solves a different problem than the other two. Where ACF and Metabox focus on adding fields to existing content types, Pods handles the full stack: defining the content type, its taxonomy, and its fields — all from one UI, entirely for free.
If you’re building a site that needs a Property CPT with a Property Type taxonomy and 15 custom fields, you can do all of that in Pods without installing a separate CPT plugin. That’s a genuine convenience for simpler builds where the architecture is straightforward and the budget is limited.
The Pods template system is also worth noting — it uses simple template tags ({@field_name} syntax) to output field data without PHP, which can be useful for clients who want to control their own templates but aren’t developers.
The API reflects the object-oriented architecture:
// Get a field value
$pod = pods('property', $post_id);
$value = $pod->field('bedrooms');
// Or simpler shorthand
$value = pods_field('bedrooms', $post_id);
The honest tradeoffs: Pods doesn’t integrate with page builders the way ACF does. The developer community and documentation are smaller than ACF’s, which means fewer Stack Overflow answers when something breaks. The free version is genuinely full-featured, but Pods Pro (paid) unlocks advanced relationship types, import/export, and priority support — so it’s not quite as completely free as it’s sometimes marketed.
Pick Pods if: budget is the primary constraint, you need CPT + taxonomy + fields management in a single free plugin, or you’re building a relatively simple content architecture.
Skip Pods if: you’re integrating with a major page builder, need Repeater-equivalent functionality with polished UI, or are building something you’ll be actively developing and scaling for years.
How to Actually Decide
Three questions narrow it down quickly:
1. Who manages the content? If a non-developer client will be in WordPress adding and editing structured content, ACF Pro’s field group UI is the least likely to generate confused support emails. Metabox is developer-facing. Pods is in between.
2. How much data, and do you query across it? A blog with a few extra fields per post: any of the three. A directory with 10,000 listings where you’re filtering by price, location, and category simultaneously: Metabox with MB Custom Table is in a different performance league. For the underlying mechanics, see the WP_Query guide on custom fields and meta queries — the postmeta join behavior it describes is exactly what custom tables sidestep.
3. Are you using a page builder? If yes, ACF Pro. Bricks Builder in particular treats ACF as a first-class data source — you can bind any ACF field to any element attribute directly in the editor. Metabox and Pods require more manual wiring.
On budget: if you’re building a custom theme from scratch and writing PHP templates directly, the SCF fork gives you most of the ACF field UI for free. If you need Repeaters, Options Pages, or ACF Blocks — that requires Pro. For the custom theme from scratch workflow, ACF Pro or Metabox both fit naturally depending on data scale.
If you’re managing custom post types as part of this decision, the CPT guide covers how CPTs and custom fields interact at the architecture level — useful context before committing to any of the three plugins above.
Still Not Sure?
The choice of custom fields plugin tends to echo through a project for years — it affects query patterns, template code, and how much the client can self-serve. If you want a recommendation for a specific build, get in touch and I can tell you which one fits and how to structure the fields before you start building.


