Allow non-unique barcode/ean/upc across variants — real-world barcodes are legitimately shared

[GBreg19]

What

ProductVariant enforces a global unique index on sku, barcode, ean, and upc (packages/modules/product/src/models/product-variant.ts, partial where: "deleted_at IS NULL"). This means no two active variants can share the same barcode/ean/upc.

Unique sku is reasonable — it's an internal, seller-assigned identifier. But ean/upc/barcode are externally assigned by the manufacturer and identify a product, not a single sellable unit. It's normal for genuinely distinct variants to carry the same scannable barcode.

Why this is a problem

Real catalogs reuse the same barcode across variants:

• Wine — different vintages of the same wine (modeled as variants) frequently share one EAN/barcode.
• Apparel / other goods — manufacturers sometimes assign one EAN to multiple colors/sizes.

With the current constraint these catalogs can't be modeled in Medusa, and POS barcode-scanning is forced into a one-barcode-→-one-variant assumption that doesn't hold in practice. (Related friction: #5541, where the same constraint broke product duplication and was closed unresolved.)

Proposal

Relax uniqueness on the externally-assigned identifiers while keeping sku unique. Options, in rough order of preference:

1. Drop the unique index on barcode/ean/upc (keep sku unique).
2. Make uniqueness configurable (e.g. a product-module option / feature flag) so existing behavior stays the default.

Environment

• Medusa v2 (confirmed in current main; checked against @medusajs/medusa 2.15.5).
• Constraint location: packages/modules/product/src/models/product-variant.ts.

[GBreg19]

This has been open for two weeks with no response, and it's currently blocking us in production.

To summarize the ask: ProductVariant enforces a global unique index on barcode/ean/upc (packages/modules/product/src/models/product-variant.ts). sku being unique is fine, but barcode/ean/upc are manufacturer-assigned and routinely shared across genuinely distinct variants, so real catalogs can't be modeled today.

Proposal: drop the unique index on barcode/ean/upc (keep sku unique), or make it configurable with the current behavior as default.

@shahednasser, could someone confirm whether this is something the team would accept? Happy to open a PR if so.

[tedblad]

+1, this is a much needed change for us.

We run a wine retail business on Medusa v2, with both an online storefront and an in-store POS, and we hit exactly the wine case described here. Different vintages of the same wine are naturally modeled as variants, and they very often carry the same EAN from the producer. Today the unique index forces us into workarounds that don’t reflect reality: either collapsing vintages into one variant, or storing the real barcode somewhere outside the native field, which then breaks barcode lookup at the POS.

The distinction in the proposal is the right one. SKU is ours to assign, so uniqueness makes sense there. EAN/UPC/barcode are assigned by the manufacturer and identify a product, not a specific sellable unit, so the platform shouldn’t assume a one-to-one mapping.

Either option would solve it for us. Dropping the unique index on barcode/ean/upc is the simplest, but a configurable option with the current behavior as the default would also work well and avoid surprising existing projects. On the POS side, a scan that matches several variants can simply prompt the cashier to pick the right one, which is how most retail systems handle it already.

Would be great to get a signal from the team on whether a PR along these lines would be accepted.