A production-ready multi-vendor marketplace database schema inspired by platforms like Etsy, Amazon Marketplace, and Shopify. Includes user accounts, vendor store management, product listings with per-store pricing, order processing, customer reviews with ratings, and automated payout tracking for sellers. Designed to handle multiple independent sellers operating under a single marketplace umbrella.
An order belongs to one store, not to a basket. orders carries both buyer_id and store_id, so a cart spanning three vendors becomes three orders — which is the only arrangement where each seller ships, is paid and is disputed independently. The shared checkout is an application concern; the database records what each store actually owes and is owed.
There are two kinds of review and they answer different questions. store_reviews rates the vendor, while reviews rates a product and points at an order_item. That third key is what makes a review verifiable: it can only be written by someone whose order actually contained the thing being reviewed.
Money owed to sellers is its own table rather than a sum over orders. payouts stores the amount, the commission taken, a period and a status, because settlement runs on its own clock — a payout covers a date range regardless of which orders fall inside it, and it can be pending, paid or failed independently of whether the orders were delivered.
Splitting the cart at checkout feels like extra work and removes an entire class of problems. A single order spanning vendors would need per-store status, per-store shipping and per-store disputes inside one row, and a refund from one seller would have to partially cancel a shared total. Separate orders make each of those the normal path. The price is that the buyer's single payment has no row of its own here.
The rate is current policy and can be renegotiated; the amount is what was actually withheld for a settled period. Keeping only the rate would make every historical payout recalculate against today's terms, which is exactly the number a seller will dispute. Storing both means a rate change applies going forward and never rewrites what was already paid.
Sellers edit and delete listings constantly on a marketplace. The copied name keeps an order readable when the product is gone, while the id keeps the link for reviews and reordering. The duplication is deliberate: one column is for display and is frozen, the other is for identity and is live.
A role column instead of two tables, because the same person sells and buys, and splitting them would duplicate every account and make a seller reviewing another store impossible to represent. The cost is that seller-only fields have nowhere natural to live — they end up on stores, which is why the storefront, not the user, carries the commission rate and the activation flag.