What's new
Chat on WhatsApp
Toggle Nav
My Cart
Magento Glossary · Product Types

What is a Magento configurable product?

A Magento configurable product is a parent product whose variants are separate simple products, one for each combination of attribute values such as size and color. It is one of the six product types Magento ships with: simple, configurable, bundle, grouped, virtual, downloadable. On apparel catalogs it is the type I use most.

Below I cover how the parent and child link is stored, where configurable fits and where it does not, the mistakes I find most often in catalog audits, and answers on variant limits, regional pricing, MSI and Hyvä.

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 holds the catalog identity: URL, SEO fields, base image, description. Each combination of configurable attributes (size, color, capacity) points to a child simple product, and that child carries the real SKU, price, weight and stock. The shopper picks values from swatches or dropdowns, Magento matches the combination to one child, and that SKU goes into 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

Here is how Magento connects a configurable parent to its variants in the database, the indexers and the storefront. This is the level of detail I need when a swatch picker breaks.

  1. 1

    Parent product holds the catalog metadata

    The parent stores the name, description, base image, category links, URL key and SEO meta. It has no price or stock of its own; those live on the children. Shoppers land on the parent page and choose a variant before they can add to cart.

  2. 2

    Each variant is a separate simple product

    Each combination of values (for example medium / red / slim-fit) is its own simple product with its own SKU, price, special_price, weight, image and stock record. I set these children to Not Visible Individually so they don’t get their own product page.

  3. 3

    Parent ↔ child link via super_link table

    The link lives in catalog_product_super_link (one row per parent and child pair) and in catalog_product_relation, which the indexers read when they roll child data up to the parent. When I debug a variant that won’t show, these two tables are the first thing I query.

  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 product page Magento outputs a JSON map (jsonConfig) of the valid combinations with each child’s ID, price and image. The swatch script reads it, swaps the gallery and updates the price. Add to cart sends the parent ID plus the chosen attribute values, and Magento resolves them to the child on the server. On Hyvä the same JSON feeds an Alpine.js component instead of jQuery.

When to use it

Four real-world patterns, and one anti-pattern

Three catalogs where configurable is the right choice, and one case that belongs in Custom Options instead.

  • Apparel & fashion

    size × color × fit

    The standard case. A T-shirt parent with size (XS-XXL), color (8 swatches) and fit (slim, regular, relaxed) gives 6 × 8 × 3 = 144 children. I use visual swatches for color and dropdowns for size and fit.

  • Electronics

    storage + RAM + carrier

    Phones, laptops and tablets suit configurable when storage tiers or unlocked and carrier-locked versions differ in price and stock. If each colour has its own marketing page, I leave colour out of the combination and split it into separate parents, so the pages don’t compete with each other in search.

  • Furniture & home

    fabric × finish × dimension

    Sofas, tables and beds work as configurable for fabric and finish. A 6-fabric × 4-finish × 8-size sofa is 192 children, which is fine. Add cushion firmness and leg style and you pass 1,000 children and the admin grid slows down. At that point I move some choices to Custom Options.

  • When NOT to use configurable

    unique-per-product variants

    If a choice is unique to one order (engraving text, monogram font, a custom inscription), it is a Custom Options job, not a configurable one. Configurable works for shared attributes picked from a list. Free 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