Scaling Your SaaS Stack with Convex and Clerk

I was asked whether Convex and Clerk can support serious scale. They can.

The more useful question is when a migration is technically justified, and how much your stack choice really affects cost at high user counts.

Can Convex and Clerk Actually Scale?

100k users: comfortably.

1M users: still within design assumptions.

Convex runs large-scale, low-latency, real-time backends in production. Clerk processes authentication for tens of thousands to millions of monthly active users (MAUs). The real constraint at scale is not raw capability, but the tradeoff between cost, developer velocity, and operational complexity.

The Pricing Reality

Convex at Scale

Convex Professional tier is 25 USD per developer per month, plus usage-based fees.

Function calls: 2 USD per million (25 million included).

Database storage: 0.20 USD per GB (after 50 GB included).

Database bandwidth: 0.20 USD per GB (after 50 GB included).

File storage: 0.03 USD per GB (after 100 GB included).

A moderately active application with around 100k users typically lands around 200–800 USD per month in Convex usage, dominated by reads, writes, and bandwidth.

Clerk at Scale

Clerk Production tier has a 25 USD per month base, plus 0.02 USD per MAU after the first 10,000 free.

At 100k MAUs: 1,825 USD per month.

At 1M MAUs: 19,825 USD per month.

Billing applies only to active users, meaning users who actually authenticate within the month, which differs from many providers that meter on total stored accounts.

When Should You Care About Costs?

For applications in the 100k–1M MAU range that are profitable or funded, infrastructure rarely dominates the cost structure.

At 100k users and 10 USD per month ARPU, the monthly recurring revenue is 1M USD. In that scenario, 1,825 USD per month for authentication represents about 0.18% of revenue.

A migration is more defensible when:

Infrastructure cost reaches roughly 5–10% of revenue.

You need specific compliance regimes, nontrivial custom auth flows, multi-region deployment, or strict data residency.

You require granular cost control or have highly predictable traffic patterns.

You have dedicated DevOps or platform engineering bandwidth.

Migrating purely because of user count is usually premature. The trigger should be cost ratios and product or compliance requirements.

Architectural Variations and Patterns

Convex Deployment Options

Standard hosted setup: managed, auto-scaling backend well-suited to most SaaS workloads and real-time experiences.

Hybrid architecture: Convex for real-time state and live queries, plus traditional REST or RPC for heavy or batch workloads, with a CDN in front of static or public content.

Caching strategies: built-in client-side caching from Convex, plus optional Redis or Vercel KV for expensive aggregations or high-fan-out reads.

Clerk Integration Variations

B2C setups: classic email and password, social sign-in, magic links, user profiles, and session management.

B2B and enterprise: SAML SSO, organization and role management, custom JWT claims, and integration with identity providers.

Headless mode: use Clerk’s APIs and webhooks to implement completely custom UIs and atypical authentication UX while preserving the underlying security model.

The AWS Migration Path

At a larger scale or with significant funding, many teams move to a stack centered on AWS Cognito, DynamoDB, and AppSync for tighter cost and control.

Cognito Pricing

First 10k MAUs are free on the Lite tier.

Next 90k MAUs, up to 100k, cost 0.0055 USD per MAU, or 495 USD.

Beyond 100k MAUs, the rate is 0.0046 USD per MAU.

At 1M MAUs, the bill is 495 USD plus 900,000 multiplied by 0.0046, which equals 4,635 USD per month, not 4,415 USD .

Additional advanced security features and SAML federation incur extra cost.

DynamoDB

Write requests: about 1.25 USD per million writes.

Read requests: about 0.25 USD per million reads.

Storage: about 0.25 USD per GB, with the first 25 GB free.

A well-modeled application at 1M users often ends in the 270–400 USD per month range for DynamoDB, though data access patterns drive large variance.

AppSync

GraphQL queries and mutations: 4 USD per million operations.

Realtime messages: 2 USD per million.

Connection minutes: 0.08 USD per million connection minutes.

A user that remains connected continuously for a month costs about 0.003456 USD in connection minutes, not 3.45 USD per month.

For 1M users issuing around 10 API calls per month, AppSync typically lands around 140–600 USD per month, again strongly dependent on exact real-time and query patterns.

Total AWS Stack Cost at 1M Users

Putting these components together at 1M MAUs:

Conservative estimate with relatively modest real-time usage: about 5,000 USD per month.

With heavy real-time features and higher traffic: about 7,000–10,000 USD per month.

A roughly equivalent Convex plus Clerk setup can reach 20,000–25,000 USD per month.

The difference is not free.

Achieving those AWS numbers assumes substantial investment in DevOps, schema and partition design, observability, incident management, and ongoing performance tuning.

Technical Deep Dive: Operational Characteristics

Connection management: Convex manages connection pooling, reconnection, and live query invalidation automatically. With AppSync, you are responsible for connection lifecycle, reconnection strategies, and client behavior around network instability.

Data sharding and modeling: Convex manages storage distribution behind the scenes. DynamoDB requires explicit partition key design, careful handling of hot partitions, and sometimes auxiliary tables to model access patterns efficiently.

Query optimization: Convex automatically optimizes indexes and live query fan-out for typical patterns. DynamoDB pushes you to design for specific query shapes using global and local secondary indexes, single-table designs, and precomputed views.

Caching layers: both stacks benefit from CDNs, in-memory caches like Redis or ElastiCache, and client-side caching. The difference lies in how much you must handcraft these layers versus relying on default behavior.

Viable Database and Platform Alternatives

Supabase (Postgres): offers up to about 50,000 MAU on the free tier and around 100,000 MAU on the Pro tier, with approximately 0.00325 USD per MAU beyond that. Typical cost at 100k users is roughly 500–1,500 USD per month, depending on workload.

PlanetScale (MySQL): Pro starts around 39 USD per month plus usage. Many workloads at 100k users fall in the 500–2,000 USD per month range.

Neon (Postgres): branching-friendly Postgres with free and paid plans. At 100k users, many SaaS workloads land between 300–1,000 USD per month.

Firebase: around 50k MAU of auth on the free tier, then usage-based pricing for authentication, Firestore, storage, and functions. A full Firebase-based stack at 100k users often sits in the 2,000–4,000 USD per month band.

Comparison at a Glance

These numbers are indicative, not exact quotes, please don't take them to heart

Migration: Time and Real Cost

A minimal but functional migration from Convex plus Clerk to an AWS-style stack usually consumes three to four months of focused engineering work. If we're being real.

Reaching a robust, production-ready state with observability, incident playbooks, security hardening, infrastructure as code, and full regression coverage frequently takes six to twelve months and translates to roughly 200k–300k USD of engineering time.

The less obvious cost is reduced feature velocity, context switching, and the opportunity cost of not shipping product improvements during the migration window.

When to Migrate

Migration tends to make technical and economic sense when:

Product-market fit is clearly established, and unit economics are validated.

You have specific compliance, data residency, latency, or performance constraints that managed platforms cannot satisfy.

You have or can hire DevOps and platform engineers to own the stack.

In contrast, migration usually does not make sense when:

You are pre-product-market fit.

Infrastructure represents less than roughly 5% of revenue.

You lack dedicated operational expertise.

The primary motivation is fear of future scale rather than actual current constraints.

Key Points

Convex and Clerk can support applications with hundreds of thousands to millions of users.

Infrastructure cost becomes a serious optimisation target when it makes more sense, not when the first scaling pains appear.

An AWS-centric stack can be materially cheaper at very high scale, but that advantage is paid for with DevOps headcount, higher complexity, and ongoing maintenance.

Developer velocity and iteration speed matter far more in the early and mid stages of a SaaS product than perfect cost efficiency.

Intermediate options such as Supabase, PlanetScale, Neon, and Firebase provide a middle ground between fully managed platforms and deeply custom AWS architectures.

The hardest scaling problem for most SaaS products is not infrastructure. It is reaching product-market fit before infrastructure optimisation becomes necessary.