--- source_url: "https://kriedysystems.com/blog/saas-infrastructure-stack-2026?utm_source=openai" title: "The Modern SaaS Infrastructure Stack in 2026 | Kriedy Systems" mirrored_at: 2026-08-10T03:03:04.137Z host: kriedysystems.com cited_in_42a: true mirror_canonical: "https://index.42a.ai/kriedysystems.com/blog/saas-infrastructure-stack-2026__q__utm_source_openai" --- > **Original source:** https://kriedysystems.com/blog/saas-infrastructure-stack-2026?utm_source=openai The modern SaaS infrastructure stack has matured considerably. The days of provisioning bare EC2 instances and running your own Postgres on a single VM are largely behind us — the managed service ecosystem has reached a point where you can build a production-grade multi-tenant platform in weeks rather than months, if you make good decisions about which layer to own and which to delegate. This guide walks through each layer of the stack, the realistic tradeoffs between the major options in 2026, and the patterns we recommend for early-to-mid-stage SaaS companies (roughly $0 to $10M ARR). * * * ## Compute Layer: ECS vs EKS vs Lambda The compute decision is the one with the longest tail of consequences. Getting it wrong means a painful migration 12 months in. ### AWS ECS (Fargate) ECS on Fargate remains the lowest-operational-overhead option for teams that need container-based compute without wanting to manage Kubernetes. You define tasks, Fargate runs them, and you pay per vCPU-second and GB-second of memory. **When to choose ECS:** You're a team of fewer than 10 engineers. You need containers but have no Kubernetes expertise. You want predictable operational cost with minimal DevOps investment. **Realistic cost:** A typical SaaS running 5 services at moderate load spends $500–1,500/month on ECS Fargate compute. Simple to reason about, easy to autoscale. ### AWS EKS EKS gives you full Kubernetes. You get the entire ecosystem — Helm, ArgoCD, Karpenter, Istio, KEDA — but you pay for it in operational complexity. The cluster control plane costs $0.10/hour ($72/month) before a single workload runs. Node management (even with managed node groups) requires Kubernetes knowledge. **When to choose EKS:** You have more than 15 services. You need advanced scheduling (GPUs, spot instances, KEDA-based scaling). You have engineering capacity to own the platform. **The realistic path:** Many SaaS companies start on ECS and migrate to EKS when they hit the scaling and flexibility ceiling. The migration is painful but manageable. Plan for it when services exceed 20. ### AWS Lambda Lambda's position has shifted in 2026. The cold start problem is largely solved for common runtimes (Node.js, Python, Go), and the pricing model ($0.20 per million invocations + duration) is extremely compelling for async workloads and APIs with spiky traffic. **When to choose Lambda:** Event-driven processing, webhooks, background jobs, APIs with highly variable traffic. Lambda does not work well for latency-sensitive synchronous APIs that need sub-50ms P99 response times consistently. **The hybrid pattern:** Most mature SaaS platforms run core synchronous APIs on ECS/EKS and use Lambda for async processing — webhook delivery, file processing, report generation, email sending. This gives you the cost efficiency of Lambda for bursty workloads without fighting cold starts on your critical path. * * * ## Database Layer: RDS vs PlanetScale vs Neon Database choice is permanent in a way that compute choice isn't. Migrating a production database mid-growth is extremely expensive. ### AWS RDS (PostgreSQL) RDS PostgreSQL remains the default choice for good reason. Managed backups, Multi-AZ failover, read replicas, and a 20-year-old extension ecosystem. The operational overhead is low compared to self-managed Postgres, and the performance is predictable. **Cost at scale:** `db.r6g.xlarge` (4 vCPU, 32GB RAM, Multi-AZ) runs approximately $420/month. Read replicas add cost linearly. Storage is $0.115/GB/month for gp3. **When to use RDS:** Most SaaS companies. It's boring and reliable, which is what you want from your database. ### PlanetScale PlanetScale is a MySQL-compatible serverless database platform built on Vitess (the technology that scaled YouTube and GitHub). Its key differentiator is **non-blocking schema changes** — DDL migrations that don't lock tables, even at scale. For SaaS companies shipping fast, this is a genuine operational improvement over traditional Postgres ALTER TABLE locks. PlanetScale also supports **branching** — each developer gets a copy of the schema to experiment with, and schema changes are merged like pull requests. **The tradeoff:** No foreign key support (by design — Vitess shards across multiple MySQL instances). For teams that rely on referential integrity at the database level, this is a dealbreaker. For teams that enforce integrity at the application layer, it's fine. ### Neon (Serverless Postgres) Neon is serverless PostgreSQL with a genuinely innovative architecture that separates compute from storage. Databases auto-suspend when idle (billing stops), resume in ~500ms, and scale compute up automatically. For development environments and low-traffic applications, Neon's cost is effectively zero. In 2026, Neon has matured significantly. The branching feature (similar to PlanetScale) makes it excellent for staging environments and PR preview deployments. **Realistic recommendation:** Use RDS PostgreSQL as your primary production database. Use Neon for staging, PR previews, and development environments to eliminate the cost and operational overhead of running replica RDS instances for non-production workloads. * * * ## Messaging and Background Jobs Every SaaS needs a way to process work asynchronously. The options: **Amazon SQS + Lambda** — The simplest pattern. SQS queues are cheap ($0.40 per million messages), Lambda processes them. No servers to manage. Works well for most async patterns up to moderate throughput. **Amazon SQS + ECS worker** — Same queue, but a long-running ECS task polls and processes. Better for jobs that need persistent connections, local state, or consistent low-latency. **Redis + BullMQ / Sidekiq** — For teams already running Redis (common for caching), adding a job queue on the same Redis instance is low-overhead. BullMQ (Node.js) and Sidekiq (Ruby) are mature, feature-rich job frameworks with retries, concurrency controls, and dashboards. The tradeoff is Redis as a single point of failure for your job queue — use Redis Cluster or ElastiCache with Multi-AZ. **The recommendation:** SQS + Lambda for greenfield. Redis + BullMQ or Sidekiq if you're already in that ecosystem. Avoid overengineering with Kafka unless you have genuine event sourcing requirements. * * * ## CDN and Edge **CloudFront** is the default for AWS-native stacks. It integrates with S3, API Gateway, and ALB without additional configuration. For static assets and API caching, it's sufficient for most SaaS platforms at any scale. **Cloudflare** is worth considering for global performance and edge compute. Cloudflare Workers provide edge-side logic (A/B testing, auth edge cases, geo-routing) at sub-millisecond latency. Cloudflare's DDoS protection is also best-in-class. Many mid-stage SaaS companies run Cloudflare in front of their ALB/CloudFront for the security and performance benefits. * * * ## Auth Layer In 2026, the clear recommendation is **don't build auth yourself**. **Clerk** has become the leading choice for B2B SaaS. Pre-built UI components (sign-in, sign-up, organisation management, user profiles), SAML/SSO support, and enterprise features that would take months to build. Pricing is per monthly active user, which aligns with SaaS revenue growth. **Auth0 / Okta** remains the enterprise standard for companies with compliance requirements (SOC 2, HIPAA, FedRAMP). More complex to configure, but the compliance tooling and audit logging are worth it at enterprise scale. **AWS Cognito** is often chosen for AWS-native teams because of perceived cost savings. In practice, Cognito's API is notoriously complex, its UI components are dated, and the developer experience is painful. Use Clerk or Auth0 and pay the per-user cost — it's worth it. * * * ## Payments **Stripe** is the default for good reason: exceptional API design, comprehensive documentation, and a feature set that covers subscriptions, usage-based billing, metered billing, invoicing, and marketplace payments. The 2.9% + $0.30 per transaction cost is standard. As revenue scales, look at **Stripe's custom pricing** (available above ~$1M annual processing volume) and evaluate whether **Paddle** makes sense for international expansion — Paddle acts as a Merchant of Record, handling VAT, tax compliance, and local payment methods across 200+ countries, which is significant complexity to offload. * * * ## The Recommended Stack for $0–$10M ARR SaaS | Layer | Choice | Why | |---|---|---| | Compute | ECS Fargate | Low ops overhead, scales cleanly | | Database | RDS PostgreSQL | Reliable, mature, ecosystem | | Dev/staging DB | Neon | Zero cost when idle, branching | | Jobs | SQS + Lambda | Serverless, no ops, cost-efficient | | Cache | ElastiCache Redis | Standard, Multi-AZ available | | CDN | Cloudflare + CloudFront | Security + performance | | Auth | Clerk | Best DX, B2B features | | Payments | Stripe | Ecosystem standard | The SaaS infrastructure stack in 2026 is more capable and more complex than ever before. The winning pattern is to aggressively delegate commodity infrastructure — auth, payments, CDN, managed databases — and invest your engineering time in the application layer that actually differentiates your product.