Source database: wordpress
Architecture HYBRID_WITH_CACHE Overall risk HIGHCurrent monthly
Projected monthly
Savings
Engines
Tables migrate
Overall risk
Already removed from this comparison: $367.39/mo (DocumentDB), $240.96/mo (OpenSearch), retired before this projection; see Engines not used below.
Analyzed 50 source tables and 107 query patterns across 3 target database(s). Workload split: dynamodb handles 58 queries (54.2%), aurora_mysql handles 49 queries (45.8%). Cache layer: elasticache fronts 20 hot reads (83.4% of calls) cache-aside and owns no queries. Estimated monthly cost: $582.76. 2 open migration risks (overall: HIGH); 6 more were resolved by the assignment. Other targets evaluated: documentdb (consolidated into aurora_mysql by the reality check), opensearch (consolidated into aurora_mysql by the reality check).
The generated narrative was withheld because it referenced schema work this run did not perform; the figures here are unaffected.
| Engine | Role | Workload | Scope | Est. monthly | Why |
|---|---|---|---|---|---|
| dynamodb | Migration target | 54.2% | 0 source tables | $98.41 | 97% mean fit across 58 queries (18 rated tables), led by key-value lookups (25 of 58). estimated $98.41/month. |
| aurora_mysql | Migration target | 45.8% | 0 source tables | $318.80 | 88% mean fit across 49 queries (21 rated tables; 2 queries without table-level evidence), pinned by a utility or DDL statement, aggregation, full-text or pattern search and multi-table joins (35 of 49). estimated $318.80/month. |
| elasticache | Cache layer | 20 cached reads · 83.4% of calls | cache-aside | $165.55 | Cache layer for 20 hot reads (83.4% of calls), mostly point lookups, cache-aside in front of Aurora MySQL in wave 2, then DynamoDB once wave 3 moves these reads; it owns no queries; 76% mean cache fit across 20 cached reads (12 rated tables). estimated $165.55/month (185.07 calls/s combined across these reads clears the 1 calls/s hot-read floor). |
| Total | 100% | 8 tables migrate | $582.76 | ||
elasticache is an additive cache layer: it fronts 20 hot reads (83.4% of calls) cache-aside and owns none of the workload: the engines listed above still own every cached read. It fronts Aurora MySQL in wave 2, then DynamoDB once wave 3 moves these reads with no data migration of its own, and keeps serving the same reads as their owners move in later waves: invalidation follows the engine that owns each cached table. The migration moves the 8 tables assigned to DynamoDB, Aurora MySQL; the per-engine costs above reconcile to the projected total.
One suggested adoption path, not the only one — to modernize in one step instead, adopt the target architecture in Recommended architecture above directly.
Wave 1: Move to Aurora MySQL — all 107 queries at cutover; 49 (45.8%) remain on Aurora MySQL at the end, 50 source tables and views. The whole source database (MySQL 8.0.45) moves 1:1 to Aurora MySQL: same engine family. The collector reports engine and version only; feature compatibility is not assessed here. 49 queries (45.8%) remain on Aurora MySQL once later waves have moved their share; later waves move subsets of these 50 tables and views out of Aurora MySQL.
Gate: Schema and data parity validated against the source database before cutover; decommission the legacy source once replication lag is zero.
Wave 2: Cache hot reads with ElastiCache — 20 queries (83.4% of calls). 20 hot reads (83.4% of calls), cache-aside in front of Aurora MySQL in wave 2, then DynamoDB once wave 3 moves these reads: no data migration, fully reversible. It takes the read pressure off before the data migrations that follow. These reads belong to queries that move in wave 3 (DynamoDB) and wave 1 (Aurora MySQL); this share overlaps the owner shares, which alone sum to 100%.
Gate: Cache hit rate and invalidation verified against Aurora MySQL.
Wave 3: Move key-value and point-lookup queries to DynamoDB — 58 queries (54.2% of query patterns), 8 source tables. 58 key-value and point-lookup queries (54.2% of query patterns) across 1 table group, respecting co-dependent tables where possible: the pattern DynamoDB fits best, and the smallest-blast-radius data migration available once the cache wave has absorbed the read pressure.
Gate: Dual-write/backfill validated and query parity confirmed per table group. 7 tables (wordpress.wp_actionscheduler_actions, wordpress.wp_actionscheduler_groups, wordpress.wp_options, wordpress.wp_postmeta, wordpress.wp_termmeta, wordpress.wp_woocommerce_api_keys, wordpress.wp_woocommerce_order_itemmeta) stay dual-read by Aurora MySQL queries, which remain on Aurora MySQL; keep a copy in sync via CDC. 29 queries read 10 tables (wordpress.wp_actionscheduler_logs, wordpress.wp_comments, wordpress.wp_posts, wordpress.wp_term_relationships, wordpress.wp_term_taxonomy, wordpress.wp_terms, wordpress.wp_users, wordpress.wp_wc_reserved_stock, wordpress.wp_woocommerce_downloadable_product_permissions, wordpress.wp_woocommerce_order_items) Aurora MySQL owns (wave 1) and keeps owning; keep a DynamoDB copy of them in sync via CDC.
Overall risk HIGH. 2 open migration risks (2 high, 0 medium) across migration complexity, performance degradation. 6 more were resolved by the assignment. The full risk register, with per-engine detail and mitigations, and the migration trade-offs are in the Engineering Report.
Overall risk is the highest severity among the open risks; risks the assignment resolved do not count.
Mitigation strategies
wordpress_decision-report_docs-sam_20261007.html · job docs-sample · generated 2026-10-07T05:24:34+00:00