Introducing Multi-Region and Dual-Region Buckets | Tigris Object Storage

Quick Summary 6 min read

Four location types. Global, multi-region, dual-region, and single-region buckets cover the main combinations of data residency and availability.

Simple pricing. Multi-region is $0.025/GB/month with zero egress fees and no per-geo premiums, so your bill stays predictable even as you add regions.

Clear consistency model. Consistency is tied directly to bucket location type, so you always know how reads behave in and across regions.

CLI and dashboard updates. Use the new tigris mk commands and updated dashboard flows to create and manage location-aware buckets.

Today, we're introducing bucket location types in Tigris. Going forward, there will be four ways to control exactly where your data lives and how resilient it is.

Tigris has always distributed data globally. You write once, then read fast from anywhere. That model works well for most workloads, but it left no room for teams with constraints the automatic model could not accommodate.

• The first constraint is compliance. GDPR, data sovereignty laws, and enterprise contracts can require that data never leaves a specific country or region. "Close to your users" doesn't satisfy a regulation that says Frankfurt or nothing.

• The second is architecture. Multi-tenant platforms, active/active deployments, and compute-co-located pipelines all need storage in a known location. When your system depends on a topology guarantee, automatic distribution works against you.

Multi-region and dual-region buckets are our answer to that gap. Multi-region is the recommended default for most production workloads; dual-region lets you name two specific regions when regulations or architecture call for it. You can choose exactly where your data lives and how resilient it needs to be across four location types:

Bucket locations

Four ways to control where your data lives.

Global

Global buckets distribute data worldwide.

Objects move to the regions where they are accessed most.

Multi‑region

Multi-region buckets provide the highest availability in one geography.

Data is copied across regions in a group like us or europe.

Dual‑region

Dual-region buckets keep data in specific regions you choose.

They are a good fit for compliance and active/active topologies.

Single‑region

Single-region buckets keep data in one region co-located with compute.

Data is stored redundantly within that region’s availability zones.

Global buckets

Global buckets are what Tigris has always done: data distributed worldwide, reads served from the region closest to the request. They're now a first-class location type you can select intentionally.

They're the right choice for read-heavy workloads with users spread across the world: model weights, media libraries, static assets, documentation. You write infrequently, you read everywhere, and Tigris handles the rest.

Global endpoints

Tigris is deployed globally across multiple regions. All regions are accessible via https://t3.storage.dev and https://fly.storage.tigris.dev, which handle routing automatically. In your SDKs or the AWS CLI, set the region to auto and Tigris takes care of the rest.

Multi-region buckets (recommended default)

This is the place to start for most new production workloads. Multi-region buckets keep copies of your data across a group of regions within a chosen geography (for example usa or eur). You select the geography (USA or EUR), Tigris automatically selects the regions inside that geography, and maintains two or more copies. Every read and write inside that geography behaves consistently. If one region has a bad day, the others keep serving traffic.

Front-end assets, feature flags, and user data that needs both low latency and resilience to regional failures all fit this model. You get strong, predictable behavior without hand-wiring replication between single-region buckets.

Pricing

Multi-region buckets are priced at $0.025/GB/month, regardless of how many regions Tigris uses inside the geography, and egress is still free. That's often less than dual-region, where storage scales with each region you add. See the pricing page for details.

A multi-region bucket in the EUR geography might look like this:

Multi-region bucket (EUR)

Multi-region bucket (EUR)

EUR geography

Tigris-selected regions within EUR

ams

fra

Here is how to create multi-region buckets with the CLI:

# Create a multi-region bucket scoped to the EUR geography

tigris mk my-eu-bucket --locations eur

# Create a multi-region bucket scoped to the USA geography

tigris mk my-us-bucket --locations usa

Tigris CLI shortcut

tigris mk is an alias for tigris create, so any existing commands that use create will keep working.

Dual-region buckets

Dual-region stores copies in two or more regions you name. The “dual” label matches GCS terminology, but the feature itself does not limit you to exactly two regions—we simply recommend choosing two for most workloads. Reads route to whichever copy is closest. Writes go to all selected regions.

Most teams should start with multi-region buckets; dual-region is for the cases where you must pin data to specific regions instead of a geography like eur or usa. This fits when your compute layer is split across two named regions and storage needs to match, or when you want a small, explicitly pinned set of regions. It also works as a warm DR setup: a second copy in a known location without running your own replication service. Pricing stays simple here too: storage and Class A operations are billed per underlying region at the standard single-region rate, so if you pick three regions you pay 3 × $0.02 = $0.06/GB/month in total, with zero egress fees.

For example, a dual-region bucket might be:

Dual-region bucket (iad,sjc)

Dual-region bucket (iad,sjc)

iad (Ashburn)

sjc (San Jose)

Example CLI commands for common dual-region setups:

# US dual-region: East + West

tigris mk my-bucket --locations iad,sjc

Single-region buckets

Single-region buckets keep data in one region. They're the most cost-effective option and the right fit for staging environments, regional internal tools, and batch pipelines that live alongside a single compute region. You still get strong consistency within that region. You just don't pay for replication you don't need.

In the simplest case, everything lives in one place:

Single-region bucket (sin)

Single-region bucket (sin)

sin (Singapore)

You can create single-region buckets with a simple CLI flag:

# Create a single-region bucket in Singapore

tigris mk my-bucket --locations sin

# Create a single-region bucket in Ashburn, Virginia

tigris mk my-bucket --locations iad

Configuring bucket locations

You can configure bucket location in the Tigris Dashboard, under Advanced Settings. When creating a bucket, the Location field lets you choose between Global, Multi-region, Dual-region, and Single-region.

• For Multi-region, pick a geo group like USA or EUR from the dropdown.
• For Dual-region, select two specific region IDs.

Updating existing buckets

For existing buckets, go to the Tigris Dashboard, open the bucket, click Settings, and update the bucket location from there.

Pricing

Tigris keeps pricing intentionally simple: one storage line item per bucket, the same rates across geographies, and zero egress fees.

For dual-region buckets, total storage and Class A costs scale linearly with the number of regions you select. That’s why we recommend multi-region as the default: at $0.025/GB/month flat, it becomes cheaper than dual-region once you need two or more regions in a geography.

Pricing at a glance

Don't forget, your first 5GB are free! For the full breakdown, including storage tiers and request pricing, see the Tigris pricing page.

Compliance and data residency

Many teams pick bucket locations to satisfy legal or policy requirements, not just latency.

When you need to go beyond geography-level controls like eur and pin data to specific regions, Dual-region lets you say “only these regions” at the storage layer without building your own replication logic.

Consistency options

Consistency in Tigris is about how quickly every reader sees the latest write, and your bucket’s location type decides that behavior.

• Same‑region reads are always strongly consistent: as soon as you write, overwrite, delete, or list an object in that region, you see the latest state.
• Cross‑region reads either stay strongly consistent (Multi‑region and Single‑region) or may briefly return an older copy while replicas catch up (Global and Dual‑region).

If you want every read, from anywhere, to see the latest data, pick Multi‑region or Single‑region; if you can tolerate occasional sub‑second staleness in exchange for lower latency or automatic global placement, Global is often a better fit, and Dual‑region makes sense when you also need reads pinned to specific regions.

Consistency guarantees

For the exact guarantees for each location type, see the consistency docs.

Choosing a location type

Use this table as a quick decision guide:

If you're unsure, multi-region in your primary geography is the safe default for production. You get resilience inside that geography without touching your application code.

What about existing buckets?

Your existing buckets keep working exactly as before. For new workloads, read the bucket locations guide and the regions docs and pick the type that matches your geography, latency, and resilience requirements.

Create your first multi-region bucket today!

Sign in to the Tigris console, pick your geography, and let Tigris handle replication and failover—your first 5 GB are free.