Cost & scaling on AWS

Leaving Supabase + Vercel to self-host on AWS at SaaS scale: a service-by-service migration map, a cost model at 1k / 10k / 100k users, and the scaling architecture — built around the one number that actually moves: model inference.

AWS-preferred · Postgres + pgvector · Claude Haiku + Sonnet · figures as of 2026-07-20.

1. Service map — what replaces what

Two escape routes per layer: the AWS-native managed service (less ops, AWS-preferred), and a fully-portable open-source equivalent (zero lock-in, cheapest on bare metal). Your app is already built to move — better-auth is self-hosted, the DB is boring relational Postgres, and the LLM/search gateways make providers swappable.

2. Cost at three scales

Monthly, order-of-magnitude. MAU = monthly active users; assume ~40% of them trigger AI in a given month. AWS figures assume on-demand + modest reserved coverage; the Claude figures assume metering is on (see §3). Treat as planning brackets — model your real numbers in the AWS Pricing Calculator.

AWS infra line items

3. The cost center: Claude inference

Your architecture already picks the right model per job — Haiku for extraction, Sonnet for search/drafts, Batch for nightly. Here's what that costs, and where it explodes.

* Sonnet 5 introductory pricing $2/$10 per MTok runs through 2026-08-31; model durable planning at $3/$15. Prompt-cache reads bill at ~0.1× input; cache writes 1.25× (5-min) / 2× (1-hour).

Two spend regimes

Cheapest paths to the same quality

• Prompt caching is free money. The stable system prefix + the user's graph context are the same across calls — cache them and input drops to ~0.1×. Keep volatile content (today's date, the query) last so the prefix stays byte-stable.
• Batch everything that can wait. Enrichment, change-detection, digests → Message Batches at −50%. (Keep this on the Anthropic API or Claude Platform on AWS — not Bedrock.)
• Right-size the model per task, then cap effort. Haiku already handles extraction; don't let a Sonnet call do a Haiku job.
• Meter from day one (you already do) so a runaway tenant is a throttled tenant, not a surprise.

4. Scaling architecture

The compute layer auto-scales trivially; the database is the ceiling. The move that unlocks real concurrency is the same one your docs already track — transaction-mode pooling with per-transaction RLS — plus caching the hot reads so most requests never touch Postgres.

The request path:

Users · mobile · extension
        ↓
CloudFront + WAF
        ↓
Application Load Balancer
        ↓
App tier — ECS Fargate / EKS   (Next.js + API, autoscaled)
        ↓   fans out to
  ├─ ElastiCache Redis          hot reads · rate limits
  ├─ RDS Proxy (txn pooling)    → Aurora writer, read replicas
  ├─ S3                         photos · exports → CDN
  └─ SQS + EventBridge          → Fargate workers (extraction · enrichment · digests)
        ↓   Haiku / Sonnet · nightly Batch
Claude — API · Platform on AWS · Bedrock

The five levers, in priority order

1. Transaction pooling + per-transaction RLS. Session-pinned pooling caps you at ~pool_size concurrent DB requests. Transaction mode (RDS Proxy / PgBouncer) multiplexes thousands of clients onto a few backends — but requires moving RLS scoping to SET LOCAL inside each transaction. This is the prerequisite for real scale.
2. Cache the hot reads. Graph payload, home dashboard, contact lists → ElastiCache, keyed per user (already RLS-scoped), invalidated on write. At 10k+ MAU this is the biggest lever for keeping DB load flat.
3. Read replicas. Route graph/search reads to Aurora replicas; writes to the primary.
4. Short transactions. Never hold a connection across an LLM or network call — the principle already applied to the extraction worker generalizes everywhere.
5. Queue the heavy work. Extraction, enrichment, embeddings → SQS + Fargate workers, off the request path.

5. When to self-host the model

The LLM gateway makes Claude ↔ Ollama/vLLM a drop-in — so this is a pure cost/quality/ops trade you can defer until the numbers demand it.

6. Migration order

• Prove portability first — you can already run the whole stack via docker compose; that's your escape hatch and your staging target.
• Move the database to Aurora Postgres (pgvector), fronted by RDS Proxy, and land the transaction-pooler + per-transaction-RLS rework here — it's the load-bearing change for scale.
• Containerize the app + workers onto ECS Fargate behind ALB + CloudFront; wire SQS for nightly jobs.
• Add ElastiCache and cache the hot reads before you need to.
• Point the LLM gateway at Claude Platform on AWS (keeps Batch + web search) or the first-party API — not Bedrock, unless you drop those features.
• Flip search to OpenSearch through the SearchIndex gateway only if PG FTS stops keeping up — the seam is already there.