ArchVizs
AboutHow it WorksPricingGalleryBlog
Log InGet Started
AboutHow it WorksPricingGalleryBlog

Log InGet Started
Back to Blog
Engineering12 min read

Building a Multi-Tenant 3D Platform at Scale

January 20, 2026

Building a Multi-Tenant 3D Platform at Scale

Scaling a 3D visualization platform to serve thousands of design studios simultaneously presents unique engineering challenges. Here's how we built ArchVizs's multi-tenant architecture.

The Tenancy Model

We chose a shared database with Row Level Security (RLS) over separate databases per tenant. Every table has a `tenant_id` column, and PostgreSQL RLS policies ensure complete data isolation at the database level.

This approach gives us the isolation guarantees of separate databases with the operational simplicity of a single database. Migrations run once, not thousands of times.

Storage Architecture

Each tenant's files (panoramas, 3D models, textures) are stored in isolated paths: `/{tenant_id}/projects/{project_id}/rooms/{room_id}/`. Supabase Storage policies enforce path-based access control, and Cloudflare CDN caches assets at the edge for fast global delivery.

The Rendering Pipeline

When a user requests a panorama render, the job enters a BullMQ queue backed by Upstash Redis. Worker processes on Railway pull jobs and execute Blender Cycles renders on Modal GPU instances. Results are uploaded to storage and the user is notified via Novu.

Real-Time Collaboration

Supabase Realtime enables live cursor presence and simultaneous editing. When two designers are working on the same project, they see each other's changes in real-time without conflicts.

Performance at Scale

  • **CDN-first delivery**: Panorama images (20-50MB each) are served from Cloudflare's edge, not our origin
  • **Progressive loading**: Low-res thumbnails load instantly, high-res tiles stream on demand
  • **Connection pooling**: Supabase's PgBouncer handles thousands of concurrent database connections
  • **Rate limiting**: Per-tenant rate limits via Upstash prevent any single tenant from affecting others

Lessons Learned

  1. RLS is powerful but requires careful testing — we run integration tests that verify tenant A cannot access tenant B's data
  2. JSONB columns are incredibly flexible for tenant-specific settings but need GIN indexes for query performance
  3. Presigned URLs for storage are essential — never expose raw storage paths
  4. Feature flags per tenant (via PostHog) let us roll out changes gradually

Building for multi-tenancy from day one was the right call. Retrofitting isolation is orders of magnitude harder than designing it in.

Ready to create stunning visualizations?

Start your free account and bring your designs to life in 3D.

Get Started for Free
ArchVizs

The modern platform for stunning 3D interior visualizations.

  • Features
  • Pricing
  • Gallery
  • Demo
  • Blog

Product

  • Features
  • Pricing
  • Gallery
  • Demo
  • Blog
  • About
  • Careers
  • Contact

Company

  • About
  • Careers
  • Contact
  • Terms of Service
  • Privacy Policy
  • Cookie Policy
  • DPA

Legal

  • Terms of Service
  • Privacy Policy
  • Cookie Policy
  • DPA
  • Twitter
  • LinkedIn
  • GitHub
  • Discord

Connect

  • Twitter
  • LinkedIn
  • GitHub
  • Discord

© 2026 ArchVizs. All rights reserved. Website created by Tech Service 4U Inc

TwitterLinkedInGitHub