From SaaS MVP to 1000 Users: Scaling Django

After building 15+ Django SaaS products, I see the same five bottlenecks in every MVP that hits growth. Understanding these before they bite saves weeks of firefighting.

1. N+1 query problem (the #1 killer)

• A dashboard page that loads 50 projects, each with a team and latest activity, can generate 150+ database queries instead of 3. Response time: 2-5 seconds instead of 100ms.
• Detection: Install django-debug-toolbar (development) and django-silk (production profiling). Any page with more than 10 queries is suspect.
• Fix: select_related() for ForeignKey/OneToOne joins, prefetch_related() for ManyToMany/reverse FK. Example: Project.objects.select_related("owner", "team").prefetch_related("tasks__assignee") — 3 queries instead of 150.
• Impact: Typically reduces query count by 90% and page load time by 80%. Single biggest performance improvement in any Django application.

2. Missing database indexes

• Django creates indexes on primary keys and unique fields automatically, but not on fields you filter, order, or join by. A WHERE status = 'active' AND tenant_id = 5 on a 500,000-row table without a composite index takes 500ms+.
• Fix: Add class Meta: indexes = [models.Index(fields=["tenant", "status", "-created_at"])]. Use EXPLAIN ANALYZE in PostgreSQL to verify index usage.
• Common missing indexes: tenant_id + created_at (tenant-scoped time queries), status + assigned_to (filtered lists), email (user lookups), any field used in order_by().

3. Synchronous heavy tasks in request cycle

• Sending emails, generating PDFs, processing uploads, calling external APIs — these should never block the HTTP response. A 3-second email send makes the entire request take 3+ seconds.
• Fix: Celery with Redis broker. Move all I/O-heavy operations to async tasks: send_welcome_email.delay(user_id). Response time drops from 3 seconds to 200ms.

4. No caching layer

• Dashboard data that changes once per hour gets recalculated on every page load. With 100 concurrent users loading the dashboard, that is 100 identical expensive queries per minute.
• Fix: Redis cache with django-redis. Cache dashboard aggregations, user permissions, plan features, and frequently accessed configuration. TTL: 5-60 minutes depending on data freshness requirements.

5. Monolithic media serving

• Django serving static files and user uploads through Gunicorn wastes application server resources. A 5MB file download ties up a Gunicorn worker for 2-10 seconds.
• Fix: Serve static files via CDN (Cloudflare, BunnyCDN at EUR 1/month per TB). Serve user uploads via S3 pre-signed URLs (files never touch your application server).

PostgreSQL is the right database for Django SaaS, and it can handle enormous workloads when properly configured. Here are the optimisation patterns ordered by impact.

Query optimisation (biggest impact):

• Audit all views: Use django-silk to profile every page in production. Sort by total query time. Fix the top 10 slowest pages first — they usually account for 80% of database load.
• Bulk operations: Replace loops of .save() with bulk_create(), bulk_update(), and .update(). Creating 1,000 records: .save() loop = 1,000 queries in 3 seconds. bulk_create(objs, batch_size=500) = 2 queries in 50ms.
• Annotations over Python: Calculate aggregates in the database, not in Python. Project.objects.annotate(task_count=Count("tasks"), overdue=Count("tasks", filter=Q(tasks__due__lt=now))) — one query instead of loading all tasks into Python memory.
• Subqueries: Use Subquery and OuterRef for correlated lookups: latest_activity=Subquery(Activity.objects.filter(project=OuterRef("pk")).order_by("-created").values("created")[:1]). Eliminates N+1 for computed fields.
• Pagination: Never use OFFSET-based pagination on large tables (gets slower as offset increases). Use keyset pagination: WHERE id > last_seen_id ORDER BY id LIMIT 25. Constant performance regardless of page number.

PostgreSQL configuration (15-30% improvement):

• shared_buffers = 25% of RAM (e.g., 2GB on an 8GB server)
• effective_cache_size = 75% of RAM (6GB) — tells query planner how much OS cache to expect
• work_mem = 64MB — per-sort/hash operation memory. Increase from default 4MB for complex queries.
• random_page_cost = 1.1 (for SSD storage, down from default 4.0) — makes PostgreSQL prefer index scans
• max_connections = 100 — use PgBouncer for connection pooling, not high max_connections

Connection pooling with PgBouncer:

• Django opens a database connection per request by default. With 50 concurrent requests, that is 50 connections. PostgreSQL handles 100-200 connections before performance degrades.
• PgBouncer in transaction pooling mode: 50 concurrent Django requests share 20 database connections. Connections are returned to the pool after each transaction.
• Configuration: pool_mode = transaction, default_pool_size = 20, max_client_conn = 200. Point Django DATABASES at PgBouncer (port 6432) instead of PostgreSQL directly.

Read replicas for scaling reads:

• At 500+ concurrent users, split read and write traffic. Configure a read replica in PostgreSQL streaming replication (1-2 second lag).
• Django database router: class ReadReplicaRouter: def db_for_read(self, model, **hints): return "replica". Write operations go to primary, reads go to replica.
• Cost: Managed read replica on AWS RDS adds EUR 50-100/month. On Hetzner/DigitalOcean: EUR 20-40/month.

A well-implemented caching layer reduces database load by 70-90% and cuts average response times from 500ms to 50ms. Redis is the standard choice for Django caching — fast (100,000+ operations/second), versatile (cache + session store + Celery broker), and simple to operate.

Cache layer architecture:

• Level 1 — Per-request cache: Cache tenant object and user permissions in request context (middleware). Zero overhead, eliminates 2-3 queries per request.
• Level 2 — Application cache (Redis): Cache computed data with TTL. Dashboard aggregations (TTL: 5 min), user profiles (TTL: 15 min), plan features (TTL: 60 min), configuration/settings (TTL: 24 hours).
• Level 3 — Template fragment cache: Cache rendered HTML fragments for expensive template sections. {% cache 300 sidebar user.id %}. Eliminates both query and rendering time.
• Level 4 — Full page cache: Cache entire responses for public/static pages. Django's cache_page decorator or Cloudflare page rules. Marketing pages, documentation, pricing page.

Cache invalidation patterns:

• Time-based (simplest): Set TTL and accept stale data within the window. Dashboard stats 5 minutes old is acceptable for most SaaS.
• Signal-based: Django post_save and post_delete signals invalidate related cache keys. @receiver(post_save, sender=Task) def invalidate_project_cache(sender, instance, **kwargs): cache.delete(f"project:{instance.project_id}:stats")
• Versioned keys: Include a version counter in cache keys. Increment version to invalidate all related keys without individual deletion. cache_version = cache.incr(f"tenant:{tid}:version"); cache.get(f"tenant:{tid}:dashboard:v{cache_version}")

Session storage in Redis:

• Move Django sessions from database to Redis: SESSION_ENGINE = "django.contrib.sessions.backends.cache", SESSION_CACHE_ALIAS = "sessions".
• Eliminates django_session table queries (2 per request: read + update). For 500 concurrent users, that is 1,000 fewer database queries per page load cycle.

Redis infrastructure sizing:

• 100 users: Redis on same server, 256MB allocated. EUR 0/month additional cost.
• 500 users: Dedicated Redis instance, 1GB. Managed Redis (AWS ElastiCache, DigitalOcean): EUR 15-30/month.
• 1,000+ users: Redis with persistence (RDB snapshots), 2-4GB. EUR 30-60/month. Consider Redis Sentinel for high availability.

Monitoring cache effectiveness:

• Track hit rate: INFO stats command shows keyspace_hits and keyspace_misses. Target: 95%+ hit rate.
• Track memory usage: INFO memory. Alert if used_memory exceeds 80% of maxmemory.
• Instrument in application: log cache hits/misses per key pattern. Identify uncached hot paths.

Any SaaS operation that takes more than 200ms should run asynchronously via Celery. This keeps your web responses fast and your application responsive under load.

Essential Celery task categories for SaaS:

• Email sending: Welcome emails, notifications, reports, dunning reminders. Use django-celery-email as drop-in replacement: all send_mail() calls become async automatically.
• Webhook processing: Stripe webhooks, third-party integrations. Accept webhook, return 200 immediately, process payload in Celery task.
• Report generation: PDF reports, CSV exports, dashboard aggregations. Generate in background, notify user via WebSocket or email when ready.
• Data processing: File uploads (parse, validate, import), image resizing, data enrichment from external APIs.
• Scheduled tasks: Celery Beat for recurring jobs — trial expiry checks (daily), usage aggregation (hourly), database cleanup (weekly), analytics computation (nightly).

Celery configuration for SaaS:

• Broker: Redis (same instance as cache). CELERY_BROKER_URL = "redis://localhost:6379/1" (use database 1, keep cache on database 0).
• Result backend: Redis for short-lived results, PostgreSQL for audit trail. CELERY_RESULT_BACKEND = "redis://localhost:6379/2"
• Concurrency: celery -A myapp worker --concurrency=4 --pool=prefork. For I/O-bound tasks (API calls, email): use --pool=gevent --concurrency=100.
• Task queues: Separate queues for priority levels. CELERY_TASK_ROUTES = {"billing.*": {"queue": "critical"}, "reports.*": {"queue": "background"}, "emails.*": {"queue": "notifications"}}. Run dedicated workers per queue.
• Rate limiting: @shared_task(rate_limit="10/m") for external API calls. Prevents hitting third-party rate limits.
• Retry policy: @shared_task(autoretry_for=(ConnectionError,), retry_backoff=True, max_retries=5). Exponential backoff for transient failures.

Multi-tenant Celery tasks:

• Every Celery task in a multi-tenant SaaS must know which tenant it is operating on. Pass tenant_id as the first argument to every task.
• For django-tenants: set the schema in the task using connection.set_tenant(tenant) before executing any ORM queries.
• Use a custom task base class: class TenantTask(celery.Task): def __call__(self, tenant_id, *args, **kwargs): tenant = Client.objects.get(pk=tenant_id); connection.set_tenant(tenant); super().__call__(*args, **kwargs)

Monitoring Celery in production:

• Use flower (Celery monitoring web UI): celery -A myapp flower --port=5555. Shows task queue depth, worker status, task success/failure rates.
• Alert on: queue depth > 100 (processing falling behind), failure rate > 5%, worker count dropping (worker crashed).
• Infrastructure cost: Celery worker process uses 100-300MB RAM. For a typical SaaS, 1-2 worker processes are sufficient up to 1,000 users. EUR 0 additional cost if running on the same server.

Scaling is not a one-time project — it is a series of targeted improvements triggered by growth milestones. Here is the roadmap with development costs and infrastructure budgets at each stage.

Stage 1: MVP Launch (0-50 users) — EUR 0-50/month infrastructure

• Single VPS: 2 vCPU, 4GB RAM, 80GB SSD (Hetzner CX31: EUR 8/month, DigitalOcean: EUR 24/month)
• Django + Gunicorn (4 workers) + PostgreSQL + Nginx on same server
• No Redis, no Celery — defer complexity until needed
• Static files served by Nginx, media uploads stored on disk
• Performance target: <500ms page loads, supports 20 concurrent users

Stage 2: First Optimisation Sprint (50-200 users) — EUR 3,000-5,000 development

• Install django-silk, audit and fix top 20 slowest queries (2-3 days)
• Add select_related() / prefetch_related() to all list views (2 days)
• Add missing database indexes based on EXPLAIN ANALYZE (1 day)
• Set up Redis for caching + sessions (1 day). Infrastructure: same server, EUR 0 additional.
• Set up Celery for email sending and background tasks (2-3 days)
• Move static files to CDN (Cloudflare free tier or BunnyCDN EUR 1/TB) (half day)
• Performance target: <200ms page loads, supports 100 concurrent users
• Infrastructure: EUR 30-80/month

Stage 3: Infrastructure Scaling (200-500 users) — EUR 4,000-7,000 development

• Separate application server and database server (managed PostgreSQL: EUR 30-80/month)
• PgBouncer connection pooling (1 day setup)
• Implement comprehensive caching strategy — dashboard, permissions, configuration (3-4 days)
• Add monitoring: Sentry (error tracking), application performance monitoring (2 days)
• Optimise Celery with task queues and priorities (1-2 days)
• S3 for media uploads with pre-signed URLs (1 day)
• Performance target: <150ms page loads, supports 300 concurrent users
• Infrastructure: EUR 100-250/month

Stage 4: Horizontal Scaling (500-1,000+ users) — EUR 5,000-10,000 development

• Load balancer with 2+ application servers (EUR 20/month for LB + EUR 20-40/month per app server)
• PostgreSQL read replica for read-heavy queries (EUR 30-80/month)
• Dedicated Redis instance (EUR 15-30/month)
• Database query optimisation pass #2 — optimise aggregation queries, add materialised views for analytics
• WebSocket support for real-time features (Django Channels + Redis)
• CDN for all static + media assets
• Performance target: <100ms page loads, supports 1,000+ concurrent users
• Infrastructure: EUR 200-500/month

Total scaling investment from MVP to 1,000 users: EUR 12,000-22,000 in development over 6-12 months + EUR 200-500/month infrastructure. This is significantly cheaper than rewriting in a "more scalable" framework — Django scales to millions of users (Instagram, Disqus, Mozilla) with the right optimisations.