S3-compatible storage APIs: why they became the default for backup tooling

Most backup tools already speak S3. Here's why that matters when you're choosing object storage.

How S3 became the lingua franca

When Amazon launched S3 in 2006, it solved a concrete problem for developers: provisioning storage hardware meant estimating future needs accurately, and getting it wrong was expensive—too little caused crashes, too much wasted money. S3 offered scalable, on-demand storage without the hardware ops burden.

The API it came with spread everywhere. Tools like rclone, Restic, Arq, Veeam, and Synology were built to speak S3 syntax. Backup libraries in Go, Python, and Ruby assumed it. When competing storage providers entered the market—Backblaze B2, Wasabi, Cloudflare R2, MinIO—most of them added S3-compatible APIs specifically because their customers didn't want to rewrite code that already worked.

The S3 API became the industry standard for object storage, not just Amazon's implementation of it.

What a native API adds

Storage providers often build their own native API first, before layering on S3 compatibility. Backblaze's B2 Native API, for example, includes a few things the S3 Compatible API doesn't:

Programmatic key management: create, list, and delete API keys with dedicated calls (b2_create_key, b2_delete_key, b2_list_keys)

Official SDKs: Java and Python SDKs for managing and configuring storage resources

Token-based auth: the server calculates signatures for you, rather than requiring the client to pre-sign URLs

The tradeoff is upload complexity. The B2 Native API requires a separate call to get an upload URL, which can go stale and needs to be retried on a 50x error. The S3 Compatible API handles that routing on Backblaze's backend automatically.

That extra complexity in the B2 Native API is what historically allowed Backblaze to offer storage at a lower price point than AWS—but the S3 Compatible API closed most of that gap in developer ergonomics.

What this means for a backup pipeline

If you're setting up scheduled backups—Postgres dumps to object storage, encrypted file archives, server snapshots—the S3-compatible path is almost always the right call:

Your existing tools work without modification. rclone, Restic, Duplicati, and most backup scripts already speak S3 syntax. You configure an endpoint URL and credentials; they handle the rest.

Provider portability is real. Moving from AWS S3 to Backblaze B2, Cloudflare R2, or a self-hosted MinIO instance is a config change. Your backup code doesn't change. Your restore procedure doesn't change.

The ecosystem is mature. S3-compatible SDKs exist in every language—Go, Python, Ruby, JavaScript, PHP, and more—with years of production use behind them.

The native API earns its complexity in specific scenarios: fine-grained programmatic key provisioning, custom auth flows, or deep integrations where you're managing the storage layer itself. For a backup pipeline that runs on a cron job and needs to reliably store and restore snapshots, native APIs are more complexity than the job requires.

Storage portability and backup recovery

One thing that gets underweighted when picking backup storage: vendor risk matters more for backups than for most other data. If your primary cloud provider has an outage or an unexpected price change, you need to restore from a backup—potentially to a different provider. S3-compatible storage means your restore procedure works regardless of where the files live.

Small SaaS teams and agencies managing client infrastructure often end up with backups spread across several providers anyway: one client is on AWS, another is on DigitalOcean, a self-hosted project uses Hetzner object storage. S3 compatibility is what makes a single backup approach work across all of them without maintaining separate tooling per environment.

Calm Backup's point-in-time restore connects to any S3-compatible backend—B2, R2, Wasabi, your own MinIO—and keeps restore working consistently regardless of which one you're using. When you're under pressure to recover a database, you don't want to be debugging API authentication.

The short version

Use S3-compatible storage for backups. Your tools already speak it. Switching providers stays cheap. And when you need to restore at an inconvenient hour, you want the storage layer to be the least interesting part of the problem.

If you need programmatic key management or are building a custom storage integration from scratch, the native API is worth evaluating. But for the backup case—set it up, let it run, restore when needed—S3 compatibility is the right default.