Chat on WhatsApp
  • Sign In
  • Create an Account
Toggle Nav
My Cart
Account
Magento Glossary · Product Types

What is a Magento configurable product?

A Magento configurable product is a parent product whose child variants are individual simple products, each defined by a unique combination of attribute values (e.g. size + color). It’s one of Magento’s six native product types: simple, configurable, bundle, grouped, virtual, downloadable.

Below: a 5-step technical breakdown of how the parent ↔ child link is stored, four real-world use-case patterns (apparel, electronics, furniture, when not to use it), four mistakes that bite stores in production, and six FAQs covering variant ceilings, regional pricing, MSI, and Hyvä compatibility.

Type: DefinedTerm Read: 6 min Adobe Certified author Updated May 2026
TL;DR Definition

Configurable product = parent + child simples linked by attribute combinations

The parent owns the catalog identity (URL, SEO, base image, description). Each combination of configurable attributes — size, color, capacity, etc. — points to a child simple product that carries the actual SKU, price, weight, and stock. The customer picks attribute values via swatches/dropdowns; Magento resolves the picked combination to one child SKU and adds that to the cart.

  • Magento product types: simple · configurable · bundle · grouped · virtual · downloadable (6 native types)
  • DB tables involved: catalog_product_super_link · catalog_product_super_attribute · catalog_product_relation
  • Variant ceiling: ~1,000 active children before admin grid + indexers degrade
  • Best for: apparel, electronics, furniture — anywhere customers pick a pre-built variant
How it works

Five steps from parent record to a variant in the cart

How Magento stitches a configurable parent to its variants on the database, the indexers, and the storefront — at the level of detail you’d need to debug a broken swatch picker.

  1. 1

    Parent product holds the catalog metadata

    The configurable parent stores the canonical name, description, base image, category assignments, URL key, and SEO meta. It never has its own price or stock — those live on the children. Customers land on the parent PDP and pick a variant before checkout.

  2. 2

    Each variant is a separate simple product

    Every combination of attribute values (e.g. medium / red / slim-fit) becomes its own simple product with a unique SKU, price, special_price, weight, image and inventory record. The variant simples are usually flagged not visible individually so they don’t generate their own PDP.

  3. 3

    Parent ↔ child link via super_link table

    The relationship is stored in catalog_product_super_link (one row per parent→child mapping) and catalog_product_relation. There’s no foreign key constraint — orphan rows can accumulate after deletes if you don’t use the repository API.

  4. 4

    Configurable attributes drive the picker

    Which attributes act as variants is declared in catalog_product_super_attribute. Each attribute must be Global scope, dropdown / visual swatch input, and Used in Configurable Product = Yes in the EAV definition. Any attribute that fails one of those three checks won’t even appear in the wizard.

  5. 5

    Frontend swatches resolve combinations to a child SKU

    On the PDP, Magento ships a JSON map (jsonConfig) of every valid attribute-value combination → child product ID, price, stock and image. The swatch JS picks one combination, swaps the gallery, updates price, and posts the child product’s ID into the cart. On Hyvä the same JSON drives an Alpine.js component instead of jQuery.

When to use it

Four real-world patterns — and one anti-pattern

Three industries where configurable is the right call, plus the one shape that always belongs in Custom Options instead.

  • Apparel & fashion

    size × color × fit

    The classic configurable case. A T-shirt parent with size (XS-XXL), color (8 swatches), and fit (slim / regular / relaxed) yields 6 × 8 × 3 = 144 child variants — well within healthy limits. Visual swatches show fabric color, dropdowns handle size and fit.

  • Electronics

    storage + RAM + carrier

    Phones, laptops and tablets benefit from configurable when storage tiers and unlocked / carrier-locked SKUs differ in price and stock. Avoid mixing colour into the combination if you have separate marketing pages per colour — split into multiple parents instead so SEO doesn’t cannibalise.

  • Furniture & home

    fabric × finish × dimension

    Sofas, tables and beds use configurable for fabric and finish but switch to Custom Options the moment the combinations exceed ~1,000 — a 6-fabric × 4-finish × 8-size sofa = 192 children, still fine; add cushion-firmness × leg-style and you cross 1k and the admin grid drags.

  • When NOT to use configurable

    unique-per-product variants

    If each variant has a one-off attribute that no other product reuses (engraving text, monogram font, custom inscription), you’re building a Custom Options scenario, not a configurable. Configurable’s strength is shared, dropdown-driven attributes — text input belongs in Custom Options or a Bundle.

Common mistakes

Four configurable-product mistakes that bite stores in production

Patterns I see most often when auditing existing Magento catalogs — every one is fixable, but only if you spot it before the catalog hits 5,000 products.

  • Variant explosion (>1,000 children per parent)

    A configurable with 5 attributes × 10 values each = 100,000 theoretical combinations. Even if you only seed the realistic ones, the admin product grid, indexers, and frontend jsonConfig all get punished. Hard ceiling: ~1,000 active variants. Above that, split into multiple parents or move some axes to Custom Options.

  • Variant SEO competing with the parent

    If you forget to flag child simples as not visible individually + leave the canonical empty, every variant gets indexed as its own URL — and Google sees 8 near-duplicate pages all targeting "blue medium T-shirt". Always set visibility = Not Visible Individually on children and let the parent own the canonical.

  • Picking configurable when Bundle would fit

    If the customer needs to build the product from independently-priced components (PC build, gift hamper, kit), use Bundle, not configurable. Bundle lets each option carry its own price delta and stock; configurable forces every combination to pre-exist as a child SKU — wrong shape for build-your-own UX.

  • Mixing Custom Options into configurable variants

    You can technically attach Custom Options to a configurable parent, but the price impact compounds confusingly: the variant child sets the base price, then Custom Options stack on top. Customers can’t tell which is which on the cart line. Pick one mechanism per product — configurable for a small set of shared axes, Custom Options for everything bespoke.

Related
FAQ

Six questions stores ask before committing to configurable

  • Configurable vs simple — when do I pick which?

    Use a simple product when there’s exactly one SKU and price (a single-size candle, a hardcover book, a poster). Use a configurable when the same logical product comes in multiple shared attribute combinations (sizes, colors, capacities) that the customer picks before adding to cart and each combination has its own SKU + stock.

    Rule of thumb: if the cart line item needs to be different from the URL the customer landed on, you need configurable. If they’re identical, simple is enough.

  • Configurable vs Bundle — what’s the actual difference?

    Configurable = customer picks ONE pre-built combination (a Medium / Red / Slim-Fit T-shirt). The cart adds one child SKU. Bundle = customer assembles a kit from independently-priced options (PC build: pick CPU, RAM, GPU, case). The cart can list each component separately or as a single bundle line.

    Decision tree:

    • Customer is choosing among variants of one thing → configurable
    • Customer is composing a thing from parts → Bundle
    • Customer is adding free-form text / image to a thing → Custom Options
  • How many variants is too many?

    The Magento docs don’t set a hard cap, but real-world pain starts around 500 variants per parent and gets unworkable past 1,000. Symptoms: admin product grid times out, catalog_product_price indexer takes hours, frontend jsonConfig blob exceeds 1 MB and slows TTFB by 200-400 ms.

    Mitigations: enable Asynchronous Indexing, paginate the admin grid, and most importantly — split big configurables into multiple parents. A "shoes" parent with 8 colours × 14 sizes × 3 widths = 336 variants is fine. The same with 5 fabrics × 6 toe-shapes added = 10,080 is not.

  • Can I override a variant’s price per region or store?

    Yes — variants are full simple products, so every store-scope override that works on a simple works on a variant. Set the variant’s price, special_price, tier_price, and tax class at the store-view scope and Magento honours it independently from the parent.

    Common pattern: parent stays at Default Config (price hidden), variants carry per-region price tiers. Couple this with Customer Group tier prices for B2B-style overrides without spawning duplicate children.

  • How does inventory work — at parent or child level?

    Always at the child level. The parent reports an aggregated in-stock if at least one child has stock and an out-of-stock only when every child is exhausted. With Multi-Source Inventory (MSI) enabled, each child has its own per-source stock row, and the salable-quantity calculation rolls up to the parent.

    Watch out for: Backorders setting — when set on the parent it doesn’t propagate; you have to set it per child. Same for Notify for Quantity Below low-stock alerts.

  • Are configurable products fully Hyvä compatible?

    Yes — Hyvä ships first-class configurable PDP support out of the box. The Alpine.js + Tailwind variant picker reads the same jsonConfig blob Luma uses, so swatches, price updates, and image-gallery swaps work without extra modules. No Hyvä Compatibility Module needed for stock configurable functionality.

    Where you do need work: third-party swatch enhancers, visual configurators, or product matrix grids from Luma extensions almost never have Hyvä equivalents — those need a rewrite. Run the compatibility checker on each extension before quoting a Hyvä migration.

Building a fashion or apparel catalog?

Configurable products are the backbone of every Magento apparel store — but only if size / color / fit are modelled cleanly and the variant ceiling is respected. See the full apparel-vertical playbook for swatch UX, lookbook integration, and inventory rollups.

See Magento for fashion