Magento + 100k+ vehicle database — does performance hold up?

Yes, with the right architecture. Three load-bearing pieces:

• Custom entity for vehicles — not Magento products. Vehicles live in their own table (auto_vehicle) with year/make/model/trim columns. Indexed on (make, model, year). 100k rows is trivial for MySQL with proper indexes — queries return in 5–15ms.
• Product-to-vehicle compatibility table — many-to-many junction (catalog_product_auto_vehicle). At 50k SKUs × ~30 vehicles per SKU = ~1.5M rows. Index on (product_id, vehicle_id). Queries for “all parts that fit this vehicle” return in 20–50ms.
• Elasticsearch as the layered-nav backend — the vehicle filter is implemented as a custom ES filter. When customer picks “2018 Honda Civic LX,” the ES query AND-filters on vehicle_ids: [12345]. Faster than MySQL JOINs at scale.

The performance trap: do NOT store vehicle compatibility as a comma-separated string in a Magento product attribute. The native EAV indexer chokes on this above 20k SKUs. Custom entity + junction table is the only sustainable model. Hyvä storefront makes the YMM picker itself snappy (Alpine.js reactive state, no full-page reload between Year → Make → Model selections). My benchmark store: 78,000 SKUs × 95,000 vehicles, layered-nav response 180ms p95.