Generated banner for Bigtable Basics
Generated logo for Bigtable Basics

Bigtable Basics

GoogleOfficialPublished by Google

  • Skill
  • Tool integration
  • Data and AI
  • Apache-2.0
  • No issues found

From the author

Assists in provisioning instances/tables, designing performant schemas, and querying data in Bigtable. Use when designing Bigtable row keys, configuring column families, writing SQL queries or client library code (Java, Go, Python) for Bigtable, or diagnosing performance/hotspotting issues. Also use when provisioning Bigtable clusters using gcloud or cbt CLIs. Don't use for generic Cloud SQL administration.
— the description by Google

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Bigtable-basics provides essential guidance for managing Google Bigtable instances, tables, and data. It covers control plane operations via gcloud, data plane tasks using the cbt CLI, and best practices for schema design, row key optimization, and performance troubleshooting. The skill emphasizes high-performance patterns, including the use of Key Visualizer for diagnostics and selecting appropriate client libraries for production workloads.

What it does

  • Guides the provisioning of Bigtable instances, clusters, and tables.
  • Provides patterns for designing performant row keys and column families.
  • Facilitates data reading and writing using cbt and SQL interfaces.
  • Offers workflows for diagnosing performance issues and hotspotting.
  • Includes instructions for schema evolution and garbage collection policy management.
  • Ensures proper usage attribution for CLI commands.

When to use it

  • When setting up or modifying Bigtable infrastructure and schemas.
  • When writing or debugging client application code for Bigtable.
  • When performing manual data validation or quick lookups via CLI.
  • When investigating performance bottlenecks or table hotspots.
  • When planning for complex data access patterns using materialized views.

Advantages

  • Promotes performance-first design principles for NoSQL data modeling.
  • Clearly distinguishes between control plane and data plane operations.
  • Provides actionable diagnostic workflows for identifying slow queries.
  • Standardizes CLI usage with required attribution tracking.

Usage examples

“How do I create a new column family with a specific garbage collection policy?”
The agent provides the cbt createfamily and cbt setgcpolicy commands with the correct syntax for setting max versions and age.
“I am seeing performance issues. How can I diagnose hotspotting?”
The agent instructs the user to use Key Visualizer in the Cloud Console and explains how to use cbt read with stats to identify slow queries.
“How do I read a single row efficiently?”
The agent recommends using the cbt lookup command for point reads instead of a full table scan.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/google/bigtable-basics/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip bigtable-basics.zip -d .agents/skills

Documentation by Google

Bigtable Basics

This skill provides core workflows and guidance for administering and developing with Google Bigtable.

Attribution

MUST READ: Before executing any gcloud, REST API, or MCP command, you MUST read Usage Attribution. For commands executed directly in the terminal (never in generated scripts, Terraform, or user code), prefix gcloud with CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:bigtable-basics)" and append agent-skills/1.0 (skill:bigtable-basics) to User-Agent headers.

Core Principles

  • Control Plane vs. Data Plane:

    • Use gcloud for Control Plane operations: Manage Instances, Clusters, App Profiles, Backups and IAM. Create Tables, Logical Views, Materialized Views and Authorized Views.

    • Use cbt for Data Plane operations: Update Tables, Column Families, and reading/writing data.

  • Performance First: Bigtable is a NoSQL database. Efficiency is tied to Row Key design. Always warn about Full Table Scans.

  • Client Selection: For production use cases, prefer Java or Go for their superior performance and feature coverage compared to other languages.

  • Observability: When diagnosing performance or hotspotting, always mention Key Visualizer (via Cloud Console) as the primary diagnostic tool because it provides the most granular view of access patterns across row keys. This should be followed by the hot-tablets tool and table stats in gcloud CLI and include-stats=full option under cbt read to diagnose slow queries.

[!IMPORTANT] Safety Rule: You MUST obtain explicit user confirmation before making non-emulator database changes. You MUST mention this safety requirement when providing commands or instructions that modify the database structure or data.

Quick Recipes

1. Querying Data

Use SQL for complex transforms or aggregations and key-value APIs for simpler query patterns. Note: Use exact match, prefix (_key LIKE 'myprefix%'), or range predicates on _key to avoid expensive unbounded scans. Recommend explicit row ranges (_key BETWEEN 'start' AND 'end') as a more performant alternative to prefix matches where possible.

If expensive scans (either unbounded or prefix or range queries scanning a large range) are unavoidable due to multiple access patterns that can’t all be accommodated in a single schema, consider one of these two options:

  • If the query will be used in user facing and/or latency sensitive applications, use continuous materialized views with keys optimized for the additional access patterns.

  • If secondary access patterns are infrequent, batch patterns like ETL, ML model training or analytical read-only tasks, use Bigtable Data Boost instead.

2. Manipulating Data

Use key-value APIs for insert, update, increment and delete operations. SQL API is read-only.

3. Data Model Definition (DDL)

SQL API doesn't support DDL operations. Table creation, deletion, updates should be made using gcloud CLI. Logical Views and Continuous Materialized Views are defined as SQL queries but they must be created using gcloud CLI.

Reference Guides

Common Workflows

Schema Evolution (DevOps)
  1. Prefer Terraform for production schema changes to prevent accidental data loss.

  2. For manual cbt changes, first check the existing state by listing the table's column families and GC policies before proposing any modifications:

    cbt ls {table}

    If modifications are needed, create the family or update the GC policy:

    cbt createfamily {table} {family}
    cbt setgcpolicy {table} {family} "maxversions=5 AND maxage=30d"
  3. Reference infrastructure_management.md for full syntax.

External Resources

Files

references/sql_guide.md

Bigtable SQL Guide for Agents

This document outlines key aspects of Google Bigtable's SQL dialect which extends GoogleSQL to support a multi-version wide-column data model. Bigtable currently only supports SELECT statements over single tables i.e. JOIN and UNION operations are not supported with the exception of JOINs with UNNEST(array) to support working with nested objects.

Table of Contents

  • Bigtable SQL Data Structures [L19-L190]

    • Columns [L21-L42]

    • Primitive types [L43-L65]

    • Timestamps [L66-L124]

    • Row keys [L125-L157]

    • Maps [L158-L164]

    • Protocol buffers (protos) [L165-L181]

    • Functions and operators [L182-L190]

Bigtable SQL Data Structures

Columns

Unless table metadata indicates otherwise, columns are of Map type which hold versioned key-value pairs. In legacy Bigtable APIs, SQL maps correspond to column families.

  • Access Pattern: You cannot select a column directly as a scalar value. You must access the specific key within the column family.

  • Correct Syntax Example:

    -- CORRECT: Use map-like bracket notation for the column qualifier.
    SELECT cf1['text'] FROM messages;
  • Incorrect Syntax Example:

    -- INCORRECT: Dot notation is not supported and will fail.
    SELECT cf1.text FROM messages;
Primitive types

There is often no type information associated with column values. You should infer the type from the name of the column and include an explicit cast in generated SQL queries.

  • Example: SELECT CAST(info['address'] AS STRING) AS address FROM table_name

  • Example: SELECT CAST(CAST(info['age'] AS STRING) AS INT64) AS age FROM table_name

  • Example: SELECT SAFE_CAST(info['address'] AS STRING) FROM table_name;

  • Example: SELECT TO_INT64(cf['age']) as age FROM table_name

  • Example: SELECT CAST(CAST(cf['checkin_date'] AS STRING) AS DATE) AS checkin_date FROM table_name

  • Example: SELECT TIMESTAMP(CAST(CAST(cf['checkin_date'] AS STRING) AS DATE)) AS checkin_date_time FROM table_name

  • Example: SELECT CAST(CAST(cf['is_booked'] AS STRING) AS BOOL) AS is_booked FROM table_name - if "true" or "false" was stored

  • Example: SELECT CAST(TO_INT64(cf['is_booked']) AS BOOL) AS is_booked FROM table_name - if 1 or 0 was stored`

  • Example: SELECT CAST(SAFE_CONVERT_BYTES_TO_STRING(cf['is_booked']) AS BOOL) AS is_booked from table_name, if "true" or "false" was stored

Timestamps

By default Bigtable returns the latest value of each column when use with a standard SELECT statement. You can use different flags explained below to get prior versions. Using any flag other than "as_of" and "with_history => FALSE" will return timestamp-value pairs. SQL interface exposes Bigtable timestamps as SQL TIMESTAMP type. This section doesn't contain the exhaustive list of all version management flags, for more details refer to the Google Cloud documentation.

  • Access Pattern: To retrieve values as of a certain point in time (on or immediately prior to the provided timestamp), use the as_of flag.

SELECT * FROM table_name(as_of => TIMESTAMP("2025-03-28 14:13:40-0400"))

  • Access Pattern: To retrieve all versions treat table name as a table-valued function and set the with_history flag to TRUE.

SELECT * FROM table_name(with_history => TRUE)

  • Access Pattern: To retrieve last 5 versions treat table name as a table-valued function and use the with_history flag.

SELECT * FROM table_name(with_history => TRUE, latest_n => 5)

  • Access Pattern: To retrieve a range of timestamps treat table name as a table-valued function and use the before, after, after_or_equal, and before_or_equal flags.

SELECT * FROM table_name(with_history => true, after => TIMESTAMP("2025-03-28 14:13:40-0400"), before_or_equal => TIMESTAMP("2025-03-28 14:15:10-04:00"))

  • Access Pattern: Convert timestamped values into a flat table and perform time bucketing and aggregations.

SELECT TIMESTAMP_TRUNC(_timestamp, HOUR) AS hourly, AVG(temp_versioned) AS average_temperature FROM
UNPACK((SELECT metrics['temperature'] AS temp_versioned FROM sensorReadings(with_history => true, after => TIMESTAMP('2023-01-14T23:00:00.000Z'), before => TIMESTAMP('2023-01-21T01:00:00.000Z'))
WHERE _key LIKE 'sensorA%'))
GROUP BY 1

Row keys

Each Bigtable row is identified with a unique key. Bigtable SQL interface has a pseudo-column named _key that is used to query by row key.

Standard Scans (Opaque Key)

Success with Bigtable depends on translating logical queries into efficient physical scans.

  • Point Lookup: SELECT * FROM table_name WHERE _key = 'row_key'

  • Prefix Scan: SELECT * FROM table_name WHERE STARTS_WITH(_key, 'prefix#')

  • Range Scan: SELECT * FROM table_name WHERE _key >= 'start#key' AND _key < 'end#key'

  • Fuzzy Match: SELECT * FROM table_name WHERE _key LIKE '%#pattern#%' (Warning: Causes full table scan)

Querying with Structured Row Keys

If a Structured Row Key is defined for the table (see schema_design.md), you can reference segments directly by name in the WHERE clause. This allows for cleaner, more expressive queries.

  • Syntax: SELECT * FROM table_name WHERE segment_name = 'value'

  • Example: If your structure defines tenant_id and timestamp, you can query: SELECT * FROM table_name WHERE tenant_id = '123' AND timestamp > 1713300000

Agent Action: When generating queries that are not looking for exact matches (point lookups), key ranges, or prefixes, warn the user that the query will result in a full table scan.

Maps

Inspect qualifiers within a column family.

  • Example: SELECT MAP_KEYS(cf1) FROM table_name

  • Example: SELECT MAP_ENTRIES(cf1) FROM table_name

Protocol buffers (protos)

Some users prefer to serialize data to protobufs and store them as blobs in Bigtable. Protobufs reduce the storage footprint and are often faster to read, advantageous for data that is not frequently updated. Protobufs can be directly queried using SQL after their schemas are registered using gcloud bigtable schema-bundles create.

  • Example: If you have profile proto that has attributes user_name, gender and birth_year registered under accounts bundle with package_name publisher stored under family user, column qualifier info you can query:

    SELECT CAST(user['info'] AS accounts.publisher.profile).user_name FROM accounts;
Functions and operators

Bigtable offers a wide range of SQL functions and operators and conditional expressions.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Google
Publisher
Google (Official)
Source
google/skills · skills/cloud/bigtable-basics · commit 2194d3b
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Google or Google.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download bigtable-basics.zip