If you’ve ever tried to build a marketplace in Adalo and ended up with a tangled mess of collections that don’t talk to each other properly, you’re not alone. I’ve built over 180 apps on Adalo, and marketplaces are by far the most common type I get hired for. They’re also the most misunderstood when it comes to database structure.
This is the exact structure I use on every marketplace build. It works whether you’re building a service marketplace, a product marketplace, a rental platform, or a booking app.
The Core Problem Most Builders Make
Most people start with Users collection, then add Listings, then realize they need Orders, then add Reviews, and before long they have a database that works in isolation but breaks the moment they try to connect the pieces.
The mistake is building collection by collection instead of thinking about relationships first. Before you create a single collection in your database, you need to map out every relationship between your entities on paper. Every single one.
The 6 Core Collections Every Marketplace Needs
1. Users
One Users collection, but with role logic built in. Don’t create separate Buyer and Seller collections. Keep everyone in Users and add a field called “Role” with two options: Buyer and Seller. In many marketplace apps, users can switch between roles, so it’s better to keep them unified from the start, so it saves you a painful collections migration later.
Important properties to add: Name, Email, Profile Photo, Role, Bio, Location, Rating (number), Review Count (number).
The Rating and Review Count fields get updated via actions every time a new review is submitted. Save them on the User record directly so you can display them without loading an entire Reviews relationship every time.
2. Listings
This is the core of your marketplace app. Each listing belongs to one seller (a relationship to Users), can have many Orders, and can have many Reviews.
Important properties to add: Title, Description, Price, Category, Photos (image), Status (Active / Paused / Sold), Seller (relationship to Users), Average Rating (number).
The Status field is critical. The listing should be marked as Sold or Paused without deleting it, because you still need it attached to completed Orders for history.
3. Categories
Create a separate Categories collection so you can add, edit, or remove categories without going back into every listing. Listings have a relationship to Categories.
Important properties to add: Name, Icon, Description, Sort Order (number).
The Sort Order field lets you control the display order from the database without rebuilding your UI.
4. Orders
This is where most marketplace builds fall apart. An Order connects the buyer, the seller, and the listing in one record. This should contain 3 main relationships to have them connected properly.
Important properties to add: Buyer (relationship to Users), Seller (relationship to Users), Listing (relationship to Listings), Status (Pending / Confirmed / Completed / Cancelled), Total Price (number), Notes (text).
The reason you store both Buyer and Seller directly on the Orders collection is performance. You should never have to go Listing => Seller to find out who the seller is on an order. That path is two relationship hops and it causes performance issues in lists. Store Seller directly.
5. Reviews
Reviews connect a Reviewer (Buyer), a Reviewed User (Seller), and a Listing. All three relationships on one record.
Important properties to add: Reviewer (relationship to Users), Reviewed User (relationship to Users), Listing (relationship to Listings), Rating (number from 1 to 5), Comment (text).
6. Messages (Optional but Recommended)
If your marketplace needs in-app messaging between buyers and sellers, create a Conversations collection and a Messages collection. Conversations belong to two Users (Buyer and Seller) and have a relationship to a Listing. Messages belong to one Conversation and one Sender.
Don’t try to do messaging without this two-collection structure. A single Messages collection without Conversations creates a nightmare when filtering threads.
The Relationship Map
Before you build anything, draw this out:
-
Users => Listings (one seller has many listings)
-
Users => Orders as Buyer (one buyer has many orders)
-
Users => Orders as Seller (one seller has many orders)
-
Listings => Orders (one listing has many orders)
-
Listings => Reviews (one listing has many reviews)
-
Users => Reviews as Reviewer (one user writes many reviews)
-
Users => Reviews as Reviewed (one user receives many reviews)
-
Categories => Listings (one category has many listings)
Every one of these needs to be a proper Adalo relationship, not a text field storing an ID. If you’re storing IDs as text, your filters will break the moment your data scales.
One Practical Tip on Performance
Keep your list screens filtered as tightly as possible. A Listings list screen that loads (All listings) and then filters by category is slower than a list that uses a (Current Category) data passed from the Categories screen to the Listings list screen. Learn to pass data between screens using inputs and custom actions rather than loading large collections and filtering on screen.
What This Structure Gives You
With these 6 collections properly related, you can build: a listings feed filtered by category, a seller profile showing their listings and rating, an order history for both buyer and seller, a review system that updates ratings in real time, and an admin view that shows all orders and their statuses.
Every feature a marketplace needs comes from these relationships. The structure is the product.
If you have questions about specific relationship setups or how to handle a particular marketplace type, drop them below. I’ve built food marketplaces, service marketplaces, rental platforms, and booking apps on Adalo, and each one has its own variations on this structure.
If you have questions about your specific marketplace structure or want me to review your database setup, book a free 20-minute audit: consultation.webnux.org
Ali Bazzi | Adalo Expert and Community Leader | Founder of Webnux
Work with me: adalo.com/experts/ali-bazzi
Free audit: consultation.webnux.org