A seller should be able to list banana bread…
with and without choco chips… at different prices.

That’s it.

But somehow, this turned into:

• product vs variant debates

• option vs attribute confusion

• structured vs flexible nightmares

Classic overengineering spiral.

The Bakery Thought Experiment

Then I imagined something very real.

You walk into a bakery.

Behind the glass, you see:

• Banana Bread = ₹199

• Banana Bread with Choco Chips = ₹249

They’re sitting right next to each other.
Different trays. Different prices. Same base item.

And your brain doesn’t go:

“Ah yes, this is one product with two variants.”

No.

Your brain goes:

“There are two things I can buy.”

That’s when it clicked

The problem wasn’t technical.

It was how I was thinking about the model.

I was forcing everything into:

“One product → many variants”

But in reality, what I had was:

• One Offering (Banana Bread)

• Multiple purchasable Products

The Mental Model Shift

Instead of this:

Product
  └── Variants (500gm, 1000gm, choco chips, etc.)

I moved to this:

Offering (Banana Bread)
  ├── Product → Classic → ₹199
  └── Product → With Choco Chips → ₹249

Each variant is not a “child object”.

It’s a real product.

Something you can:

• price independently

• track inventory for

• show directly to users

Where It Gets Messy

Then came the real problem.

How do you handle:

• size (500gm, 1000gm)

• dimensions (20x30 cake)

• weird stuff like “extra toppings” or "added cheese"

I tried two extremes:

1. Everything structured

quantity: 500
unit: gm
dimensions: {...}

Clean. Queryable. Backend-friendly.

But…

Where does “extra toppings” go?

2. Everything flexible (options)

Flavor: Butterscotch
Size: 500gm

Flexible. Easy to extend.

But…

Now you can’t filter, sort, or reason about anything properly.

The Balance That Actually Works

So I stopped trying to be perfect.

And split things into 3 layers:

1. Structured fields (for the system)

• quantity

• unit

• dimensions

• weight

Used for:

• filtering

• logistics

• analytics

2. Label (for humans)

This is the most important field.

What the customer actually sees:

• “500gm”

• “With Choco Chips”

• “Large”

This becomes the single source of truth for display

3. Optional custom options (for edge cases)

Only when needed:

• Flavor → Butterscotch

• Topping → Extra Nuts

Not forced. Not everywhere. Just when it makes sense.

The UI Changed Everything

Instead of complex variant builders…

I made it stupid simple:

*[ Label ]        → "With Choco Chips"
*[ Price ]        → ₹249

[ Quantity ]     → 500 gm
[ Dimensions ]   → L x W x H

[ Add custom option ]
  Flavor → Butterscotch
                                            [+ Add Variant]

And that’s it.

The Unexpected Truth

Most sellers don’t care about your schema.

They will just type:

• “Banana Bread”

• “₹199”

And move on.

They don’t wake up thinking:

“Should I define an option group with normalized values?”

They just want to list and sell.

Real moments where they pause

• When price changes
  → “Wait, choco chips costs more”

• When the choice is obvious
  → “Small vs Large”
  → “500gm vs 1kg”

• When customers usually ask
  → “Do you have eggless?”
  → “Do you add nuts?”

• When it affects decision-making
  → “Full hands mehendi vs half hands”
  → “Basic vs premium package”

In those moments, something shifts.

They pause and think:

“Okay… I should probably show this as an option.”

Not because your system told them to;
but because their customer expects it.

And the UI should meet them right there

No complex setup. No forced structure.

Just a simple:

[ + Add Variant ]

They click it… and add:

• a new label → “With Choco Chips”

• a new price → ₹249

• (optionally) more details if they care

No “define option groups”
No “configure attributes”
No mental overhead

Just:

“Here’s another version of the same thing I’m selling.”

The Real Lesson

Variants shouldn’t feel like configuration.
They should feel like adding another item to the shelf!

Final Takeaway

Stop trying to design the “perfect” variant system.

Instead:

• Model real-world behavior

• Keep data readable

• Allow flexibility without forcing it

That bakery shelf taught me more than hours of schema design ever did.

Panchhee isn't trying to be the most powerful marketplace.

It's trying to be the simplest one.

There are already countless marketplaces for complex setups; Panchhee is for people who just want to list and sell.

Happy Building!

The Scenario

Imagine you have two existing tables, "Shirts" and "Transactions," and you're introducing a new "Categories" table. "Shirts" table will definitely need a "category_id" as it belongs to a particular category. However, a challenge emerges when you need to list orders made of a specific category. Now, you're faced with a decision: should you map the "category_id" in the "Transactions" table or maintain it solely in the "Shirts" table? Let's explore the two options to address this issue.

Option 1: Flattened Keys - A Simplified Snapshot

Consider the following schema:

• Shirts: Keeps the shirt details like ID, description, size and category_id.

• Category: Holds the category title and description.

• Transactions: Along with purchase details, contains shirt_id and category_id as well.

Pros:

• Enhanced Performance: Queries involving category-based filtering leverage the flattened keys, leading to faster execution times.

• Simplified Queries: Retrieving orders by category becomes straightforward, requiring only querying from the "Transactions" table.

Cons:

• Maintenance Overhead: Maintaining data consistency across the tables additional processes to ensure synchronization. Let's say the category of a particular shirt is now changed. You'll need to find all orders of this shirt and update the "category_id" in the "Transactions" table as well as the "Shirts" table.

• Storage Space: This approach will also consume additional storage space, potentially impacting scalability.

Option 2: Nested Keys - Leveraging Joins

In this approach schema will be defined as:

• Shirts: Keeps the shirt details like ID, description, size and category_id.

• Category: Holds the category title and description.

• Transactions: Along with purchase details, contains shirt_id.

We can connect "Transactions" to "Shirts" with shirt_id to establish the relationship between orders and shirts. Further to join with Categories, link "Shirts" to "Category" with category_id to identify the corresponding category for each shirt within the order.

Pros:

• Data Integrity: This approach meticulously maintains the relationships between entities, ensuring data consistency and accuracy.

• Flexibility: It seamlessly handles complex scenarios involving multiple categories per order or dynamic category structures.

Cons:

• Performance Impact: The multi-step join process can incur performance penalties, especially when dealing with large datasets or frequent category-based queries.

• Query Complexity: Formulating queries to retrieve orders by category might require more intricate structures compared to the alternative approach.

Choosing the Champion:

• Flattened keys: Suited for smaller databases as it offer the simplicity and performance benefits.

• Nested Keys: Optimal for large databases prioritizing performance gains through joins, especially if data consistency and flexibility are paramount.

Future-Proofing the Database Design

As your platform evolves, anticipate potential changes in data volume, query patterns, and category structure to ensure long-term adaptability. Remember, there's no one-size-fits-all solution. Carefully weigh your data's size, query patterns, and future growth prospects to design a database that empowers efficient management and insightful analysis.

Beyond the Binary

This blog has explored two key strategies, but remember, database design is an iterative journey. Continuously monitor performance, storage usage, and data consistency. Be prepared to adapt your approach as your platform evolves, ensuring optimal efficiency and scalability.

After all, no schema is too complex, your queries are the ultimate flex!

Scenario: Imagine you're developing a database for an online vintage clothing store. You have information about shirts, sellers, and buyers, and each shirt belongs to one seller but can be purchased by multiple buyers. Do you cram everything into one giant table, or do you embrace the power of joins and spread the data across multiple tables in an organized manner?

Option 1: Single Table Oasis - Easy Setup, Limited Scalability

All data resides in a single "Shirts" table with columns for shirt details, seller ID, and buyer IDs.

Pros:

• Simple Setup: Easy to set up and understand, ideal for beginners.

• Quick Queries: Fast for basic queries like finding a specific shirt.

Cons:

• Data redundancy: When a seller has various shirts for sale, making updates to the seller information involves modifying entries across multiple rows.

• Table bloat: Large datasets lead to slower performance and complex queries. Finding all shirts from a specific seller bought by a specific buyer, is a nightmare in this schema right?

• Limited flexibility: Adding new features like purchase dates becomes cumbersome. You'll end up making the buyer field an array of objects containing buyer ID and purchase date per record in the "Shirts" table.

Option 2: Joined Flexibility - Clean Data, Future-Proof Design

Utilize three separate tables: Shirts, Sellers, and Transactions.

• Shirts: Holds shirt details like ID, description, size, and maybe a catchy slogan.

• Sellers: Houses seller information like ID, name, and shop description.

• Transactions: This table links shirts and buyers, including purchase details like price.

Pros:

• Clean data: No redundancy, updates are localized and efficient.

• Compact tables: Improved query performance even with massive datasets. For example, looking for all transactions of a specific seller is a breeze in this schema!

• Highly flexible: Easily add new features without affecting the existing structure. In this scenario, adding purchase dates will be another attribute of the "Transactions" table.

Cons:

• Efficient Planning: Requires upfront planning and understanding of joins (connecting tables).

• Complex Queries: Queries may be slightly more complex initially, but mastering joins unlocks powerful capabilities.

Choosing the Champion:

• Single Table Oasis: Suitable for small-scale projects with limited data and features and a high priority on quick basic searches.

• Joined Flexibility: Ideal for complex databases with extensive data, demanding future-proof design and scalability.

Joins are Your Homies, Not Haters!

Joins offer a powerful way to connect data efficiently and unlock the full potential of your database. Don't be afraid to embrace them and watch your database evolve from a cluttered closet to a well-organized gallery!

Normalize Your Data

Explore normalization techniques to further optimize your database structure. Think of it like decluttering your data and arranging it for optimal access and efficiency. With careful planning and execution, you can build a database that serves your needs flawlessly, no matter how your vintage clothing empire expands.

After all, no schema is too complex, your queries are the ultimate flex!