UploadThing vs Amazon S3 vs Cloudflare R2: File Uploads for a Next.js SaaS (2026)

Quick answer (2026)

For a Next.js SaaS in 2026, pick by two things, not by the storage price: how much of the upload pipeline you want to build, and whether your files get served a lot. UploadThing is the fastest way to add uploads (a drop-in React component plus a typed server route, $10/mo flat for a 100 GB app). Cloudflare R2 is the cheapest to serve, because its egress is free ($0.015/GB-month storage, no bandwidth charge). Amazon S3 is the most powerful and the most work, and its egress bill ($0.09/GB after the first 100 GB each month) is what makes a read-heavy app expensive. All three are S3-API compatible enough that switching later is a config change, not a rewrite.

The real axis is egress and plumbing, not the per-gigabyte storage price

Every "R2 vs S3" post leads with the storage rate. For a typical Next.js SaaS that is the wrong number to stare at. Storage is cheap everywhere: a hundred gigabytes of user avatars and PDFs costs a couple of dollars a month on any of the three. What actually moves your bill, and your shipping speed, is:

1. Egress, the price to send those files back out to users, and
2. Who writes the upload plumbing, the presigned URL, the client component, the progress bar, the access rules.

Order the three on those two axes and the decision gets simple.

The three, quickly

UploadThing: rent the whole pipeline

UploadThing (the pingdotgg/uploadthing repo, 5.2k GitHub stars, MIT, TypeScript, as of July 2026) is a managed uploader built for exactly this stack. You drop in a typed upload button, wire a FileRouter on the server, and uploads, storage, and a CDN are handled for you. It is the shortest path from "no uploads" to "uploads in production," and the reason it exists is that rolling your own S3 presigned-URL flow in Next.js is fiddlier than it looks.

Amazon S3: own the raw primitive

Amazon S3 is the object store the other two imitate. Nothing matches its durability story, lifecycle rules, event triggers, and the depth of the AWS ecosystem around it. The cost is that you build everything (the IAM policy, the presigned URLs, the client), and you pay to send bytes out: $0.09/GB after the first 100 GB each month, with GET requests at $0.0004 per 1,000 (S3 pricing, July 2026). For a public, image-heavy app, that egress line is the whole story.

Cloudflare R2: the S3 API without the egress tax

R2 speaks the S3 API, so the same AWS SDK code points at it with a different endpoint. The headline is egress: it is free. Storage is $0.015/GB-month, Class A (write) operations are $4.50 per million and Class B (read) operations $0.36 per million, with a free tier of 10 GB plus a million writes and ten million reads a month (R2 pricing, July 2026). You still write the upload plumbing yourself, but you stop paying every time a file is viewed.

What each actually costs in 2026

The gap only shows up when you plug in a real shape. Take a Next.js SaaS storing 100 GB of user files and serving 500 GB a month (images and documents loading in the browser):

• UploadThing: the 100 GB app plan, $10/mo flat. Storage, bandwidth, and the UI are one line item.
• Cloudflare R2: about $1.35 in storage (the first 10 GB are free) and $0 egress. Call it a dollar or two.
• Amazon S3: about $2.30 in storage plus 400 GB of billable egress at $0.09, which is $36. Roughly $38/mo, and it climbs with every viral post.

Same files, same traffic, and S3 costs more than twenty times what R2 does, entirely because of bandwidth. UploadThing sits in the middle on price but wins on time: you are not writing a presigned-URL handler at all. Ask in r/nextjs and the recurring answer is "R2 for cost, UploadThing for speed," which matches the math above.

Where each one loses (honestly)

• UploadThing is a managed dependency you do not control. The per-gigabyte tiers get pricier than raw R2 once you are storing terabytes, your ceiling is the plan, and you inherit its uptime and roadmap. Great for a feature, riskier as the foundation of a storage-heavy product.
• Amazon S3 punishes public, read-heavy workloads with egress, and "just use S3" hides a real amount of IAM and presigned-URL code. It is the right answer for data lakes, compliance, and event-driven pipelines, not for serving avatars cheaply.
• Cloudflare R2 still makes you build the upload flow (there is no Next-native component), the tooling and ecosystem are thinner than AWS, write-heavy apps pay Class A operations, and it lacks S3's deeper lifecycle and analytics features.

Which situation picks which

• You want uploads working this afternoon and they are a feature, not the product: UploadThing.
• Your files are public and served constantly (images, video, downloads) and you are cost-sensitive: Cloudflare R2, for the free egress.
• You are already deep in AWS, or need lifecycle rules, compliance, or event-driven processing: Amazon S3.
• You are on S3 today and the egress bill hurts: move to R2. Because it is S3-API compatible, it is an endpoint swap, not a rewrite.

For where file storage sits in the wider stack, this pairs with our open-source Next.js SaaS and AI starter scorecard and the data-layer call in Neon vs Supabase: your rows live in Postgres, your files live in object storage, and the two decisions rhyme, own the primitive or rent the managed wrapper.