The problem: 100 million engine downloads a month

Prisma’s ORM is built around two components that developers install from npm: Prisma Client and the Prisma CLI. Both rely on the Prisma Engines, Rust-based binaries that handle schema introspection, migrations, and query translation. The engines are distributed separately from the npm packages as platform-specific compiled binaries, downloaded on demand by the CLI based on the target environment.

That architecture worked well until mid-2023, when engine downloads reached 100 million per month, translating to 250 terabytes of monthly egress. Prisma needed a highly available, globally distributed storage solution with low latency — and the bill for their existing AWS setup was climbing accordingly.

The old setup: S3 and CloudFront

Prisma’s original distribution pipeline used AWS S3 for blob storage and CloudFront as the CDN. That combination scaled fine, and Prisma’s team was comfortable with AWS. The problem was cost. Data transfer at their scale was a growing line item, with no sign of leveling off.

The team’s first instinct was to look for free options before paying for anything else.

Free alternatives ruled out

Because Prisma ORM is open source, GitHub Releases and npm were natural candidates for hosting engine files. GitHub Releases was dismissed early because it couldn’t guarantee the quality of service Prisma needed for production downloads.

npm was technically viable — hosting the engines would comply with its terms — but adopting it meant reworking the upload and download logic and forcing updates across many older Prisma CLI versions. That broke a hard requirement: the migration couldn’t disrupt existing users.

Why Cloudflare R2 won

Prisma’s AWS cost breakdown showed that CloudFront alone accounted for 97% of distribution costs. Swapping CloudFront for an alternative CDN while keeping S3 as the origin would have cut costs by an estimated 70%. But Cloudflare R2, which replaces both S3 and CloudFront, was more attractive: it has no egress fees, and pricing is based on stored data volume and operations alone.

R2’s S3 compatibility meant Prisma wouldn’t need major software changes. The team also had existing trust in Cloudflare’s platform — Prisma Accelerate and Prisma Pulse already run on Cloudflare infrastructure.

To validate performance, Prisma deployed a test script across 50 global cities to measure download latencies for engine files (~15MB), comparing cache hit and miss scenarios against the AWS setup. The results showed R2 was at least on par with S3 and CloudFront.

The migration playbook

Prisma CLI uses a fixed domain for engine distribution, which meant the team could keep old CLI versions working by merely repointing the domain. The real work was orchestrating a safe switchover.

The release pipeline was modified to upload new engines to both S3 and R2. For historical engine versions, Prisma used R2 Super Slurper to copy existing assets into the new bucket. Grafana monitoring checks were set up to pull files from R2 over a test domain, using the same DNS and TLS configuration intended for production.

The switch itself used DNS load balancing. Two alias records were configured with weighted routing: one pointed to CloudFront (the control) and the other to R2 (the candidate). All traffic initially stayed on the control record. A health check monitored latencies and errors, and was configured to fail all traffic back to CloudFront if anything went wrong. TTL was set as low as possible so weight changes took effect quickly.

The rollout was deliberately gradual:

  • With just 5% of traffic routed to R2, cache hit ratios approached 100%.
  • Latency matched the control record, so the health check never fired.
  • Over the course of an hour, the R2 weight was increased to 25%, then 50%, then 100% — without issue.

After two additional days of monitoring, the DNS topology was simplified to route exclusively to R2. There was zero downtime and no user-reported issues.

Results

Moving to Cloudflare R2 cut Prisma’s engine distribution costs by 98%. The service has maintained the same level of uptime, performance, and latency as the previous AWS setup. Because R2’s pricing model doesn’t penalize egress, those savings scale with Prisma’s user base rather than eroding as traffic grows.

The project highlighted two practical takeaways for organizations considering similar migrations:

  • S3 compatibility is a real advantage. It kept the engineering effort to a minimum and let the team preserve existing workflows.

  • DNS-based weighted rollout, combined with monitoring and automated fallback, made a potentially risky infrastructure change boring — which is exactly what a good migration should be.