TigerData: how do I create a zero-copy fork for debugging an incident or testing a migration?

When you’re debugging an incident or rehearsing a risky migration, you want the full production dataset without the blast radius. That’s exactly what a zero-copy fork in Tiger Cloud gives you: a fast, space-efficient clone of a TigerData service that you can break, test, and iterate on—without touching the original.

Quick Answer: In Tiger Cloud, you create a zero-copy fork by spinning up a new service from an existing one using a fork strategy (NOW, LAST_SNAPSHOT, or PITR) instead of doing a physical dump/restore. Storage is shared at the block level, so it’s fast to create and cheap to keep around, while still behaving like an independent Postgres+TimescaleDB instance.

The Quick Overview

• What It Is: A zero-copy fork is a new Tiger Cloud database service created from an existing service’s data blocks, without copying the full dataset. It’s a logical clone backed by shared storage and copy‑on‑write.
• Who It Is For: Postgres/TigerData operators, SREs, and application teams who need realistic environments for incident debugging, schema changes, or migration testing.
• Core Problem Solved: It eliminates fragile, slow, and expensive dump/restore workflows for large telemetry datasets, letting you test against production‑sized data safely and quickly.

How It Works

Conceptually, a zero‑copy fork works like a snapshot clone in a modern storage system. When you fork a Tiger Cloud service:

1. Tiger Cloud records a consistent point in the source service’s timeline (based on your fork strategy).
2. A new service is created that logically starts from that snapshot.
3. Both services share the same underlying data blocks until changes are made; writes to either service use copy‑on‑write so they diverge safely.

From your perspective, the forked service is just another Tiger Cloud service: Postgres-native, with TimescaleDB and TigerData extensions enabled, own connection endpoints, and independent compute/HA settings.

Fork Strategies

When you create the zero‑copy fork, you choose a fork_strategy:

1. NOW – Fork at the current database state

   • Use this when you want to debug an active incident with the very latest state (or as close as possible).
   • The snapshot is taken from the current instance state; any writes after that point remain only in the source.

2. LAST_SNAPSHOT – Fork at the last existing snapshot (faster)

   • Uses the most recent internal snapshot/checkpoint of the service.
   • This is typically faster to provision because Tiger Cloud doesn’t have to generate a new snapshot first.
   • Ideal when you don’t need “last 30 seconds” of data, but do need a recent, consistent view.

3. PITR – Point-in-time recovery fork

   • Creates a service from a specified time on the WAL (write‑ahead log) timeline.
   • Important: You must also set a target_time for PITR forks.
   • This is the right choice when you want to see “state just before it broke” or reproduce a specific historical incident.

Typical Fork Workflow

In practice, you’ll go through three phases:

1. Plan the fork
2. Create the forked service
3. Use and eventually clean up the fork

1. Plan the Fork

Before you create the fork, decide:

• Purpose:

  • Debugging a live incident? Use NOW or PITR (with a target_time just before impact).
  • Regression tests / migration rehearsal? LAST_SNAPSHOT is often sufficient and faster.

• Access and safety:

  • Ensure application credentials, secrets, and environment variables for the fork are not pointed to production endpoints.
  • Decide who can connect to the fork (IP allow lists, VPC peering, etc.).

• Size and lifespan:

  • Remember: storage is shared, but compute and any diverged data blocks still cost money.
  • Plan a clear TTL (time-to-live) for the fork and document when it should be deleted.

2. Create the Zero-Copy Fork

You can create a fork through:

• Tiger Console (UI)
• Tiger CLI / API (where you’ll explicitly see the fork_strategy and target_time knobs)

Conceptually, the CLI command looks like:

tiger services create \
  --name incident-debug-2024-04-12 \
  --from-service prod-telemetry \
  --fork-strategy NOW \
  --plan performance \
  --region us-east-1 \
  --wait

For a point‑in‑time replay:

tiger services create \
  --name migration-test-2024-04-12 \
  --from-service prod-telemetry \
  --fork-strategy PITR \
  --target-time "2024-04-12T17:25:00Z" \
  --plan performance \
  --region us-east-1 \
  --wait

For a fast clone from last snapshot:

tiger services create \
  --name nightly-migration-sandbox \
  --from-service prod-telemetry \
  --fork-strategy LAST_SNAPSHOT \
  --plan performance \
  --region us-east-1 \
  --wait

Note: Exact CLI flags may vary; always check the latest Tiger Cloud CLI docs or use tiger services create --help for the current interface. The important primitives are from-service, fork-strategy, and (for PITR) target-time.

Once created, you’ll see a new service with:

• Its own endpoints (pooled and direct)
• Its own compute/replica configuration
• Its own HA, backup, and PITR settings

3. Use and Clean Up the Fork

After the fork is ready:

• Connect using standard Postgres tools:
  psql, applications, migration tools, or BI tools all see it as a regular Postgres+TimescaleDB instance.

• Run your tests or debugging steps:

  • Reproduce the failing query patterns.
  • Apply schema changes or index experiments using CREATE INDEX CONCURRENTLY, ALTER TABLE, etc.
  • Test TimescaleDB features such as:

    SELECT create_hypertable('metrics', 'time', chunk_time_interval => '1 day');
    
    SELECT add_continuous_aggregate_policy(
      'metrics_hourly',
      start_offset => INTERVAL '7 days',
      end_offset => INTERVAL '1 hour',
      schedule_interval => INTERVAL '15 minutes'
    );
    

• Important: The fork is isolated. Writes to the fork do not affect the source, and vice versa.

When you’re done:

• Export any DDL you want to apply to production.
• Delete the forked service to stop incurring compute and incremental storage costs.

tiger services delete --name incident-debug-2024-04-12 --wait

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Zero-copy storage	Shares underlying data blocks between source and fork; uses copy‑on‑write	Fast creation and low storage overhead, even at multi‑TB scale
Fork strategies	Lets you choose NOW, LAST_SNAPSHOT, or PITR with target_time	Precisely control the point in time you want to debug or test
Independent service	Creates a full Tiger Cloud service (endpoints, HA, policies) from the fork	Safe experimentation with no risk to the production service

Ideal Use Cases

• Best for incident debugging: Because you can create a NOW or PITR fork that mirrors the production workload and data distribution, then replay problem queries, add logging, or change indexes without touching the live service.
• Best for migration and upgrade testing: Because LAST_SNAPSHOT or PITR forks let you run schema migrations, application upgrades, or new index strategies against realistic production‑sized data before you commit to the real cutover.

Limitations & Considerations

• Forks are not free:
  While the base dataset is shared, each fork has its own compute and additional storage for changed blocks. Keep forks short‑lived for incident or migration use, and clean them up once you’re done.

• PITR requires WAL coverage and target_time:

  • You can only create a PITR fork for times covered by the source service’s WAL retention.
  • You must set target_time; if it’s outside the WAL retention window, the fork will fail or roll back to the closest valid time.

• Region and plan constraints:
  Forks generally live in the same region/cluster as the source. Cross‑region cloning may require an additional mechanism (for example, logical replication or export/import).

Pricing & Plans

Zero‑copy forks are implemented at the service level, so they follow Tiger Cloud’s transparent resource-based billing:

• You pay for:
  • The fork’s compute (vCPU/RAM, replicas, HA)
  • Any incremental storage created by writes in the fork
• You don’t pay per query, for backups, or for networking egress within the platform.

A few common ways teams align forks with plans:

• Performance plan: Best for SREs and application teams needing to debug incidents or run realistic benchmarks on production‑like data without impacting production.
• Scale or Enterprise plans: Best for teams rehearsing complex migrations (multi‑TB telemetry services, schema restructuring, or data model overhauls) that require multiple concurrent forks, HA in test environments, and compliance (SOC 2, GDPR, HIPAA on Enterprise).

Note: Always check the current pricing page or your account rep for the exact fork behavior and limits on your plan.

Frequently Asked Questions

Can a zero‑copy fork affect my production TigerData service?

Short Answer: No. Once created, the fork is isolated; changes to the fork cannot modify the source service.

Details:
The source and fork share underlying storage blocks, but all writes use copy‑on‑write semantics. That means:

• Reads on the fork never block or alter the source.
• Inserts/updates/deletes on the fork allocate new blocks; the source keeps its original blocks.
• Schema changes (ALTER TABLE, CREATE INDEX, etc.) applied to the fork only affect that fork’s catalog and data files.

Operationally, you should still treat the fork like any other service: give it separate credentials, separate networking rules, and never point production traffic at it.

Which fork strategy should I use: NOW, LAST_SNAPSHOT, or PITR?

Short Answer:

• Use NOW for active incidents where you need the current state.
• Use LAST_SNAPSHOT for quick, recent clones when exact “to the second” timing doesn’t matter.
• Use PITR with target_time when you need to reproduce a specific historical state (forensics or regression analysis).

Details:

• NOW:

  • Best when the bug is happening right now.
  • You get a snapshot very close to the current state.
  • Slightly more overhead than using an existing snapshot, but you gain freshness.

• LAST_SNAPSHOT:

  • Tiger Cloud leverages the last snapshot already taken for backups/PITR.
  • Faster and operationally cheaper to create.
  • Great for daily migration rehearsal or regular load testing.

• PITR:

  • Uses WAL to reconstruct the database as of target_time.
  • Essential for incident analysis where order-of-operations matters (e.g., “What did the data look like right before the deploy at 17:30 UTC?”).
  • Requires that WAL retention covers the requested time.

Summary

Zero‑copy forks in Tiger Cloud give you a Postgres‑native way to debug incidents and test migrations at production scale without fragile dump/restore pipelines. By choosing the right fork strategy (NOW, LAST_SNAPSHOT, or PITR with target_time), you can spin up a realistic, isolated environment in minutes, experiment safely, and then tear it down once you’ve validated your fix or migration path. The underlying primitives—shared storage, copy‑on‑write, and Tiger Cloud’s snapshot/PITR infrastructure—keep it fast, cost‑efficient, and predictable for high‑ingest telemetry workloads.

Next Step

Get Started