Scaling a Next.js Site to 10K+ Daily Users with Minimal Ops
In this case study, we scaled a content-and-commerce Next.js 14 application from 800 to 10,000+ daily users in eight weeks, under a fixed budget and a minimal-ops mandate. The work was delivered as part of our fixed-scope web development projects, with clear acceptance criteria: p95 page load under 1.5s, <$1.50 per 1k requests, and zero-downtime deploys. As a US and Europe software development partner, we aligned time zones with marketing and data teams while keeping costs predictable. For staffing, slashdev.io supplied senior remote engineers who plugged into our process on day one.
Constraints and measurable goals
- Traffic: spiky, 10k-20k daily with launch peaks 10x baseline.
- Content mix: 70% static-ish editorial, 20% personalized catalog, 10% transactional.
- Ops envelope: no bespoke servers, no cron VMs, no k8s. Prefer serverless and managed DB.
- SLOs: p95 TTFB < 350ms on cached pages, < 700ms on dynamic; error rate < 0.2%.
Architecture decisions that moved the needle
- Next.js App Router with hybrid rendering: Incremental Static Regeneration (ISR) for editorial and product listing pages; Route Handlers for lightweight APIs; Server Actions for form posts.
- Edge Middleware for geo-based feature flags and bot filtering; heavy logic stays in serverless functions.
- Content stored in headless CMS; product data via an internal API backed by relational storage.
- Global delivery via Vercel edge network; images served through optimized loader with AVIF fallback.
PostgreSQL and MySQL development choices
We evaluated PostgreSQL vs MySQL against workload shape and operational constraints. For transactions, referential integrity, and JSON querying, PostgreSQL won. For append-only analytics and idempotent event sinks, a serverless MySQL with auto-scaling (PlanetScale) fit nicely. This dual approach kept minimal ops while playing to each engine's strengths.
- PostgreSQL: Orders, user profiles, permissions, and search indices (via trigram/GiST) lived here.
- MySQL: Lightweight event ingestion (clickstreams) with periodic export to the warehouse.
We standardized connection patterns: Prisma on the app side, pgBouncer for pooling on Postgres, and HTTP-based driverless connections for serverless MySQL to avoid connection storms from lambda cold starts.
Database tuning and query wins
- Created partial indexes on active products (WHERE archived = false) dropping median catalog query from 42ms to 8ms.
- Introduced materialized views for top categories, refreshed via ISR revalidate tags; reduced category page TTFB p95 from 620ms to 280ms.
- Enabled read replicas and routed read-heavy autocomplete to the replica using a request header toggle.
- Used JSONB for third-party attributes in PostgreSQL but enforced typed columns for hot filters to retain index use.
Caching strategy: cheap wins first
- ISR windows: 60 seconds for homepage, 5 minutes for category pages, 24 hours for evergreen posts. Revalidate on content webhooks to bypass waiting periods for critical updates.
- Stale-while-revalidate: Allowed serving slightly stale HTML while regenerating in the background, protecting cold paths during spikes.
- Fine-grained API caching: GET /catalog facets cached 120s at the edge; user-specific cart endpoints bypassed cache.
- Redis-based session/cache for authenticated users with a 1-hour TTL and key-scoped invalidation on cart mutations.
Minimal-ops delivery workflow
- CI/CD: Every PR deployed to preview with Lighthouse budgets; merges gated on p95 regressions.
- Observability: Edge logs, database slow query dashboards, and synthetic checks at 5 global locations; SLO error budgets surfaced in Slack.
- IaC: Terraform for DBs and secrets only; everything else lived in provider-managed consoles to reduce drift.
- Feature flags: Configurable at the edge; rollbacks in under 60 seconds without redeploy.
Results and unit economics
- Traffic: Sustained 12k-15k daily users, peak 120k on campaign day without manual scaling.
- Performance: Cached routes TTFB p95 220ms; dynamic p95 540ms; CLS < 0.02; LCP p75 1.8s on 4G.
- Cost: $1.12 per 1k requests average; storage + queries 18% under budget, primarily due to cache hit ratios > 90%.
- Reliability: 0 production incidents during launch week; blue/green deploys took 90 seconds end-to-end.
A fixed-scope playbook you can reuse
- Define SLOs and budget ceilings up front; make "fewer moving parts" a success criterion.
- Partition pages by rendering mode; default to ISR, escalate to SSR only for personalized moments.
- Design cache keys and invalidation pathways before you code queries.
- Choose the database by workload, not preference; measure each query's p95 and cardinality.
- Automate quality gates (Lighthouse, Web Vitals, query timing) in CI to prevent regressions.
When to pick PostgreSQL vs MySQL
- Pick PostgreSQL for complex joins, transactional integrity, full-text with ranking, and JSONB that still needs indexing.
- Pick MySQL for high-write, simple schemas, or when you need effortless horizontal scaling on serverless platforms.
- If you must run both, keep them bounded: events and analytics in MySQL, durable business data in PostgreSQL.
Lessons learned
- Edge first, not edge only: keep business logic in serverless functions to avoid cold-start costs in middleware.
- Beware N+1 with Server Components; batch via loaders and constrain select lists.
- Cache observability matters as much as cache size; add per-route hit/miss dashboards.
- Small schema changes beat big infra: a partial index saved more than a bigger instance would have.
The throughline: disciplined scope, data-informed rendering, and pragmatic PostgreSQL and MySQL development deliver scale without spinning up an ops team. If you need an experienced US and Europe software development partner to execute under constraints, or elite talent to accelerate delivery, slashdev.io and our fixed-scope web development projects model make that playbook repeatable.
