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. 100k users: 1M users: still within design assumptions. 1M users: 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). Function calls: Database storage: 0.20 USD per GB (after 50 GB included). Database storage: Database bandwidth: 0.20 USD per GB (after 50 GB included). Database bandwidth: File storage: 0.03 USD per GB (after 100 GB included). File storage: 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: 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. compliance regimes custom auth flows multi-region deployment 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. Standard hosted setup: 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. Hybrid architecture: Caching strategies: built-in client-side caching from Convex, plus optional Redis or Vercel KV for expensive aggregations or high-fan-out reads. Caching strategies: Clerk Integration Variations B2C setups: classic email and password, social sign-in, magic links, user profiles, and session management. B2C setups: B2B and enterprise: SAML SSO, organization and role management, custom JWT claims, and integration with identity providers. B2B and enterprise: Headless mode: use Clerk’s APIs and webhooks to implement completely custom UIs and atypical authentication UX while preserving the underlying security model. Headless mode: 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. Write requests: Read requests: about 0.25 USD per million reads. Read requests: Storage: about 0.25 USD per GB, with the first 25 GB free. Storage: 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. GraphQL queries and mutations: Realtime messages: 2 USD per million. Realtime messages: Connection minutes: 0.08 USD per million connection minutes. 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: Putting these components together at 1M MAUs: Conservative estimate with relatively modest real-time usage: about 5,000 USD per month. Conservative estimate with relatively modest real-time usage: With heavy real-time features and higher traffic: about 7,000–10,000 USD per month. With heavy real-time features and higher traffic: 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. Connection management: 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. Data sharding and modeling: 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. Query optimization: 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. Caching layers: 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. Supabase (Postgres): 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. PlanetScale (MySQL): Neon (Postgres): branching-friendly Postgres with free and paid plans. At 100k users, many SaaS workloads land between 300–1,000 USD per month. Neon (Postgres): 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. Firebase: Comparison at a Glance FeatureConvex + ClerkAWS stackSupabaseFirebaseDev velocityExcellentPoor Good Good Real-timeNativeComplexGood Excellent Cost at 1M users20k-50k USD5k-10k USD8k-15k USD10k-20k USDLearning curveLow High MediumLow ControlLimitedCompleteGood LimitedMigration ComplexityHighNot applicableMediumHigh FeatureConvex + ClerkAWS stackSupabaseFirebaseDev velocityExcellentPoor Good Good Real-timeNativeComplexGood Excellent Cost at 1M users20k-50k USD5k-10k USD8k-15k USD10k-20k USDLearning curveLow High MediumLow ControlLimitedCompleteGood LimitedMigration ComplexityHighNot applicableMediumHigh FeatureConvex + ClerkAWS stackSupabaseFirebaseDev velocityExcellentPoor Good Good Real-timeNativeComplexGood Excellent Cost at 1M users20k-50k USD5k-10k USD8k-15k USD10k-20k USDLearning curveLow High MediumLow ControlLimitedCompleteGood LimitedMigration ComplexityHighNot applicableMediumHigh FeatureConvex + ClerkAWS stackSupabaseFirebase Feature Convex + Clerk AWS stack Supabase Firebase Dev velocityExcellentPoor Good Good Dev velocity Excellent Poor Good Good Real-timeNativeComplexGood Excellent Real-time Native Complex Good Excellent Cost at 1M users20k-50k USD5k-10k USD8k-15k USD10k-20k USD Cost at 1M users 20k-50k USD 5k-10k USD 8k-15k USD 10k-20k USD Learning curveLow High MediumLow Learning curve Low High Medium Low ControlLimitedCompleteGood Limited Control Limited Complete Good Limited Migration ComplexityHighNot applicableMediumHigh Migration Complexity High Not applicable Medium High 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: 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: 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.
