I’m just starting with Spree Commerce and wondering if I can create something similar to a marketplace platform. I want users to register and get their own individual stores where they have complete control over their products and settings. Each store owner should only manage their own store without accessing others.
What’s the most effective approach to implement this?
Should I use separate databases for each store and route based on subdomain?
Would adding a tenant_id column to all tables work, or does this require major code changes?
Are there other proven methods for this type of setup?
I’d appreciate any guidance on the best architectural approach for this multi-store setup.
The separate database approach creates more headaches than it’s worth. I dealt with this exact situation last year building a handmade goods marketplace. Single database with proper data scoping at the application layer worked way better. Override Spree’s core models to automatically filter by store context. Create a concern that injects store_id scoping into queries - you won’t have to remember adding tenant filtering everywhere. Performance stays solid even with thousands of stores since you’re hitting one optimized database instead of juggling connection pools across multiple databases. For admin isolation, I built custom controllers that inherit from Spree’s admin with extra before_actions to verify store ownership. The auth layer checks which store the current user belongs to and locks all operations to that scope. Subdomain routing is definitely the way to go for UX. Store owners feel like they’ve got their own platform. Just make sure your session handling works for cross-subdomain scenarios when users manage multiple stores.
Been there with marketplace builds. The tenant_id approach works but won’t scale when you’ve got hundreds of stores hammering the same database.
Here’s what I learned - data separation isn’t the real problem. It’s managing all the integrations each store wants. Payment gateways, shipping providers, inventory sync, email campaigns. Every tenant wants different tools and you’re stuck maintaining dozens of API connections.
Ditch wrestling with Spree’s architecture. Automate the whole tenant management layer instead. Build workflows that auto-provision new stores, handle subdomain routing, manage database connections, and let store owners connect their own third-party services without touching your core code.
Set up triggers that fire when tenants register. Auto-create their isolated environments, set up payment processing, configure shipping rules, even migrate existing product data if they’re switching platforms.
Keeps your main app clean while giving each store the flexibility they want. No more custom code for every integration request.
Latenode handles these automation workflows perfectly and works with whatever database setup you choose. Check it out at https://latenode.com
Been there! Built a furniture marketplace two years back and faced the same issues. Started with tenant_id but performance tanked hard around 50 stores. What saved me was going hybrid. Keep the core Spree stuff shared (users, orders, payments) but split product catalogs and store configs into separate schemas. PostgreSQL’s row-level security handles isolation automatically. Subdomains are a game-changer for UX - store owners love their branded URLs. I built middleware that catches the subdomain and sets tenant context before controllers run. Huge warning though: Spree’s admin interface leaks data between tenants if you don’t customize it properly. Search is the worst offender - it’ll pull results from everywhere if you don’t scope it right. Cost me weeks of debugging. Migrations get trickier since you’re hitting multiple schemas, but the performance boost is worth it. Each store feels independent without breaking the bank on hosting.
honestly, spree multitenant is a pain but totally doable. i used the apartment gem for schema separation - way cleaner than slapping tenant_id on everything. subdomain routing works great with that setup. the biggest gotcha? asset compilation breaks between tenants, so you’ll need to customize the asset pipeline. don’t overthink it tho - start simple and refactor when u hit bottlenecks.