WordPress Custom Tables vs Postmeta: Performance at Scale

When architecting data-intensive WordPress plugins or enterprise web applications—such as booking systems, logistics tracking engines, financial ledgers, or directory platforms—software engineers face a foundational architectural choice: Should domain data be stored using WordPress Custom Post Types (CPTs) with `postmeta`, or inside dedicated Custom MySQL Tables?

For over a decade, the standard WordPress recommendation has been to leverage Custom Post Types for everything. CPTs provide immediate out-of-the-box benefits: native administrative list tables, Gutenberg editor integration, REST API endpoints, revision tracking, trash lifecycle management, and built-in user capability checks.

However, as application databases scale from thousands to millions of records, the underlying Entity-Attribute-Value (EAV) storage architecture of wp_posts and wp_postmeta becomes a devastating performance bottleneck. Multi-clause metadata queries trigger complex Cartesian JOIN cascades, force MySQL to write intermediate temporary tables to disk, and exhaust database server CPU capacity.

In this definitive engineering benchmark and architectural guide, we will conduct rigorous performance tests comparing CPTs against Custom Tables across 10,000, 100,000, and 1,000,000 row datasets. We will analyze EXPLAIN ANALYZE query plans, evaluate storage footprints, build an enterprise PSR-4 Repository layer, and formulate a production Hybrid Architecture pattern.

The EAV (Entity-Attribute-Value) Anti-Pattern in WordPress Core

To understand why Custom Post Types struggle at scale, we must examine the relational structure of wp_posts and wp_postmeta:

/* Core WordPress wp_postmeta Schema */
CREATE TABLE `wp_postmeta` (
  `meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `post_id` bigint(20) unsigned NOT NULL DEFAULT '0',
  `meta_key` varchar(255) DEFAULT NULL,
  `meta_value` longtext,
  PRIMARY KEY (`meta_id`),
  KEY `post_id` (`post_id`),
  KEY `meta_key` (`meta_key`(191))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

In the EAV paradigm, every single custom attribute (e.g. price, latitude, longitude, expiration date, customer status) is stored as an un-typed row in wp_postmeta where meta_value is a LONGTEXT column. This introduces four fatal engineering penalties:

1. Lack of Native Data Types: Numbers, booleans, and dates are stored as plain text strings. Numerical comparisons (e.g., price > 100.00) force MySQL to perform runtime CAST(meta_value AS DECIMAL) conversions across every row, rendering standard B-Tree indexes completely useless.
2. JOIN Multiplication: Querying an entity across 5 meta fields requires 5 separate INNER JOIN operations against wp_postmeta. On a database with 1 million posts and 10 million postmeta rows, joining the table 5 times creates a combinatorial explosion of candidate rows.
3. Prefix Index Limitations: Because meta_value is LONGTEXT, MySQL cannot build a composite index covering (meta_key, meta_value) without arbitrary prefix truncation.
4. Index and Storage Bloat: Storing the string '_billing_amount' repeatedly across 1,000,000 rows consumes tens of megabytes of disk and RAM just storing redundant key names.

Normalized Custom Table DDL Schema

In contrast, a custom relational table uses strictly typed columns, explicit nullability constraints, foreign keys, and composite B-Tree indexes tailored precisely to the application’s query patterns:

CREATE TABLE `wp_custom_orders` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `order_uuid` varchar(64) NOT NULL,
  `customer_id` bigint(20) unsigned NOT NULL,
  `status` varchar(20) NOT NULL DEFAULT 'pending',
  `currency` char(3) NOT NULL DEFAULT 'USD',
  `subtotal_cents` int(10) unsigned NOT NULL DEFAULT 0,
  `tax_cents` int(10) unsigned NOT NULL DEFAULT 0,
  `total_cents` int(10) unsigned NOT NULL DEFAULT 0,
  `is_fraud_flagged` tinyint(1) NOT NULL DEFAULT 0,
  `payment_method` varchar(30) NOT NULL,
  `settled_at` datetime DEFAULT NULL,
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uniq_order_uuid` (`order_uuid`),
  KEY `idx_customer_created` (`customer_id`, `created_at`),
  KEY `idx_status_total_created` (`status`, `total_cents`, `created_at`),
  KEY `idx_fraud_status` (`is_fraud_flagged`, `status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Rigorous Benchmark Matrix: 10k, 100k, and 1,000,000 Records

We executed automated performance benchmarks in an isolated bare-metal environment running Ubuntu 24.04 LTS, MySQL 8.0.36 (InnoDB Buffer Pool: 4 GB), and PHP 8.3-FPM. We populated both schemas with identical synthetic financial order datasets and executed 1,000 query iterations per test:

Deep Dive into `EXPLAIN ANALYZE` Query Plans

To reveal why the execution times diverge by over 200x at 1,000,000 rows, let’s inspect the MySQL 8.0 query execution plans for a multi-filter query retrieving orders where status = 'completed' AND total_cents > 5000 AND created_at > '2026-01-01':

1. Custom Post Type `WP_Query` Execution Plan

-> Filter: ((wp_posts.post_status = 'publish') and (cast(pm1.meta_value as signed) > 5000)) (cost=142385.40 rows=28450) (actual time=182.412..1815.302 rows=1420 loops=1)
    -> Nested loop inner join (cost=142385.40 rows=28450) (actual time=4.120..1782.110 rows=48200 loops=1)
        -> Nested loop inner join (cost=98410.20 rows=45200) (actual time=2.810..920.400 rows=68000 loops=1)
            -> Index lookup on pm2 using meta_key (meta_key='_order_status') (cost=45120.00 rows=120000) (actual time=0.812..142.100 rows=120000 loops=1)
            -> Single-row index lookup on wp_posts using PRIMARY (ID=pm2.post_id) (cost=0.35 rows=1) (actual time=0.005..0.006 rows=1 loops=120000)
        -> Index lookup on pm1 using post_id (post_id=wp_posts.ID) (cost=0.85 rows=3) (actual time=0.010..0.012 rows=2 loops=68000)
    -> Using temporary table; Using filesort

Execution Analysis: MySQL is forced to perform a Nested Loop Join across 120,000 rows from wp_postmeta, load raw string values from disk, execute unindexed string casting (cast(meta_value as signed)), and build an in-memory/disk temporary table to sort the results, totaling 1,815 ms of CPU execution time.

2. Custom Table Execution Plan

-> Index range scan on wp_custom_orders using idx_status_total_created over ('completed' < status <= 'completed' AND 5000 < total_cents <= NULL AND '2026-01-01 00:00:00' < created_at <= NULL) (cost=640.20 rows=1420) (actual time=0.082..8.340 rows=1420 loops=1)

Execution Analysis: MySQL executes a pure Index Range Scan directly against the composite B-Tree index idx_status_total_created. Zero temporary tables are created, zero postmeta joins occur, and all 1,420 matching records are retrieved in just 8.34 milliseconds.

Building an Enterprise PSR-4 Custom Table Repository

To interact with custom tables in WordPress cleanly without littering raw SQL queries across templates, we build a PSR-4 compliant Repository Service utilizing prepared statements, cursor-based pagination, and object caching:

db    = $db;
        $this->table = $db->prefix . 'custom_orders';
    }

    /**
     * Retrieve order by ID with Redis / In-Memory Object Caching.
     *
     * @param int $order_id
     * @return array|null
     */
    public function find_by_id(int $order_id): ?array {
        $cached = wp_cache_get((string) $order_id, self::CACHE_GROUP);
        if (is_array($cached)) {
            return $cached;
        }

        $row = $this->db->get_row(
            $this->db->prepare("SELECT * FROM {$this->table} WHERE id = %d LIMIT 1", $order_id),
            ARRAY_A
        );

        if (!$row) {
            return null;
        }

        wp_cache_set((string) $order_id, $row, self::CACHE_GROUP, 3600);
        return $row;
    }

    /**
     * High-performance filtered query using composite indexes.
     *
     * @param string $status
     * @param int $min_total_cents
     * @param string $since_datetime
     * @param int $limit
     * @param int|null $cursor_id Keyspace pagination ID.
     * @return array>
     */
    public function find_filtered_orders(
        string $status,
        int $min_total_cents,
        string $since_datetime,
        int $limit = 50,
        ?int $cursor_id = null
    ): array {
        $params = [$status, $min_total_cents, $since_datetime];
        $cursor_clause = '';

        if ($cursor_id !== null) {
            $cursor_clause = 'AND id < %d';
            $params[]      = $cursor_id;
        }

        $params[] = $limit;

        $sql = "SELECT * 
                FROM {$this->table} 
                WHERE status = %s 
                  AND total_cents >= %d 
                  AND created_at >= %s 
                  {$cursor_clause}
                ORDER BY id DESC 
                LIMIT %d";

        $results = $this->db->get_results($this->db->prepare($sql, ...$params), ARRAY_A);
        return is_array($results) ? $results : [];
    }

    /**
     * Insert a new order transactionally.
     *
     * @param array $data
     * @return int|WP_Error New order ID on success.
     */
    public function create_order(array $data): int|WP_Error {
        $defaults = [
            'order_uuid'       => wp_generate_uuid4(),
            'customer_id'      => 0,
            'status'           => 'pending',
            'currency'         => 'USD',
            'subtotal_cents'   => 0,
            'tax_cents'        => 0,
            'total_cents'      => 0,
            'is_fraud_flagged' => 0,
            'payment_method'   => 'stripe',
            'created_at'       => current_time('mysql'),
            'updated_at'       => current_time('mysql'),
        ];

        $payload = array_merge($defaults, $data);

        $inserted = $this->db->insert(
            $this->table,
            $payload,
            ['%s', '%d', '%s', '%s', '%d', '%d', '%d', '%d', '%s', '%s', '%s']
        );

        if ($inserted === false) {
            return new WP_Error('db_insert_error', $this->db->last_error);
        }

        $new_id = (int) $this->db->insert_id;
        wp_cache_set((string) $new_id, $payload, self::CACHE_GROUP, 3600);

        return $new_id;
    }
}

The Hybrid Architecture Pattern: Best of Both Worlds

You do not always have to choose exclusively between CPTs and Custom Tables. The Hybrid Architecture combines the strengths of both models:

1. Register a lightweight Custom Post Type (e.g., wpstack_order) so WordPress core handles WP-Admin list screens, capabilities, permalink routing, and REST endpoint generation.
2. Store high-frequency, complex queryable fields (numerical totals, geolocation coordinates, foreign keys, and status flags) in an attached custom 1-to-1 table indexed on post_id.
3. Hook into save_post to synchronize transactional fields to the custom table.

Database Indexing Internals: B-Tree Mechanics & Leftmost Prefix Rule

Understanding why custom tables outperform CPTs requires analyzing how the MySQL InnoDB storage engine traverses indexes. InnoDB structures table data as a Clustered Index keyed on the Primary Key. Secondary indexes are structured as B+ Trees where leaf nodes contain pointers back to the primary key.

When designing composite indexes on custom tables, column order is paramount due to the Leftmost Prefix Rule. Consider the composite index KEY `idx_status_total_created` (`status`, `total_cents`, `created_at`):

1. Equality Columns First: Columns filtered with exact equality (status = 'completed') must appear first in the index definition. This allows MySQL to immediately navigate down the B-Tree hierarchy to the exact leaf branch.
2. Range Columns Second: Columns filtered with inequalities or ranges (total_cents >= 5000) must appear after equality columns. Once MySQL hits a range condition, subsequent columns in the composite index cannot be used for B-Tree traversal (though they can still be used for Index Condition Pushdown / ICP).
3. Sort / Order By Columns Last: If ordering by created_at DESC, placing it at the end of the index allows MySQL to stream sorted rows directly off the index without executing an expensive Using filesort in RAM.

Covering Indexes: Achieving Zero Disk I/O Lookups

A Covering Index occurs when all columns requested in the SELECT clause, WHERE filter, and ORDER BY clause exist entirely within the secondary B-Tree index. When a query is fully covered, MySQL satisfies the request entirely within RAM without performing secondary table lookups against the clustered primary index on disk:

/* Fully Covered Query: Extra: Using index */
SELECT id, status, total_cents, created_at 
FROM wp_custom_orders 
WHERE status = 'completed' AND total_cents >= 10000 
ORDER BY created_at DESC 
LIMIT 20;

In contrast, wp_postmeta can never achieve a covering index for multi-field queries because the meta values are stored across separate rows in the table.

Zero-Downtime Migration Engine: Moving from CPT to Custom Tables

Migrating a live WooCommerce or enterprise site with 500,000 existing CPT records into a normalized custom table cannot be done with a single locking SQL query. We implement a Four-Phase Zero-Downtime Migration Strategy:

1. Phase 1 (Dual Writing): Hook into save_post to write new incoming records to both wp_postmeta and wp_custom_orders simultaneously.
2. Phase 2 (Background Backfill): Execute chunked cursor streaming via WP-CLI to migrate historical records in batches of 1,000 without table locking.
3. Phase 3 (Read Cutover): Switch application query readers to fetch from the custom table repository.
4. Phase 4 (Legacy Decommissioning): Disable CPT writes and drop legacy postmeta keys.

Production Migration Service Implementation

db = $db;
    }

    /**
     * Migrate a chunk of historical CPT records into the custom table.
     *
     * @param int $batch_size Rows per batch.
     * @param int $last_processed_post_id Cursor pointer.
     * @return array{migrated_count: int, last_id: int, is_finished: bool}
     */
    public function migrate_chunk(int $batch_size = 1000, int $last_processed_post_id = 0): array {
        $posts_table = $this->db->posts;
        $meta_table  = $this->db->postmeta;
        $order_table = $this->db->prefix . 'custom_orders';

        // 1. Fetch Batch of CPT IDs
        $post_ids = $this->db->get_col(
            $this->db->prepare(
                "SELECT ID FROM {$posts_table} 
                 WHERE post_type = 'shop_order' 
                   AND ID > %d 
                 ORDER BY ID ASC 
                 LIMIT %d",
                $last_processed_post_id,
                $batch_size
            )
        );

        if (empty($post_ids)) {
            return [
                'migrated_count' => 0,
                'last_id'        => $last_processed_post_id,
                'is_finished'    => true,
            ];
        }

        // 2. Hydrate Metas for Batch in a Single Query
        $placeholders = implode(',', array_fill(0, count($post_ids), '%d'));
        $raw_metas    = $this->db->get_results(
            $this->db->prepare(
                "SELECT post_id, meta_key, meta_value 
                 FROM {$meta_table} 
                 WHERE post_id IN ({$placeholders})",
                ...$post_ids
            ),
            ARRAY_A
        );

        // Group metas by post_id
        $grouped_metas = [];
        foreach ($raw_metas as $meta) {
            $grouped_metas[$meta['post_id']][$meta['meta_key']] = $meta['meta_value'];
        }

        // 3. Build Multi-Row SQL INSERT statement
        $insert_values = [];
        $insert_params = [];

        foreach ($post_ids as $pid) {
            $post_id = (int) $pid;
            $metas   = $grouped_metas[$post_id] ?? [];

            $insert_values[] = '(%d, %s, %d, %s, %s, %d, %d, %d, %d, %s, %s, %s, %s)';
            
            $subtotal = (int) (($metas['_order_subtotal'] ?? 0) * 100);
            $tax      = (int) (($metas['_order_tax'] ?? 0) * 100);
            $total    = (int) (($metas['_order_total'] ?? 0) * 100);

            array_push(
                $insert_params,
                $post_id,
                $metas['_order_key'] ?? wp_generate_uuid4(),
                (int) ($metas['_customer_user'] ?? 0),
                $metas['_status'] ?? 'pending',
                $metas['_order_currency'] ?? 'USD',
                $subtotal,
                $tax,
                $total,
                0, // fraud flag
                $metas['_payment_method'] ?? 'stripe',
                null,
                current_time('mysql'),
                current_time('mysql')
            );
        }

        $sql = "INSERT INTO {$order_table} (
            id, order_uuid, customer_id, status, currency, subtotal_cents, tax_cents, total_cents,
            is_fraud_flagged, payment_method, settled_at, created_at, updated_at
        ) VALUES " . implode(',', $insert_values) . "
        ON DUPLICATE KEY UPDATE 
            status = VALUES(status),
            total_cents = VALUES(total_cents),
            updated_at = VALUES(updated_at)";

        $this->db->query($this->db->prepare($sql, ...$insert_params));

        $last_id = (int) end($post_ids);

        return [
            'migrated_count' => count($post_ids),
            'last_id'        => $last_id,
            'is_finished'    => count($post_ids) < $batch_size,
        ];
    }
}

Table Partitioning for Multi-Million Row Datasets

When scaling beyond 10,000,000 records (e.g. high-volume audit logs, sensor telemetry, or national retail transactions), even composite B-Tree indexes on single tables can face memory pressure. MySQL InnoDB supports Range Partitioning, dividing physical disk storage into yearly or monthly partitions:

CREATE TABLE `wp_custom_orders_partitioned` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `order_uuid` varchar(64) NOT NULL,
  `customer_id` bigint(20) unsigned NOT NULL,
  `status` varchar(20) NOT NULL,
  `total_cents` int(10) unsigned NOT NULL,
  `created_at` datetime NOT NULL,
  PRIMARY KEY (`id`, `created_at`),
  KEY `idx_status_total` (`status`, `total_cents`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
PARTITION BY RANGE (YEAR(created_at)) (
  PARTITION p2024 VALUES LESS THAN (2025),
  PARTITION p2025 VALUES LESS THAN (2026),
  PARTITION p2026 VALUES LESS THAN (2027),
  PARTITION p_future VALUES LESS THAN MAXVALUE
);

When a query specifies WHERE created_at >= '2026-01-01', the MySQL optimizer performs Partition Pruning, completely ignoring partitions p2024 and p2025 and reducing memory scan requirements by 66%.

Automated Concurrency Load Testing with k6

To empirically validate query throughput under high-concurrency traffic surges, we execute the following k6 load script simulating 200 concurrent users filtering orders:

// load-tests/cpt-vs-custom-table.js
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '15s', target: 50 },  // Warm-up
    { duration: '45s', target: 200 }, // Concurrency Peak
    { duration: '15s', target: 0 },   // Cool-down
  ],
  thresholds: {
    http_req_failed: ['rate<0.001'],    // 99.9% Success Rate
    http_req_duration: ['p(95)<100'],   // 95% of requests under 100ms
  },
};

export default function () {
  const url = 'https://example.com/wp-json/wpstack/v1/orders?status=completed&min_total=5000';
  
  const res = http.get(url, {
    headers: {
      'Accept': 'application/json',
      'Authorization': 'Bearer YOUR_TEST_TOKEN',
    },
  });

  check(res, {
    'status is 200': (r) => r.status === 200,
    'response under 50ms': (r) => r.timings.duration < 50,
  });

  sleep(0.1);
}

Fluent Type-Safe Query Builder for Custom Tables

While WP_Query provides a fluent array-based query interface for Custom Post Types, raw SQL string concatenation inside plugin models quickly leads to SQL injection vulnerabilities and unreadable code. We implement a lightweight, type-safe Fluent Query Builder specifically designed for custom WordPress database tables:

 */
    private array $selects = ['*'];
    /** @var array}> */
    private array $wheres = [];
    /** @var array */
    private array $orders = [];
    private ?int $limit_count = null;
    private ?int $offset_count = null;

    public function __construct(wpdb $db, string $table) {
        $this->db    = $db;
        $this->table = $table;
    }

    public static function table(wpdb $db, string $table): self {
        return new self($db, $table);
    }

    /**
     * @param array $columns
     */
    public function select(array $columns): self {
        $this->selects = array_map('sanitize_key', $columns);
        return $this;
    }

    /**
     * Add WHERE clause with parameterized placeholder binding.
     *
     * @param string $column
     * @param string $operator '=', '>', '<', '>=', '<=', 'LIKE', 'IN'
     * @param mixed $value
     * @param string $placeholder_type '%s', '%d', '%f'
     */
    public function where(string $column, string $operator, mixed $value, string $placeholder_type = '%s'): self {
        $clean_column = sanitize_key($column);
        $allowed_ops  = ['=', '!=', '>', '<', '>=', '<=', 'LIKE', 'IN'];

        if (!in_array(strtoupper($operator), $allowed_ops, true)) {
            throw new InvalidArgumentException("Unsupported SQL operator: {$operator}");
        }

        if (strtoupper($operator) === 'IN' && is_array($value)) {
            $placeholders = implode(',', array_fill(0, count($value), $placeholder_type));
            $this->wheres[] = [
                'sql'    => "{$clean_column} IN ({$placeholders})",
                'params' => array_values($value),
            ];
        } else {
            $this->wheres[] = [
                'sql'    => "{$clean_column} {$operator} {$placeholder_type}",
                'params' => [$value],
            ];
        }

        return $this;
    }

    public function orderBy(string $column, string $direction = 'DESC'): self {
        $clean_col = sanitize_key($column);
        $clean_dir = strtoupper($direction) === 'ASC' ? 'ASC' : 'DESC';
        $this->orders[] = "{$clean_col} {$clean_dir}";
        return $this;
    }

    public function limit(int $limit): self {
        $this->limit_count = max(1, $limit);
        return $this;
    }

    /**
     * Compile parameterized SQL query and fetch results.
     *
     * @return array>
     */
    public function get(): array {
        $columns_sql = implode(', ', $this->selects);
        $sql = "SELECT {$columns_sql} FROM {$this->table}";
        $all_params = [];

        if (!empty($this->wheres)) {
            $where_clauses = [];
            foreach ($this->wheres as $w) {
                $where_clauses[] = $w['sql'];
                foreach ($w['params'] as $p) {
                    $all_params[] = $p;
                }
            }
            $sql .= ' WHERE ' . implode(' AND ', $where_clauses);
        }

        if (!empty($this->orders)) {
            $sql .= ' ORDER BY ' . implode(', ', $this->orders);
        }

        if ($this->limit_count !== null) {
            $sql .= ' LIMIT %d';
            $all_params[] = $this->limit_count;
        }

        if (empty($all_params)) {
            $results = $this->db->get_results($sql, ARRAY_A);
        } else {
            $prepared = $this->db->prepare($sql, ...$all_params);
            $results  = $this->db->get_results($prepared, ARRAY_A);
        }

        return is_array($results) ? $results : [];
    }
}

InnoDB Buffer Pool Tuning & Database Memory Optimization

When transitioning from WordPress CPTs to Custom Relational Tables, database administrators must tune MySQL's memory architecture to ensure that custom table B-Tree indexes remain resident in high-speed RAM:

1. `innodb_buffer_pool_size` (60–75% of Total RAM): Dedicated database instances should allocate 65% to 75% of physical server memory to the InnoDB buffer pool (e.g., 12 GB on a 16 GB RAM server), guaranteeing that active table pages and indexes never trigger disk read I/O.
2. `innodb_buffer_pool_instances` (1 per GB): For buffer pools larger than 1 GB, set instances equal to the number of gigabytes (up to 8 or 16) to eliminate mutex contention across multi-core CPU threads.
3. `innodb_flush_log_at_trx_commit = 2`: In write-heavy environments where microsecond checkout speed is prioritized, setting this parameter to 2 writes the transaction log to OS cache every second rather than flushing to physical disk on every single commit, boosting write throughput by 4x to 8x.

Production Troubleshooting and Incident Runbook

Writing Automated Database Tests in PHPUnit

namespace WPStackTests;

use WP_UnitTestCase;
use WPStackDatabaseCustomOrderRepository;

final class CustomTablePerformanceTest extends WP_UnitTestCase {
    private CustomOrderRepository $repository;

    public function set_up(): void {
        parent::set_up();
        global $wpdb;
        $this->repository = new CustomOrderRepository($wpdb);
    }

    public function test_repository_creates_and_retrieves_orders(): void {
        $order_id = $this->repository->create_order([
            'customer_id'    => 402,
            'status'         => 'completed',
            'subtotal_cents' => 9900,
            'total_cents'    => 9900,
        ]);

        $this->assertIsInt($order_id);
        $this->assertGreaterThan(0, $order_id);

        $order = $this->repository->find_by_id($order_id);
        $this->assertNotNull($order);
        $this->assertEquals('completed', $order['status']);
        $this->assertEquals(9900, (int) $order['total_cents']);
    }

    public function test_composite_index_filter_returns_accurate_results(): void {
        $this->repository->create_order(['status' => 'completed', 'total_cents' => 15000, 'created_at' => '2026-09-01 10:00:00']);
        $this->repository->create_order(['status' => 'pending', 'total_cents' => 20000, 'created_at' => '2026-09-01 10:00:00']);
        $this->repository->create_order(['status' => 'completed', 'total_cents' => 3000, 'created_at' => '2026-09-01 10:00:00']);

        $results = $this->repository->find_filtered_orders('completed', 10000, '2026-08-01 00:00:00', 10);
        $this->assertCount(1, $results);
        $this->assertEquals(15000, (int) $results[0]['total_cents']);
    }
}

Engineering High-Throughput WordPress Databases with WPStack

Scaling WordPress database architectures beyond 100,000 records requires deliberate relational modeling, composite indexing, and query optimization. At WPStack Studio, our database architects and core engineers specialize in refactoring bloated EAV architectures, creating custom high-speed table schemas, and engineering zero-downtime database migrations for global enterprises.

Whether you are building a custom WooCommerce HPOS extension or refactoring an enterprise SaaS backend on WordPress, consult with our lead database architects through our Custom WordPress Plugin Development Services.

Frequently asked questions

Aditya Bhimrajka

Aditya Bhimrajka is the Chief Search Systems Architect at MoxSEO, leading research in enterprise technical SEO, knowledge graphs, large-scale indexing physics, and generative engine optimization.