Marketplace, built on every verified stack.
Two-sided marketplace: seller profiles, a listings catalog, buyer orders with price capture, periodic seller payouts, and per-listing reviews.
40 verified stacks
Showing 12 across 1 app types. Every stack page links its neighbours along each axis, so any combination is a click or two from here.
What Marketplace gives you
A marketplace has two sides and a fee in the middle, and the tables split along exactly that line. sellers is the supply side: one profile per identity, enforced by sellers_user_unique on user_id, holding a display_name, an opaque payout_account_id (Stripe Connect, PayPal — nullable until onboarding finishes) and a status of pending, active or suspended. The demand side has no table of its own; buyers are Better Auth users referenced straight from marketplace_orders.buyer_id and reviews.reviewer_id. That asymmetry is the design: selling is an application somebody approves, buying is just having an account. listings hangs off seller_id with ON DELETE CASCADE and carries price_cents plus a draft → active → sold → archived status.
marketplace_orders references its listing with no delete rule at all, which is deliberate — the database refuses to remove a listing that has been bought, and because listings cascade from sellers, deleting a seller who ever sold anything fails loudly instead of shredding order history. The order's amount_cents is captured at purchase, so a seller editing their price afterwards moves the storefront and never the receipt, and its status walks six values (pending, paid, shipped, completed, refunded, canceled) because a two-sided order can end in a refund as easily as in delivery. payouts is the leg most schemas of this shape get wrong.
It stores the net remitted to a seller — bigint cents, gross minus your fee — for a text period such as '2026-06', under a unique constraint on (seller_id, period). That constraint is the safety rail: a payout job rerunning after a crash collides on insert instead of paying June twice, which is the failure nobody notices until the money is gone. Its own status column (scheduled, processing, paid, failed) with idx_payout_status gives you a queue to drain. reviews is the trust layer, and it is constrained rather than trusted: one row per (listing_id, reviewer_id), and reviews_rating_check pins rating between 1 and 5 in the database rather than in a form validator.
Reviews attach to listings, not to sellers, so seller reputation is an aggregate you compute across a seller's catalog — a join, not a column.
Built for
sellers.status is text under sellers_status_check (pending/active/suspended) with idx_seller_status over it, so the approval queue is one index scan; sellers_user_unique stops a single identity holding two profiles.
idx_listing_seller on listings.seller_id serves the seller's own page; idx_listing_status serves public browse filtered to 'active', both reading the same draft/active/sold/archived column.
marketplace_orders carries idx_order_buyer on buyer_id (a text FK to Better Auth's user.id) and idx_order_listing on listing_id, so reconciliation is an index lookup from either direction.
payouts_seller_period_unique on (seller_id, period) makes a rerun of the payout job collide on insert rather than remit June a second time, while idx_payout_status drains the scheduled and processing rows.
reviews_listing_reviewer_unique on (listing_id, reviewer_id) allows a reviewer exactly one review, idx_review_listing aggregates them for the listing page, and reviews_rating_check keeps rating inside 1–5.
Why Marketplace, specifically
Order amountCents is captured at purchase time independently of the listing's priceCents — editing a listing price later cannot corrupt historical order records.
Payouts enforce a unique constraint on (sellerId, period), so each seller gets exactly one settlement row per billing window; duplicate payout jobs are rejected at the DB level.