A product has a size, a color, maybe a material.

Then the real requirements arrive.

You need different prices, different stock levels, different SKUs, optional images, disabled combinations, campaign prices, and sometimes completely custom option groups.

At that point, product variants stop being a frontend problem and become a data-modeling problem.

This article explains a practical way to structure product variants in a modern e-commerce application using Next.js, Prisma and PostgreSQL.

The basic problem

Imagine a product like a chair.

It may have:

• Color: Black, White, Walnut

• Fabric: Linen, Velvet

• Leg Type: Metal, Wood

If every combination is valid, that already creates:

3 × 2 × 2 = 12 variants

For each variant, we may need to store:

• SKU

• stock

• price

• discounted price

• barcode

• weight

• image

• active/inactive status

The important part is that the product itself and the sellable combinations should be modeled separately.

A simple product model

A simplified Prisma model may start like this:

model Product {
  id          String           @id @default(cuid())
  name        String
  slug        String           @unique
  description String?
  variants    ProductVariant[]
  options     ProductOption[]
  createdAt   DateTime         @default(now())
  updatedAt   DateTime         @updatedAt
}

The Product represents the main catalog item.

For example:

Modern Armchair

The actual purchasable combinations live in ProductVariant.

Product options

Options define the configurable dimensions of a product.

For example:

model ProductOption {
  id        String               @id @default(cuid())
  name      String
  productId String
  product   Product              @relation(fields: [productId], references: [id])
  values    ProductOptionValue[]
}

An option can be:

Color
Fabric
Size
Material

Then each option contains values:

model ProductOptionValue {
  id       String        @id @default(cuid())
  value    String
  optionId String
  option   ProductOption @relation(fields: [optionId], references: [id])
}

For example:

Color
  - Black
  - White
  - Walnut

This structure is much more flexible than adding columns like:

color
size
material

directly to the product table.

Product variants

Now we can define the sellable combination.

model ProductVariant {
  id        String   @id @default(cuid())
  productId String
  product   Product  @relation(fields: [productId], references: [id])

  sku       String   @unique
  price     Decimal
  stock     Int      @default(0)
  isActive  Boolean  @default(true)

  values    ProductVariantValue[]
}

The ProductVariantValue table connects a variant to its selected option values.

model ProductVariantValue {
  id            String             @id @default(cuid())
  variantId     String
  optionValueId String

  variant       ProductVariant     @relation(fields: [variantId], references: [id])
  optionValue   ProductOptionValue @relation(fields: [optionValueId], references: [id])

  @@unique([variantId, optionValueId])
}

This gives us a normalized structure.

A variant might represent:

Black + Velvet + Metal

while another represents:

Walnut + Linen + Wood

Why not store variants as JSON?

JSON is tempting.

For example:

{
  "color": "Black",
  "fabric": "Velvet",
  "legType": "Metal"
}

PostgreSQL handles JSONB very well, and in some systems this is completely valid.

But there are trade-offs.

Relational variant tables make it easier to:

• enforce references

• query by option

• build filters

• maintain consistent option values

• manage inventory

• prevent invalid data

• create admin tools

JSONB becomes attractive when the product schema is extremely dynamic.

For many standard e-commerce systems, I still prefer a relational core.

Variant uniqueness

One important requirement is preventing duplicate combinations.

You do not want two variants representing:

Black + Velvet + Metal

for the same product unless there is a very specific business reason.

This cannot always be solved with a simple database constraint because the combination is represented through multiple rows.

A practical solution is to generate a normalized combination key.

For example:

color:black|fabric:velvet|leg:metal

Then store it on the variant:

model ProductVariant {
  id             String  @id @default(cuid())
  productId      String
  combinationKey String

  @@unique([productId, combinationKey])
}

Before saving:

const combinationKey = selectedValues
  .sort((a, b) => a.optionId.localeCompare(b.optionId))
  .map(x => `${x.optionId}:${x.valueId}`)
  .join('|')

This makes duplicate detection much easier.

Stock belongs to the variant

A common mistake is storing stock only on the product.

That works until different combinations have different inventory levels.

For example:

Black / Small  -> 8
Black / Large  -> 2
White / Small  -> 0
White / Large  -> 5

The real inventory unit is the variant, not the parent product.

So in most cases:

ProductVariant.stock

is the correct place for inventory.

The product-level stock can then be calculated:

const totalStock = product.variants.reduce(
  (total, variant) => total + variant.stock,
  0
)

Pricing strategy

Pricing can also exist at different levels.

A useful model is:

• Product has a base price

• Variant can optionally override the price

For example:

model Product {
  basePrice Decimal
}

and:

model ProductVariant {
  price Decimal?
}

Then:

const finalPrice = variant.price ?? product.basePrice

This works well when most variants share a price but a few combinations cost more.

Variant images

Images are another interesting case.

Sometimes the image belongs to the product.

Sometimes it belongs to the variant.

For example:

Black chair -> black chair images
White chair -> white chair images

A useful approach is allowing both.

model ProductVariantImage {
  id        String         @id @default(cuid())
  url       String
  sortOrder Int            @default(0)
  variantId String
  variant   ProductVariant @relation(fields: [variantId], references: [id])
}

Then the frontend can fall back to product images if the variant has no custom image.

Querying products efficiently

Variant-heavy product queries can become expensive if every relation is always loaded.

A naive query like this:

await prisma.product.findUnique({
  where: { slug },
  include: {
    options: {
      include: {
        values: true
      }
    },
    variants: {
      include: {
        values: {
          include: {
            optionValue: true
          }
        }
      }
    }
  }
})

may be completely fine for smaller catalogs.

But as the dataset grows, it is worth thinking about:

• selecting only required fields

• pagination

• caching

• separate inventory queries

• denormalized read models

• server-side caching

The right optimization depends on the real traffic pattern.

Building the frontend selector

Once the data model is clean, the frontend becomes easier.

The frontend usually needs:

1. available options

2. selected values

3. matching variant

4. price

5. stock

6. images

A simplified variant lookup can look like this:

function findVariant(variants, selections) {
  return variants.find(variant =>
    Object.entries(selections).every(([optionId, valueId]) =>
      variant.values.some(
        item =>
          item.optionId === optionId &&
          item.valueId === valueId
      )
    )
  )
}

In production, I normally transform variant data into a structure optimized for lookup rather than scanning all variants every time the user changes an option.

Disable impossible combinations

A better UX does not let users select combinations that do not exist.

Suppose:

Black + Velvet

exists, but:

White + Velvet

does not.

When the user selects White, Velvet should become unavailable.

This requires checking valid combinations after every selection.

It is one of the areas where good backend modeling directly improves frontend UX.

Admin panel matters too

The hardest part of variants is often not the customer-facing selector.

It is the admin panel.

A practical admin interface should allow users to:

• define option groups

• add option values

• generate combinations

• disable invalid combinations

• update stock in bulk

• update prices in bulk

• edit SKUs

• assign images

• search variants

If the merchant has 150 variants, editing each one manually becomes painful very quickly.

Bulk operations are essential.

When the model needs to become more flexible

Some businesses need more than standard variants.

Examples include:

• custom dimensions

• made-to-order furniture

• configurable industrial products

• engraving

• free-text customization

• quantity-based pricing

At that point, it may make sense to separate:

Variant options

from:

Configuration options

A configuration option does not always create a new inventory unit.

For example, engraving text should not generate thousands of SKU variants.

This distinction is important in custom e-commerce systems.

Final thoughts

Product variants are not just a UI feature.

They affect:

• catalog architecture

• inventory

• pricing

• filtering

• product feeds

• order items

• admin UX

• performance

A good variant model should remain understandable when a store grows from 20 products to several thousand.

For most projects, I prefer a relational structure with:

Product
ProductOption
ProductOptionValue
ProductVariant
ProductVariantValue

and then add denormalization only when real performance requirements justify it.

We use similar architecture decisions when building custom e-commerce systems at Iconium Bilişim.

The goal is not to create the most complicated schema possible.

The goal is to build a model that stays predictable as the business grows.