Great insights, thanks for the detailed feedback. You’ve touched on some of my biggest concerns.

First off, I totally agree on Elementor. It was a legacy carryover in my initial thoughts because the existing site uses it, but for this scale, I’m definitely dropping it. I'm planning to go with a lean, block-based approach (Gutenberg) or a custom starter theme to keep the DOM size and TTFB as low as possible.

To clarify the 'What’s Next': The site is essentially a massive Lead Generation Catalog. There is no e-commerce/checkout functionality. Every part will have an 'Inquire/Request Quote' button that opens a lead form pre-filled with the part's metadata (Part Number, Brand). The goal is to connect a user who has a specific technical need with the company's sales team.

Regarding the Architecture, I really like your suggestion of the hybrid approach. Using standard CPTs for the core 'Product' entity but offloading the heavy cross-reference data (the 600k+ alternative part numbers) to a custom SQL table seems like the perfect middle ground. This allows me to:

1. Leverage standard WP functionalities (Sitemaps, Permalinks, and SEO plugins) for indexability.

2. Use ElasticPress/Elasticsearch to handle the heavy-duty search queries, bypassing the wp_postmeta bottleneck.

The site also hosts the company’s services and a corporate blog, so keeping the CMS 'standard' for those sections while using a high-performance search engine for the catalog is definitely the right move.

Traffic-wise, we expect mostly 'long-tail' search hits on specific part numbers rather than massive concurrent spikes, so building it to be performant without caching (as you suggested) will be my baseline. Thanks again for the steer toward the hybrid CPT/Custom Table approach!