You started with a custom post type for "Projects." Then came meta fields, a taxonomy, and two plugins. A year later your product data lives in
wp_posts and wp_postmeta, and every report needs a custom query. That is the moment teams ask whether WordPress custom post types still fit, or whether Laravel models would be clearer.This article compares WordPress custom post types (CPTs) with Laravel Eloquent models for product-shaped data. You will see what CPTs are good at, where plugin stacks start to hurt, what models and migrations give you instead, and how to decide without a rewrite panic.
Disclosure: LaraDashboard is our open-source Laravel admin and CMS. We recommend it when you want posts, CRM-style records, tickets, and related modules as first-class Laravel models. The decision points below still apply if you use Filament, Nova, or a custom Laravel app.
For the broader move off WordPress, see why developers move from WordPress to Laravel. For content + product architecture, see headless WordPress vs Laravel CMS.
The short answer
Keep custom post types when the data is mostly editorial content with light structure: case studies, team bios, simple event listings, and fields that editors change in wp-admin. ACF (Advanced Custom Fields) and taxonomies are enough. Query volume stays modest. Schema changes are rare.
Move toward Laravel models when the data is the product: orders linked to accounts, tickets with assignees and SLAs, CRM deals with stages, inventories, approvals, or anything that needs real foreign keys, typed columns, and testable domain logic. CPT + postmeta will fight you on joins, migrations, and multi-environment deploys.
Many teams run a hybrid for a while: WordPress owns the blog and marketing CPTs; Laravel owns the product database. That is fine if you write an ownership map.
What WordPress custom post types actually are
A custom post type is a registered content type beside posts and pages. WordPress stores each item as a row in
wp_posts with a post_type value. Titles, body content, status, and author live there. Extra fields usually land in wp_postmeta as key/value pairs. Taxonomies (categories, tags, or custom ones) hang off term tables.Plugins like ACF, Meta Box, or CPT UI make registration and field UIs easier. You get admin menus, REST exposure, and editor workflows without writing much PHP at first.
For product data, teams often stretch CPTs into:
- Catalog items with price and stock meta
- Memberships or "courses" with progress meta
- Support tickets as a CPT plus status taxonomy
- CRM "leads" with dozens of meta keys
- Multi-step application forms saved as posts
It works until the relationships get dense and the reports get serious.
Meta, taxonomies, and plugins as your schema
In WordPress, your "schema" is often a mix of:
- Registered post types and supports
- Meta keys written by plugins or theme code
- Taxonomies used as soft enums
- Options and transient caches
- Third-party plugin tables you did not design
There is no single migration file that describes the whole model. Staging and production can drift when someone adds a field in production ACF and forgets to export it. Typed relations (one ticket has many messages belonging to one user) are awkward compared to foreign keys.
Official docs cover registering post types and the REST API. They do not claim CPTs replace an application database. That gap is where scaling pain shows up.
When CPT + ACF / plugins scales poorly
Query cost and postmeta shape
Listing "all active deals for org 42 with owner and last activity" in Eloquent is a few joins. In WordPress it often means
WP_Query plus meta queries, or raw SQL against wp_postmeta. Meta queries can multiply joins on the same table. Indexes help only so far when every custom attribute is a string row.At low volume you will not notice. At thousands of CPT rows with heavy admin filters, list screens slow down. Reporting dashboards get rebuilt as custom SQL. Caching hides the symptom until write traffic rises.
Schema drift across environments
ACF JSON sync helps when the team uses it. Many sites still change fields live. A new required meta key appears in production. Staging does not have it. Importers fail. New developers ask which keys are "real."
Laravel migrations are not magic, but they force schema changes through version control. You review a diff. You run
migrate on each environment. Drift becomes visible.Plugin coupling
Your "ticket system" may depend on a form plugin, an ACF field group, a status taxonomy, and a Slack notify plugin. Each update can change hooks or storage. You inherit CVE patch cadence for every plugin in the chain. Product features become "wait for plugin X" instead of "ship a migration and a test."
That is a common reason teams leave plugin-heavy WordPress. We cover the pattern in why developers move to Laravel.
Migrations and content moves
Exporting CPT data is doable. Mapping nested meta, media IDs, and term relationships cleanly is the hard part. If you later move to Laravel, you will rewrite that map anyway. Delaying the move while adding more meta keys increases migration cost.
See the WordPress to Laravel migration checklist when you plan content, SEO, auth, and media together.
Typed relations and domain logic
Eloquent relationships (
hasMany, belongsTo, belongsToMany) match how product teams talk. Policies and form requests sit next to the model. Queues and events are first-class.In WordPress, the same logic often lives in action hooks, theme functions, and plugin glue. Unit testing that path is harder. Soft deletes, UUID keys, and multi-tenant scopes are packages or custom code in Laravel; in CPT land they are often "meta flags" and careful
WP_Query args.Multi-environment and CI
Laravel apps expect
.env differences, migrations, and feature tests in CI. WordPress can do similar work, but CPT-heavy products rarely start that way. Deploys become FTP or panel updates plus "remember to sync ACF." Product teams that already live in Git and PR review feel the mismatch first.What Laravel Eloquent models give you instead
An Eloquent model maps to a table you own. Columns have types. Foreign keys are real. Migrations describe history. Factories and seeders build test data. Relationships are methods you can reason about.
Example shape for a support ticket (illustrative, not a copy-paste mandate):
- tickets table: id, account_id, assignee_id, status, priority, subject, timestamps
- ticket_messages table: id, ticket_id, user_id, body, timestamps
- Model methods: account(), assignee(), messages()
- Policy: who can view or close a ticket
- Form request: validation rules in one place
You still build the admin UI. Filament, Nova, or a modular CMS such as LaraDashboard provide that layer. The point is the data model is no longer a bag of postmeta keys.
Migrations as the source of truth
Want a new
sla_due_at column? Add a migration. Review it. Run it. Rollback in staging if needed. Your schema history lives beside application code. That discipline matters when three environments and two feature branches touch the same domain.Relationships and reporting
SQL joins become normal again. You can index
account_id and status. You can add a covering index for a common filter. Analytics queries stop fighting the EAV-style meta table.APIs and jobs beside the model
Laravel routes, Sanctum tokens, queued jobs, and observers attach cleanly to models. You do not need a custom REST controller plugin for every CPT. Product APIs and admin screens share the same validation rules.
Still not free
You own the schema. You write migrations carefully. You design indexes. You train editors on a new admin if they leave wp-admin. A Laravel CMS shortens admin work; it does not remove domain design.
Side-by-side cheat sheet
Use this as a planning scorecard (prose form so CMS renderers keep it):
Primary storage: CPT uses
wp_posts + wp_postmeta. Laravel uses dedicated tables via migrations.Field definition: CPT often uses ACF/UI plugins. Laravel uses migrations + validation + admin forms.
Relations: CPT uses post IDs in meta or taxonomies. Laravel uses foreign keys and Eloquent relations.
Query patterns: CPT leans on
WP_Query and meta_query. Laravel leans on the query builder and eager loading.Environments: CPT risks UI-driven schema drift. Laravel pushes schema through migrations in Git.
Best fit: CPT for editorial content with light structure. Laravel models for product workflows and reporting.
Plugin risk: CPT stacks grow plugin surface area. Laravel stacks grow your code and Composer packages you choose.
Editor familiarity: CPT wins if staff live in wp-admin. Laravel wins if the admin can speak domain language (Deals, Tickets, Accounts).
Honest stay-on-WordPress cases
Stay on CPTs when most of these are true:
- The type is content-first (portfolio, FAQ items, simple locations).
- Editors must stay in WordPress and refuse a new admin.
- Relationships are shallow (a few meta fields, one or two taxonomies).
- Traffic and admin filters stay light.
- You already have a stable ACF JSON workflow and staging discipline.
- Product logic lives (or will live) in a separate app, and WordPress is only the content API.
Headless WordPress still uses CPTs under the hood for many content types. That can be the right split when marketing content stays in WordPress and the product database is already Laravel. See headless WordPress vs Laravel CMS.
Honest move-to-Laravel cases
Plan a move toward models when most of these are true:
- Staff call the CPT a "system," not a "content type."
- You need joins across accounts, users, and line items daily.
- Meta keys number in the dozens with naming collisions.
- You want feature tests around create/update rules.
- Multi-tenant or role rules are core to the product.
- Plugin updates block your roadmap.
- You are hiring Laravel engineers, not WordPress plugin specialists.
Migration does not have to be big-bang. Extract one domain (tickets, deals, inventory) into Laravel first. Keep the blog on WordPress until URLs and redirects are ready. The migration checklist covers content, SEO, auth, and media in order.
How LaraDashboard / Laravel CMS models map
LaraDashboard is a modular Laravel CMS and admin. Content such as blog posts can live as models with media, taxonomies, and roles in the same app. Product-leaning modules (contacts, deals, tickets, forms, email templates, depending on what you enable) are also Eloquent-backed rather than CPT + postmeta.
Practical mapping when you leave WordPress CPTs:
- Blog posts / pages -> Post (or page) models with editor UI, SEO fields, and media library in Laravel
- Portfolio / resources CPTs -> Dedicated models or a flexible content model with typed columns you define
- "Lead" or "Deal" CPTs -> CRM-style contact and deal models with stages and activities
- "Ticket" CPTs -> Ticket models with assignees, statuses, and reply threads
- Form entries saved as posts -> Form submissions table with viewed/handled flags
- Memberships / app users in WP -> Laravel users, Spatie-style roles, and policies
You still design the schema. LaraDashboard gives you the admin shell, modules, and Laravel conventions. It does not pretend every WordPress plugin has a one-click twin. For modular structure, see building modular Laravel applications with Lara Dashboard. For a product overview, see what LaraDashboard is.
Self-hosted means you still harden the box. Security is ownership, not a slogan. Our security series starts with how to secure a self-hosted Laravel CMS.
A practical decision walkthrough
Step 1: Name the noun
Write the noun staff use in Slack: Deal, Ticket, Shipment, Enrollment. If it sounds like a business object with lifecycle states, lean Laravel. If it sounds like an article with extra fields, CPT may be enough.
Step 2: List the joins
On paper, list every "this belongs to that" link. More than two or three frequent joins is a warning for postmeta.
Step 3: Count write paths
Who creates records? Editors only, or also API clients, importers, and cron jobs? Many write paths favor validated models and policies.
Step 4: Check environment sync
Ask how a new field reaches staging and production today. If the answer is "someone clicks in wp-admin," budget for process change even if you stay on WordPress.
Step 5: Price the migration once
Do not price only hosting. Include redirects, auth, media, and editor training. Hybrid extraction of one domain often beats a full rewrite in year one.
Common objections
"We can just add another plugin." Sometimes that is correct for a content need. For core product data, each plugin adds coupling and patch work. Measure roadmap delay, not only license cost.
"CPT UI + ACF is fine for our SaaS." Fine until reporting and tenancy land. If you already plan Laravel for the app, avoid storing the source of truth in postmeta.
"Eloquent is overkill for five fields." Agree. Start simple. Promote to a model when fields become a lifecycle.
"Editors will hate leaving WordPress." Pilot one content type. Measure time-to-publish. Keep marketing CPTs on WordPress if needed while product models move first.
"We will lose SEO." SEO breaks from bad redirects and URL ownership gaps, not from choosing models. Plan canonicals like a product launch. See rebuild without losing rankings.
FAQ
Are custom post types bad?
No. They are the right tool for many editorial content types. They become painful when used as a general-purpose application database.
Is ACF the problem?
ACF is a solid field UI for WordPress. The scaling issue is usually EAV-style meta storage plus plugin coupling for product domains, not the field picker itself.
Can I keep WordPress for the blog and Laravel for tickets?
Yes. That hybrid is common. Share auth carefully. Document which system owns which URLs and media. Migrate when the split costs more than it saves.
Do Laravel models replace taxonomies?
Often you use enum columns, lookup tables, or real
belongsToMany relations instead of WP terms. You can still build tag-like models if editors need free-form labels.How does LaraDashboard store blog posts?
As Laravel-backed content in the CMS modules, not as WordPress
wp_posts. You get Laravel migrations, policies, and admin UI in one deploy. Exact tables depend on your version and enabled modules; check current docs on laradashboard.com.When should we stop adding meta keys and migrate?
When new features need joins, tests, or multi-environment schema changes more than they need a quick ACF field. If two sprints in a row were "fighting WP_Query," schedule the extraction.
Ending note
Custom post types shine for structured editorial content inside WordPress. Laravel models shine when the data is the product: relations, policies, migrations, and reports that need real tables.
Score your noun, your joins, your write paths, and your environment sync. Stay on CPTs when the work is still content. Move product domains to Eloquent when plugins and postmeta become the bottleneck.
If you want that Laravel-native path with a modular admin and CMS, explore LaraDashboard. Keep WordPress where it still fits. Write the ownership map before you add the next "just one more" meta field.
