Database / Google Cloud Bigtable Interview questions

Cloud Bigtable is Google Cloud's fully managed, wide-column NoSQL database for very large workloads that need consistently low latency. It grows from a few gigabytes to petabytes, and it is built on the same ideas as the internal system behind products like Search and Maps.

Data lives in tables as a sorted map: each row is found by a single row key, and each row can hold millions of sparse columns. You scale throughput by adding nodes, and Google handles patching, replication and failover.

There are no joins and no multi-row transactions, so it fits key-based access patterns (time series, user profiles, events) better than relational reporting.

Bigtable is a wide-column store. Conceptually it is a persistent, sorted, multi-dimensional map: (row key, column family:qualifier, timestamp) maps to a value. Rows are stored in lexicographic order of the row key, which is what makes range scans fast.

It is often confused with plain key-value or document stores, so the table below shows where it sits.

One important catch: Bigtable has no built-in secondary indexes. If you need to look data up two ways, you design two row key layouts or keep a second table.

A deployment is built from four pieces: instance, cluster, node and table.

• Instance - the top-level container. It holds clusters and tables, and carries the instance-level settings such as app profiles.
• Cluster - a set of nodes living in one zone. You pick SSD or HDD storage when you create it. An instance can have several clusters, and that is how replication is set up.
• Node - the compute unit that serves reads and writes for the tablets assigned to it. Nodes do not hold the data themselves.
• Table - belongs to the instance, so every cluster in that instance serves the same tables.

A common slip is to think each cluster has its own tables. It does not: tables are instance-wide and replication keeps the clusters in sync.

The row key is the unique identifier of a row and the only indexed field in a table. Bigtable keeps rows sorted by it, so every read is either a point lookup on a key, a prefix scan, or a range between two keys.

Keys are plain byte strings with a hard limit of 4 KB, though you should keep them far shorter. A good key puts data you read together next to each other and avoids sequential prefixes that pile traffic onto one node.

user#00417#2026-10-22
device#thermo-9#sensor#temp

Because the key drives performance and cost more than anything else in the schema, changing it later means rewriting the table.

A column family is a named group of related columns inside a table. You must create the family before writing data into it, and every column belongs to exactly one family.

Families matter for two practical reasons. First, garbage collection policies are set per family, so you can keep one family's cells for 7 days and another's forever. Second, a read can ask for only certain families, which keeps responses small.

Keep the number small. Google recommends staying around 100 families per table at most, and short family names save space because the name is repeated in storage. Put data that is read together in the same family, and data with different retention in separate ones.

cbt createfamily events metrics
cbt createfamily events profile

A column qualifier is the name of a column inside a column family. A full column is written as family:qualifier, for example profile:email.

Unlike a relational schema, qualifiers are not declared up front. A write simply names a new qualifier and it exists, and rows in the same table can use completely different sets. Because empty cells cost nothing, tables stay sparse.

This also lets you store data in the qualifier. A common trick is one family called follows where each qualifier is a followed user's ID and the value is empty, giving you a compact adjacency list in one row. Qualifiers can be up to 16 KB, but keeping them short pays off.

A cell is the value stored where a row key meets a column (family:qualifier). Each cell carries a timestamp, and a column can hold many timestamped versions of the same cell.

So the real address of a value is three-part: row key, column, and timestamp. By default Bigtable stamps a write with the server time in microseconds, but your client can supply one, which is how you control versioning or make a retry idempotent.

A read returns the newest version unless you filter otherwise, and garbage collection removes older ones. Cells are capped at 100 MB, though around 10 MB is the sensible ceiling.

A tablet is a contiguous range of rows from a table. Bigtable splits tables into tablets automatically and treats the tablet as the unit it balances across nodes.

Tablets are stored as SSTable files in Google's distributed file system, Colossus, not on the nodes. A node just holds pointers to the tablets it currently serves. That is why moving a tablet to another node is cheap: only the assignment changes, no data is copied.

Bigtable splits a tablet when it grows large or gets busy, and merges small neighbours back together. You do not manage this by hand, but your row key design decides whether the load spreads across many tablets or lands on one.

You choose the storage type when you create a cluster, and you cannot switch it afterwards on that cluster.

SSD is the default recommendation. HDD saves money per gigabyte, but random reads are slow, and Google's guidance is that it only makes sense above 10 TB with mostly scans and little latency sensitivity. Because it cannot be changed in place, a wrong pick means creating a new cluster and moving the data.

Bigtable suits workloads with huge volume, high write rates and lookups by key.

• Time series and IoT - sensor readings, metrics and logs, with keys like device ID plus time.
• Ad tech and marketing - impression and click events, user segments and real-time bidding profiles.
• Fintech - transaction history, fraud signals and ledgers read by account.
• Personalization and recommendations - per-user feature rows served in milliseconds.
• ML feature stores - online serving of precomputed features.
• Graph and social data - adjacency lists stored one row per entity.

What these share is a predictable access path through the row key. If your workload needs ad-hoc joins or multi-row transactions, look at BigQuery or Spanner instead.

Bigtable enforces some hard limits and gives softer recommendations that you should treat as the real targets.

Staying well under the hard limits matters because very large rows cause slow reads, memory pressure and compaction trouble. If a row keeps growing, for example appending every event to one user's row, switch to a taller, narrower design with one row per event.

Garbage collection (GC) is how Bigtable deletes old cells automatically, based on a policy you set on each column family. It is not related to JVM memory management.

Two rules are available, and you can combine them:

• Max age - delete cells older than a duration, such as 30 days.
• Max versions - keep only the newest N versions of each column.
• Union (either rule matches) or intersection (both must match).

cbt setgcpolicy metrics readings maxage=30d or maxversions=2

GC runs in the background during compaction, so expired data may still be returned for a while, sometimes up to a week. If a query must never see expired cells, filter by timestamp in the read as well.

cbt is a command-line tool, written in Go, for basic Bigtable administration and data operations. It is handy for quick checks, scripts and demos, though production traffic goes through client libraries.

It reads the project and instance from a ~/.cbtrc file, so you do not repeat them on each call.

echo project = my-project > ~/.cbtrc
echo instance = my-instance >> ~/.cbtrc

cbt createtable orders
cbt createfamily orders cf
cbt set orders order#1001 cf:status=PENDING
cbt read orders prefix=order# count=5
cbt count orders

Typical commands include createtable, createfamily, set, read, lookup, ls, deleterow and setgcpolicy. Remember that cbt count scans every row, so avoid it on very large tables.

Bigtable's data API is based on gRPC, and Google ships Cloud client libraries for the common languages: Java, Go, Python, C++, C#, Node.js, PHP and Ruby.

There are also integrations rather than raw libraries:

• Bigtable HBase client for Java - lets existing HBase code talk to Bigtable.
• Apache Beam / Dataflow connector - for batch and streaming pipelines.
• Spark and Hadoop connectors - used from Dataproc.
• cbt and gcloud bigtable - command-line administration.

Whichever library you use, create the client once and reuse it. Each client keeps a pool of gRPC channels, and opening a new client per request is a common reason for high latency.

Bigtable's data model is close to Apache HBase's, so Google provides a Bigtable HBase client library that implements the HBase Java API on top of Bigtable. Existing HBase applications can usually switch with a dependency and configuration change rather than a rewrite.

Connection conn = BigtableConfiguration.connect("my-project", "my-instance");
Table table = conn.getTable(TableName.valueOf("orders"));
table.put(new Put(Bytes.toBytes("order#1001"))
    .addColumn(Bytes.toBytes("cf"), Bytes.toBytes("status"), Bytes.toBytes("PENDING")));

Compatibility is not total. Server-side extras such as coprocessors are not supported, some filters behave differently, and HBase snapshots are replaced by Bigtable backups. Check the compatibility notes before assuming a drop-in migration.

Replication keeps copies of your data in several clusters of the same instance, in different zones or regions. You turn it on simply by adding another cluster; Bigtable then copies writes between clusters automatically and asynchronously.

It buys you three things:

1. Availability - if one cluster becomes unreachable, traffic can fail over to another.
2. Workload isolation - run batch analytics on one cluster while another serves live traffic.
3. Proximity - place clusters near users to reduce latency.

An instance can have up to 8 clusters, each in a different zone. Because copying is asynchronous, a read from a different cluster may briefly show older data. That is the price of the extra availability.

An app profile is an instance-level setting that tells Bigtable how to handle requests coming from a particular application. Each client connects using an app profile ID, and a default one exists if you do not pick.

The main settings are:

• Routing policy - single-cluster routing sends everything to one chosen cluster, while multi-cluster routing sends each request to the nearest available cluster.
• Single-row transactions - allowed only with single-cluster routing.
• Request priority - low, medium or high, so a batch job does not starve user-facing traffic.

A tidy pattern is one profile per workload: checkout-api with multi-cluster routing for live traffic, and nightly-etl pinned to a secondary cluster at low priority.

Autoscaling lets Bigtable add or remove nodes in a cluster on its own, so you do not provision for the peak all day. You configure it per cluster.

You set three things: a minimum and maximum node count, a CPU utilization target, and a storage utilization target. Bigtable adds nodes when CPU or storage exceeds the target and removes them when load drops, never going outside the min and max you set.

Scale-up reacts faster than scale-down, which is deliberate because a cluster that shrinks too eagerly can hurt latency. Set the minimum high enough to hold your stored data and cover expected baseline traffic, and the maximum as a cost guard rail.

Key Visualizer is a diagnostic tool that draws a heatmap of how your table is being used. The horizontal axis is time and the vertical axis is the row key space, with colour showing activity such as read or write rate, latency or row size.

Its main job is to reveal hotspots. A bright horizontal band means a narrow key range is taking a disproportionate share of traffic, and a diagonal pattern often means sequential keys marching across the table. It also helps spot oversized rows and verify that a new key design actually spreads load.

It only produces scans for tables that are large and busy enough, so a tiny test table may show nothing. Check the current documentation for the exact thresholds.

A Bigtable backup is a managed, point-in-time copy of a table's schema and data. You can create one on demand or on a schedule, and it is stored alongside a cluster separately from the live table.

Key points to remember:

• A backup has an expiration time; the maximum retention is up to 90 days.
• Restoring always creates a new table, so you can compare or swap it in. It does not overwrite the original.
• You can copy a backup to another cluster, region or project for extra protection.
• Backups protect against logical mistakes like a bad delete, which replication does not, since replication copies the mistake too.

You are billed for backup storage, so set sensible expiry times.

Data Boost is a serverless compute option for reading Bigtable data without using your cluster's nodes. It is aimed at big analytical or batch reads that would otherwise compete with live traffic.

You access it through a dedicated Data Boost app profile. Jobs from Dataflow, Spark or BigQuery read the stored data directly, so your production cluster's CPU is not affected. Billing is by serverless processing units used rather than by nodes.

Limits to keep in mind: it is read-only, and it targets throughput-oriented scans, not low-latency point lookups.

A change stream records every data change on a table - inserts, updates and deletes - so other systems can react to them. You enable it per table and choose a retention period between 1 and 7 days.

Records are grouped by row key ranges, and each carries the mutation along with its commit time. The standard way to consume them is the Dataflow connector (BigtableIO.readChangeStream) or the Java client.

Typical uses are replicating changes to BigQuery for analytics, publishing to Pub/Sub to trigger downstream services, and building audit trails. Keep in mind that change streams add some storage and processing cost, and that a pipeline that falls behind longer than the retention window loses the ability to catch up.

GoogleSQL for Bigtable lets you query Bigtable tables with SQL, so teams do not have to write low-level read calls for everything. The row key is exposed as _key, and column families appear as maps you index by qualifier.

SELECT _key, cf['status'] AS status
FROM orders
WHERE _key >= b'order#2026-10'
  AND _key < b&#x27;order#2026-11&#x27;
LIMIT 50;

It is a good fit for exploration, dashboards and simple aggregation. But SQL does not change how Bigtable stores data: a query that cannot narrow by row key still scans a lot of rows, and the cost shows up as CPU on your nodes. Write queries with row key ranges first.

Aggregate cells let Bigtable combine writes on the server, so you can keep counters and similar totals without reading the value first. You create a column family with an aggregate type, then send add-to-cell mutations.

Supported aggregates include sum, min, max and approximate distinct counts using HyperLogLog. Each write is merged into the existing value instead of replacing it.

This beats the old read-modify-write approach for counters in two ways: it needs no round trip, and it works safely with replication and multi-cluster routing, where read-modify-write is not allowed. Typical uses are page view counters, running totals and unique visitor estimates.

Bigtable separates compute from storage. Nodes serve requests, but the data itself lives in Colossus, Google's distributed file system, as immutable SSTable files. A table is cut into tablets, and each tablet is assigned to one node at a time.

When a write arrives, the node appends it to a commit log and places it in an in-memory memtable. When the memtable fills, it is flushed as a new SSTable. Over time compaction merges SSTables, drops deleted and expired cells, and keeps reads from checking too many files.

flowchart LR
  C[Client] --> N["Node serving the tablet"]
  N --> L["Commit log in Colossus"]
  N --> M["Memtable in memory"]
  M -- flush --> S["SSTable files in Colossus"]
  S -- compaction --> S2["Merged SSTable"]

This design explains two behaviours. Rebalancing is fast because moving a tablet only changes who serves it. And node failure does not lose data, since everything durable is already in Colossus.

A write starts at the client, which routes it according to its app profile to a cluster, then to the node that currently serves the tablet holding that row key.

sequenceDiagram
  participant App as Client
  participant Node as Tablet node
  participant Log as Commit log (Colossus)
  participant Mem as Memtable
  participant Rep as Other clusters
  App->>Node: MutateRow(row key, cells)
  Node->>Log: Append mutation
  Node->>Mem: Apply to memtable
  Node-->>App: Success
  Node--)Rep: Asynchronous replication

1. The node appends the mutation to the commit log, which makes it durable.
2. It applies the change to the in-memory memtable.
3. It acknowledges the client. All cells of one row change atomically.
4. Later, the memtable is flushed to an SSTable, and replication ships the change to other clusters in the background.

The acknowledgement does not wait for replication, which is why other clusters can lag slightly.

A read goes to the node serving the tablet that contains the requested row key or range. The node must produce a merged view because the newest data may sit in the memtable while older versions are spread across several SSTables.

1. Locate the tablet and node from the row key.
2. Check caches first: Bigtable keeps frequently read data in memory, including a cache of rows and blocks.
3. Read the memtable and the relevant SSTable blocks from Colossus on a cache miss.
4. Merge the results by timestamp, apply filters such as column and version limits, and drop cells already marked deleted.
5. Stream the rows back to the client in key order.

Scans are efficient because rows are sorted and contiguous. Point reads on hot rows are typically served from cache, which is why read latency is so low once data is warm. Reads that bypass filters and pull wide rows cost much more.

The row key is the only index, so it decides which queries are fast, how data is grouped on disk, and how evenly load spreads across nodes. A schema that is perfect in every other way still fails with a poor key.

Three things follow from that:

• Query speed - prefix and range scans only work on the leading part of the key.
• Locality - rows with adjacent keys land in the same tablet, so related data read together should share a prefix.
• Distribution - sequential prefixes such as timestamps push all new writes onto the last tablet.

Since you cannot rename keys in place, test the design with realistic data and Key Visualizer before launch.

Hotspotting happens when a small part of the key space takes most of the traffic, so one node's CPU is saturated while the others sit idle. Adding nodes does not help, because the busy tablet is still served by only one node.

Common causes are timestamp or auto-increment prefixes, reversed domain names that cluster popular sites, and a single very popular row.

Ways to avoid it:

• Field promotion - move a well-distributed field, such as device ID, to the front of the key.
• Salting - prefix the key with a hash bucket. It spreads writes but turns one range scan into several, one per bucket.
• Hashing the leading field, when you only do point lookups.
• Splitting a hot row into several rows, for example one counter row per shard.

bucket = hash(device_id) % 20
row_key = f"{bucket:02d}#{device_id}#{event_ts}"

Use Key Visualizer and the hot tablets view to confirm the fix worked.

Start with the entity you query by, then add time. A typical key is metric#device_id#timestamp. Because the entity comes first, writes from many devices spread across the table, and one device's readings stay together for a fast time-range scan.

Two further choices matter:

• Tall and narrow vs short and wide - Bigtable generally prefers one row per measurement (or per small time bucket) to one ever-growing row per device.
• Newest first - use a reverse timestamp (Long.MAX_VALUE - ts) when the common query is 'latest N readings'.

Always put a bounded retention policy in place with garbage collection, or the table keeps growing.

They solve different problems. Bigtable is an operational database for high-throughput, low-latency reads and writes by key. BigQuery is an analytical data warehouse for large SQL scans and aggregation across whole datasets.

They are often used together. Data lands in Bigtable for serving, then BigQuery queries it through an external table (ideally with Data Boost), and BigQuery can also export results back into Bigtable for fast serving.

Pick Bigtable when your access path is mostly by key, volume or write throughput is very high, and single-row atomicity is enough. Pick Spanner when you need relational features: joins, secondary indexes, foreign keys and ACID transactions across rows or even regions.

A useful rule of thumb: if you find yourself wanting transactions and secondary indexes, you are probably describing Spanner. If you can express every read as a row key range, Bigtable is usually cheaper at scale.

Neither is better in general; they target different applications. Firestore is a document database aimed at app developers, with mobile and web SDKs, realtime listeners, offline sync and automatic indexes. Bigtable is built for massive throughput and large data volumes behind backend services.

Choose Firestore for a mobile app's user data with realtime sync. Choose Bigtable for an event pipeline writing hundreds of thousands of rows per second.

Both are app profile routing policies in a replicated instance. Single-cluster routing sends every request from that profile to one named cluster. Multi-cluster routing sends each request to the nearest available cluster and fails over automatically.

The practical trade-off is consistency against availability. Many teams run live traffic on multi-cluster routing and keep batch jobs on a single-cluster profile pinned to another cluster.

Consistency depends on whether you use replication and how you route requests.

• Single cluster - reads and writes are strongly consistent. After a write is acknowledged, a read of that row from the same cluster sees it.
• Replicated, single-cluster routing - each profile still reads its own cluster, giving read-your-writes there. Other clusters catch up later.
• Replicated, multi-cluster routing - eventual consistency: a read may be served by a cluster that has not yet received the latest write.

When two clusters accept conflicting writes to the same cell, the one with the later timestamp wins, with a deterministic tiebreak if timestamps are equal. This is effectively last-write-wins.

Atomicity is only guaranteed within a single row. That is why related fields that must change together belong in the same row.

Bigtable only guarantees atomicity per row. A batch sent with MutateRows is just a way to send many row mutations in one request; each row's mutation is applied independently.

That means partial success is possible. Some rows can succeed while others fail, for example because of a timeout or a transient server error. The response contains a status for each entry, and your client must look at them instead of assuming all-or-nothing.

statuses = table.mutate_rows(rows)
failed = [i for i, s in enumerate(statuses) if s.code != 0]
# retry only the failed rows

To make retries safe, write idempotent mutations by setting explicit timestamps, since replaying a write with the same timestamp has no extra effect. And if two values must always change together, model them as cells in the same row.

Both are atomic single-row operations, and both need single-cluster routing. They answer different needs.

# CheckAndMutate: ship only if the order is still pending
row = table.conditional_row(b"order#1001", filter_=ValueRegexFilter(b"PENDING"))
row.set_cell("cf", b"status", b"SHIPPED", state=True)
row.commit()

# ReadModifyWrite: atomic increment
r = table.append_row(b"page#home")
r.increment_cell_value("stats", b"views", 1)
r.commit()

Use CheckAndMutate when the new value depends on a condition, such as optimistic locking or claiming a task so only one worker wins. Use ReadModifyWrite when the new value depends on the old one and you need it returned. Both run atomically on one row, so two clients racing on the same row are serialized rather than overwriting each other.

Neither works under multi-cluster routing. For high-volume counters, consider aggregate cells instead, since read-modify-write on one hot row can itself become a bottleneck.

Bigtable watches the load and size of every tablet and adjusts automatically. A tablet that is too large or too busy is split, tiny neighbours are merged, and tablets are reassigned between nodes so each node carries a similar share.

Reassignment is quick because data is not copied. It lives in Colossus, so the new node just starts serving the tablet. That is also why a freshly added node needs a little time before it helps: tablets must be moved to it and its caches warm up.

Rebalancing has limits worth knowing:

• It cannot split a single hot row, because a row is the smallest unit.
• It needs traffic patterns to be reasonably stable; sudden shifts in the key range take minutes to absorb.
• It cannot fix poor key design, only spread what the keys allow.

Bigtable scales horizontally. Add nodes and throughput grows roughly linearly, remove them to cut cost. You can resize manually in the console, with gcloud, or turn on autoscaling and let CPU and storage targets drive it.

gcloud bigtable clusters update my-cluster --instance=my-instance --num-nodes=12

A few rules decide how many nodes you need:

• CPU - keep average utilization around 70% or lower on a single cluster, and lower for replicated clusters that must absorb a failover.
• Storage per node - stay inside the per-node limits, and leave headroom rather than running close to full.
• Replicated instances - each cluster is sized on its own.

After a resize, give Bigtable some time to rebalance tablets before judging performance, and load-test a new size before the big traffic event, not during it.

Most gains come from reading less data and reading it in a way that suits how Bigtable stores it.

1. Use row key ranges or prefixes instead of full table scans.
2. Filter on the server - restrict by column family, qualifier, timestamp range or number of versions so unneeded cells never leave the node.
3. Limit the result with a row limit when you only need the first rows.
4. Keep rows small - very wide rows slow every read that touches them.
5. Reuse the client so connections are pooled, and keep the client close to the cluster.
6. Use SSD for random reads, and keep node CPU below the recommended level.

rows = table.read_rows(
    row_set=RowSet(),   # add a prefix or range here
    filter_=RowFilterChain(filters=[
        FamilyNameRegexFilter("stats"),
        CellsColumnLimitFilter(1)]),
    limit=100)

For heavy repeated lookups, ask whether a continuous materialized view could precompute the answer.

Work from the cluster outward, checking the usual suspects in order:

1. Cluster CPU and the hottest node. High max CPU with low average points to a hotspot, not a lack of nodes.
2. Key Visualizer and the hot tablets view. Look for bright bands and sequential key patterns.
3. Storage per node. A nearly full cluster slows down because background work has little room.
4. Row and cell size. Oversized rows or large values make reads and compactions expensive.
5. Workload mix. A batch job or large scan may be crowding out live traffic. Move it to a separate app profile with low priority, another cluster, or Data Boost.
6. Client side. New clients per request, high network distance, or aggressive retries can look like server slowness.
7. Recent changes - a new key format, a deployment, a schema change.

Cloud Monitoring graphs for latency, rows read and written, and error rates tell you whether the slowness began at a specific time, which narrows the cause quickly.

There are two broad approaches, depending on how much downtime you can accept.

flowchart LR
  A["Create HBase snapshot"] --> B["Export to Cloud Storage"]
  B --> C["Dataflow import to Bigtable"]
  C --> D["Validate row counts and hashes"]
  D --> E["Switch application to Bigtable HBase client"]

Before starting, create the Bigtable tables with matching column families and sensible GC policies, since HBase version settings map to GC rules. Then run a validation step comparing hashes of both sides, update the application to the Bigtable HBase client, and cut over once the data matches. Test coprocessors and custom filters early because they are not supported.

Security is layered across identity, encryption and network controls.

• IAM - predefined roles such as Bigtable Admin, User, Reader and Viewer can be granted at the project, instance or table level. Follow least privilege and give applications service accounts rather than user accounts.
• Authorized views - for finer control, expose only certain rows and columns to a given identity.
• Encryption at rest - on by default with Google-managed keys. Choose CMEK with Cloud KMS if you must control the key; it is set per cluster.
• Encryption in transit - TLS for client connections.
• Network perimeter - VPC Service Controls and Private Google Access reduce exfiltration risk.
• Audit logging - Admin Activity logs are on, and Data Access logs can be enabled to record reads and writes.
• Deletion protection - guards instances and tables against accidental removal.

Plain IAM does not filter rows. If tenants share a table, use authorized views.

An authorized view is a defined slice of a table that you share with an identity without giving it access to the whole table. You describe the slice in a definition: which row key prefixes, column families and qualifiers are included.

Unlike logical and continuous materialized views, authorized views control both reads and writes, and permissions are granted on the view itself. They store no extra data, so there is no extra storage cost.

The classic use is multi-tenant data: one table with a key like tenantA#..., and a separate authorized view per customer limited to its own prefix. The customer's service account can then read and write only inside that slice, even though the data physically lives in one shared table.

A continuous materialized view is a read-only table that Bigtable builds by continuously running a SQL query against a source table and keeping the result in sync. The view has its own schema, usually pre-aggregated or reshaped for a different access pattern.

That solves a familiar problem: your source keys serve one query well, but a dashboard needs hourly totals by region. Instead of aggregating on each request, you let Bigtable maintain the totals and read them directly.

Check the current documentation for the feature's launch stage, since it has been released in phases.

For bulk movement, Google provides Dataflow templates. They run as managed pipelines, so no cluster to build.

• Export - Bigtable to Cloud Storage as Avro, Parquet or SequenceFile.
• Import - Cloud Storage back into Bigtable from the same kinds of files.
• BigQuery to Bigtable - export query results into Bigtable for serving (reverse ETL).
• Backups - for restoring within Google Cloud, simpler than exporting files.
• cbt - only for small tests.

Run exports with care. A big export reads the whole table, so schedule it off-peak, give the job its own app profile at low priority, or use Data Boost to keep it off production nodes. Also, import tables in key order where possible or presplit them, so the load does not hit one tablet first.

There are two main routes. The first is a BigQuery external table over Bigtable, which lets you run SQL joins and aggregates against live Bigtable data without copying it.

CREATE EXTERNAL TABLE mydataset.bt_orders
OPTIONS (
  format = 'CLOUD_BIGTABLE',
  uris = ['https://googleapis.com/bigtable/projects/my-proj/instances/my-instance/tables/orders'],
  bigtable_options = '''{"readRowkeyAsString": true,
    "columnFamilies": [{"familyId": "cf", "onlyReadLatest": true,
      "columns": [{"qualifierString": "status", "type": "STRING"}]}]}'''
);

The mapping tells BigQuery which families and qualifiers to expose and how to decode them. The second route is reverse ETL: BigQuery exports query results into Bigtable so applications can read them in milliseconds.

Queries over an external table read from your cluster, so a heavy scan can compete with production traffic. Prefer Data Boost for analytical reads, or a separate cluster and app profile.

Bigtable billing has a few independent parts, so the final bill depends on how you size and use the instance.

Node cost is usually the biggest piece, and every replicated cluster adds its own nodes and storage, so replication roughly multiplies the footprint. To control cost: use autoscaling with a realistic minimum, expire old data with GC policies, keep backup retention short, and check the pricing page for current rates.

Bigtable is a poor choice when the workload needs features it does not offer, or when it is simply too small to justify it.

Cost matters too. Bigtable is billed by provisioned nodes, so a tiny, rarely used dataset costs more than it would on a pay-per-use service. If you cannot describe your reads as row key lookups or ranges, that alone is a warning sign.

Very little data risk, because nodes do not own the durable data. Tablets and the commit log live in Colossus, so a failure only affects who serves them.

flowchart TD
  A["Node becomes unavailable"] --> B["Bigtable detects the failure"]
  B --> C["Its tablets are reassigned to healthy nodes"]
  C --> D["New nodes replay the commit log into memtables"]
  D --> E["Clients retry and traffic resumes"]

During reassignment, requests to the affected key ranges can see a short spike in latency or transient errors. Client libraries retry such errors automatically, so well-written applications usually notice only a blip. Caches on the new node start cold, so latency can stay slightly higher for a short time.

A node failure is different from losing a zone. In a single-cluster instance a zonal outage makes the cluster unavailable until it recovers. With replication and multi-cluster routing, requests move to a cluster in another zone automatically.