> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lancedb.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Agentic skills

> Give a coding agent a current, maintained reference for the LanceDB APIs.

A coding agent writing LanceDB code from memory writes whatever was in its
training data: often an older API, sometimes one that never existed. The
LanceDB agent plugin fixes that by supplying the current reference at the point
the agent needs it.

## The plugin

It ships as the `lancedb` plugin in
the [lancedb-agent-plugins](https://github.com/lancedb/lancedb-agent-plugins)
repository, which is also a plugin marketplace. Install it with your agent's
plugin manager:

```text Claude Code theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
/plugin marketplace add lancedb/lancedb-agent-plugins
/plugin install lancedb@lancedb
```

```bash Codex icon="terminal" theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
codex plugin marketplace add lancedb/lancedb-agent-plugins
codex plugin add lancedb@lancedb
```

```bash Other agents icon="terminal" theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
npx plugins add lancedb/lancedb-agent-plugins
```

The [`plugins`](https://www.npmjs.com/package/plugins) installer shown under
**Other agents** is a cross-tool option. It detects which agent CLIs are on your
`PATH` (Cursor, GitHub Copilot CLI, VS Code, Grok Build, and Kimi Code, as well
as Claude Code and Codex) and installs through each one's native plugin system.

The plugin supplements the agent's training data with current LanceDB
instructions. To pick up later revisions, refresh the marketplace:

```text Claude Code theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
/plugin marketplace update lancedb
```

```bash Codex icon="terminal" theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
codex plugin marketplace upgrade
```

```bash Other agents icon="terminal" theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
npx plugins add lancedb/lancedb-agent-plugins
```

> [accordion] Where the plugin gets installed
>
> Each plugin manager clones the repository, reads its marketplace manifest to find
> the `lancedb` plugin, and hands the plugin to the agent's own plugin store rather
> than copying files into your project. Claude Code and Codex keep it under
> `~/.claude/plugins` and `~/.codex/plugins` respectively, so the plugin is available
> in every project on the machine.
>
> The `npx plugins` installer defaults to the same user-wide scope. Pass
> `--scope project` to record the plugin in the current repository instead, so that
> everyone working in it gets the same plugin, or `-t <target>` to install for a
> single agent rather than every one it detects:
>
> ```bash Bash icon="terminal" theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> npx plugins add lancedb/lancedb-agent-plugins --scope project -t cursor
> ```
>
> Not every agent supports project scope; `npx plugins targets` lists what it
> found and what each target supports.

## Automated prompt catalog

Explore the prompts covered by automated agent evaluations. Each prompt uses
example data and may require existing tables,
indexes, metadata, branches, version history, or running jobs. Replace the test
fixtures and connection details with your own before using a prompt.

The evaluations run against a LanceDB Enterprise test database, with and
without the agent plugin. Evaluation coverage does not guarantee success for
every agent or model.

Prompts are reproduced verbatim, including the answer formats used by automated
grading. Table names, local files, and placeholders in these prompts refer to
test fixtures. Supply your own data, database connection, and timestamps when
adapting them.

66 prompts.

### Tables and schema design

> [accordion] 101: list tables by prefix
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Some tables in this database came from a legacy load and are named with the prefix `eval_lt_`. Find every table whose name starts with `eval_lt_` and report them. This is a read-only check. End your answer with one line per table, each of exactly this form:
>
> TABLE: <table_name>
> ```

> [accordion] 102: describe table
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Give me an overview of the `eval_describe` table: its columns with their types, and how many rows it holds. This is a read-only check — do not modify anything. End your answer with one line per column, then two final lines, of exactly these forms. Write each `<type>` exactly as the API reports it, not as a synonym; for a nested type, write the outer type name with its element type and length in angle brackets (a 4-element vector of 8-bit ints would read `fixed_size_list<int8, 4>`):
>
> COLUMN: <column_name> = <type>
> ROWS: <row_count>
> COLUMNS: <number_of_columns>
> ```

> [accordion] 103: table storage stats
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> How is the `eval_table_stats` table laid out in storage? Report its total size on disk and its fragment layout. This is a read-only check. End your answer with two lines of exactly this form:
>
> BYTES: <total_size_in_bytes>
> FRAGMENTS: <number_of_fragments>
> ```

> [accordion] 104: create table with data
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Create a new table called `eval_created_products` in this database with three columns: `sku` (string), `name` (string), and `price` (float64). Populate it with exactly these 4 rows:
>
> | sku | name | price |
> |---------|------------------|--------|
> | SKU-001 | Espresso Machine | 249.99 |
> | SKU-002 | Milk Frother | 39.5 |
> | SKU-003 | Coffee Grinder | 89.0 |
> | SKU-004 | Digital Scale | 24.95 |
> ```

> [accordion] 105: create empty table
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Create a new, empty table called `eval_empty_events` in this database, ready for an event-logging pipeline to start writing into later. It needs three columns: `event_name` (string), `severity` (int64), and `payload` (string) — and no rows yet.
> ```

> [accordion] 107: drop table
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> The `eval_drop_me` table was created by a test run and is no longer needed. Drop it from the database — and nothing else.
> ```

> [accordion] 108: design tables from joined schema
>
> ````text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> My current DB has these 5 tables that join; how should I set up my tables in LanceDB?
>
> ```
> products    (product_id BIGINT PK, name TEXT, description TEXT, price NUMERIC(10,2), category_id BIGINT FK, brand_id BIGINT FK)
> categories  (category_id BIGINT PK, name TEXT)
> brands      (brand_id BIGINT PK, name TEXT, country TEXT)
> reviews     (review_id BIGINT PK, product_id BIGINT FK, rating SMALLINT, body TEXT)
> order_items (order_id BIGINT, product_id BIGINT FK, quantity INT, unit_price NUMERIC(10,2))
> ```
>
> In LanceDB the app will run one query: semantic search over product descriptions, filtered by category name and brand name, where every hit shows the product's name, price, category name, brand name, and average review rating. Order analytics stays in our warehouse. Description embeddings are 384-dimensional float32 vectors.
>
> Set the tables up in this database as you recommend: create them empty (schema only, no rows). Name the table the product search runs against `eval_schema_search`, and give any other table you create the `eval_schema_` prefix. Explain your design in your answer.
> ````

### Data ingestion and updates

> [accordion] 201: insert rows
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Append these 5 new products to the `eval_insert_rows` table (the embedding columns can be left null):
>
> | id | title | category | price_usd | relevance_score |
> |-----|--------------|-----------|-----------|-----------------|
> | 100 | Clearance A | clearance | 9.99 | 0.1 |
> | 101 | Clearance B | clearance | 10.99 | 0.1 |
> | 102 | Clearance C | clearance | 11.99 | 0.1 |
> | 103 | Clearance D | clearance | 12.99 | 0.1 |
> | 104 | Clearance E | clearance | 13.99 | 0.1 |
> ```

> [accordion] 202: delete rows by filter
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> All 'toys' products have been discontinued. Delete every row in category `toys` from the `eval_delete_rows` table — and nothing else.
> ```

> [accordion] 203: delete all rows
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> The `eval_purge` table was loaded from a corrupted export and every row in it is suspect. Clear out all of its rows — but keep the table itself (and its schema) in place so it can be reloaded.
> ```

> [accordion] 204: update rows by filter
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Editorial flagged every 'books' product in the `eval_update_rows` table for re-review: set `relevance_score` to 0 for all rows in category `books`. Don't touch any other rows.
> ```

> [accordion] 205: update with expression
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Run a flash sale on the `eval_discount` table: cut the price of every product in category `electronics` by 10% — each one's `price_usd` becomes 90% of its current value. Leave every other category's prices alone.
> ```

> [accordion] 206: upsert rows
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Sync the `eval_upsert` table with this batch of refurbished products, matching on `id`: update the row if the id already exists, insert it if not — as one upsert operation, not separate update and insert passes. The embedding columns can be left null.
>
> | id | title | category | price_usd | relevance_score |
> |-----|-----------------------|----------|-----------|-----------------|
> | 2 | Refurbished Product 2 | refurb | 19.99 | 0.5 |
> | 6 | Refurbished Product 6 | refurb | 29.99 | 0.5 |
> | 200 | Refurb Special A | refurb | 15.0 | 0.5 |
> | 201 | Refurb Special B | refurb | 18.0 | 0.5 |
> ```

> [accordion] 207: add column backfill
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Analytics needs integer cents. Add a `price_cents` integer column to the `eval_add_column` table, backfilled for every existing row as the price in cents (`price_usd` × 100, rounded to the nearest integer).
> ```

> [accordion] 208: rename column
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Rename the `price_usd` column of the `eval_rename_column` table to `price`, in place, keeping the data — do not rebuild or rewrite the table.
> ```

> [accordion] 209: drop column
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> The legacy `image_clip_v1` embedding column of the `eval_drop_column` table is superseded and wasting storage. Remove that column — keep everything else.
> ```

> [accordion] 210: cast column type
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Downstream tooling needs 64-bit floats: change the type of the `relevance_score` column in the `eval_cast_column` table from float32 to float64, in place, keeping the values.
> ```

> [accordion] 211: performant batch ingest
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Make sure my ingest pattern will be performant. My ingest script is `ingest.py` in your working directory; it creates the table `eval_ingest_events` in this database and loads the day's 1,000 events into it. Fix whatever would make the ingest slow or hurt the table, keeping the same table name, schema, and rows, then run it against this database so the table ends up holding exactly those 1,000 events.
> ```

### Queries and search

> [accordion] 301: filtered count
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> How many products in the `eval_filter_count` table are in category `books` with a price above $100? This is a read-only check. End your answer with a line of exactly this form:
>
> COUNT: <n>
> ```

> [accordion] 302: filtered ids
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Which products in the `eval_filter_ids` table are in category `electronics` and priced under $50? This is a read-only check. End your answer with one line per matching product, each of exactly this form:
>
> ID: <id>
> ```

> [accordion] 303: lookup row by id
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Look up the product with id 12 in the `eval_lookup_row` table and report its title. This is a read-only check. End your answer with a line of exactly this form:
>
> TITLE: <title>
> ```

> [accordion] 304: top k cheapest
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> What are the 3 cheapest products in the `eval_cheapest` table? This is a read-only check. End your answer with a line of exactly this form, ids ordered from cheapest up:
>
> CHEAPEST: <id>,<id>,<id>
> ```

> [accordion] 305: paginated read
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Our storefront lists the `eval_pagination` table's products cheapest-first, 3 to a page. A customer is looking at page 2 — which products do they see? This is a read-only check. End your answer with a line of exactly this form, the three ids in display (price-ascending) order:
>
> PAGE2: <id>,<id>,<id>
> ```

> [accordion] 306: pick column for image search
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> I have a LanceDB table called `eval_pick_column`. I want to let users upload a photo and find visually similar products. Which column should the similarity search run against? If there's more than one candidate, tell me which one to use and why. This is a read-only check — do not modify the table, its rows, or its metadata. End your answer with a line of exactly this form, naming the single column to use:
>
> RECOMMENDATION: <column_name>
> ```

> [accordion] 307: vector search similar
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> A shopper is viewing product 5 in the `eval_vector_search` table and we want a 'similar items' shelf. Using product 5's `image_clip_v2` embedding as the query, find the single most visually similar OTHER product. This is a read-only check. End your answer with a line of exactly this form:
>
> MATCH: <id>
> ```

> [accordion] 308: vector search filtered
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Same 'similar items' feature, but constrained to a department: using product 8's `image_clip_v2` embedding as the query on the `eval_vector_filtered` table, find the single most similar product in category `books` (product 8 itself is not in that category). This is a read-only check. End your answer with a line of exactly this form:
>
> MATCH: <id>
> ```

> [accordion] 309: full text search
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> A customer remembers a product description mentioning 'waterproof'. Using full-text search on the `eval_fts_search` table, find which product that is. This is a read-only check. End your answer with a line of exactly this form:
>
> MATCH: <id>
> ```

> [accordion] 310: fts multi match
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Marketing wants a list of every product in the `eval_fts_multi` table whose description mentions 'wireless'. Use full-text search to find them all. This is a read-only check. End your answer with one line per matching product, each of exactly this form:
>
> ID: <id>
> ```

> [accordion] 311: hybrid search
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Find the product in the `eval_hybrid_search` table most relevant to a shopper who typed the keyword 'solar' and whose taste profile is product 4's `image_clip_v2` embedding — i.e. combine keyword relevance and vector similarity (a hybrid search). This is a read-only check. End your answer with a line of exactly this form:
>
> MATCH: <id>
> ```

> [accordion] 312: explain query plan
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Before we ship a price filter on the `eval_explain_plan` table, confirm from the server's query plan whether a filter on `price_usd` (for example `price_usd < 50`) is served by an index or by scanning the table. This is a read-only check — do not build or drop anything. End your answer with exactly one of these lines:
>
> PLAN: index
> PLAN: scan
> ```

### Index management

> [accordion] 401: build index
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Queries that filter the `eval_build_index` table by `category` are slow. Build the appropriate index to speed them up.
> ```

> [accordion] 402: create vector index
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Vector similarity queries against the `image_clip_v2` column of the `eval_vector_index` table are running as brute-force scans. Build an ANN index on that column using cosine distance, and make sure it finishes building.
> ```

> [accordion] 403: create fts index
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Enable keyword (full-text) search over the `body_text` column of the `eval_fts_index` table, and make sure the index finishes building.
> ```

> [accordion] 404: inspect indexes
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Audit the indexes on the `eval_index_report` table: what indexes exist, and how many rows does the index on `category` cover? This is a read-only check. End your answer with one line per index plus one final line, of exactly these forms:
>
> INDEX: <index_name>
> INDEXED_ROWS: <rows covered by the category index>
> ```

> [accordion] 405: index coverage
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> The scalar index on `price_usd` of the `eval_index_coverage` table was built a while ago, and data has landed in the table since. Check the index's coverage: how many rows does it currently cover, and how many rows are not yet indexed? This is a read-only check — do not rebuild or modify anything. End your answer with two lines of exactly this form:
>
> INDEXED: <rows covered by the index>
> UNINDEXED: <rows not yet covered>
> ```

> [accordion] 406: drop index
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> The index on `price_usd` in the `eval_drop_index` table was an experiment and is slowing down writes. Drop that index.
> ```

### Version history and tags

> [accordion] 501: version history
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> How many versions does the `eval_versions` table have? This is a read-only check — do not create new versions. End your answer with a line of exactly this form:
>
> VERSIONS: <n>
> ```

> [accordion] 502: time travel read
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Without modifying the `eval_timetravel` table, compare it to its past: how many rows did it have at version 1, and how many does it have now? End your answer with two lines of exactly this form:
>
> THEN: <rows at version 1>
> NOW: <rows now>
> ```

> [accordion] 503: restore version
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Someone ran a bad cleanup against the `eval_restore` table and rows went missing. Roll the table back to the version immediately before the deletion, so the missing rows are back.
> ```

> [accordion] 504: tag version
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> We're about to run a risky migration on the `eval_tag_create` table. Tag its current version as `prod-baseline` so we can refer back to it later.
> ```

> [accordion] 505: read at tag
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> The `eval_tag_read` table's version tagged `release-v1` is what we shipped. Without modifying the table, compare then and now: how many rows did it have at the `release-v1` tag, and how many does it have now? End your answer with two lines of exactly this form:
>
> TAGGED: <rows at the release-v1 tag>
> NOW: <rows now>
> ```

> [accordion] 506: move tag
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> The `latest` tag on the `eval_tag_move` table still points at an old version, but the table has moved on since. Update the `latest` tag so it points at the table's current version. Leave any other tags alone.
> ```

> [accordion] 507: delete tag
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> The `deprecated` tag on the `eval_tag_delete` table is obsolete. Remove that tag — leave any other tags alone.
> ```

> [accordion] 508: compare two versions
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Compare version 3 and version 7 of the `eval_history_compare` table and explain, in plain English, what happened to it in between — cover the schema, the indexes, and the data. This is a read-only investigation: do not modify the table.
>
> Report only what changed AFTER version 3, up to and including version 7 — version 3 is the starting point, so whatever happened at version 3 itself is not one of the changes.
>
> End your answer with three lines of exactly these forms. The first two are comma-separated lists of column names (or NONE): the columns added in that range, and the columns that gained an index in that range. The third is exactly one of the five words offered, describing the row-level data changes in that range:
>
> COLUMNS_ADDED: <column_name>[, <column_name>...]
> INDEXES_ADDED: <column_name>[, <column_name>...]
> DATA_CHANGES: APPEND_THEN_DELETE | DELETE_THEN_APPEND | APPEND_ONLY | DELETE_ONLY | NONE
> ```

> [accordion] 509: changes since date
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Our last schema review of the `eval_history_since` table signed off at {cutoff}. Did any schema or index changes happen to that table since then? Explain in plain English what you find, and say which changes were not schema or index changes so we know they were considered. This is a read-only investigation: do not modify the table.
>
> This table also has columns and indexes that predate that timestamp — those are not what the review is asking about, so report only what changed at or after it.
>
> End your answer with four lines of exactly these forms: every table version at or after that timestamp that changed the schema or an index — version numbers only, comma-separated, ascending (or NONE); the column added by a schema change at or after that timestamp (or NONE); the column covered by an index built at or after that timestamp (or NONE); and every table version at or after that timestamp whose change was NOT a schema or index change — version numbers only, comma-separated, ascending (or NONE):
>
> CHANGED_VERSIONS: <version>[, <version>...]
> COLUMN_ADDED: <column_name>
> INDEX_ADDED: <column_name>
> OTHER_CHANGES: <version>[, <version>...]
> ```

> [accordion] 510: trace column to job
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Someone added a column called `foo` to the `eval_history_column_job_{db}` table and nobody wrote down why. Find the exact version where `foo` appeared, then find the background job that was pinned to that same table version and report what it is doing and its current state. There are several jobs on this table, pinned to different versions of it, so make sure the one you report is the one pinned to that version. This is a read-only investigation: do not cancel or modify anything.
>
> End your answer with four lines of exactly these forms (full job id, no truncation). Write `<job_type>` and `<current_state>` exactly as the API reports them, not as synonyms or prose:
>
> VERSION: <version_number>
> JOB: <job_id>
> TYPE: <job_type>
> STATE: <current_state>
> ```

### Column metadata and lineage

> [accordion] 601: add all metadata types
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Document the two image-embedding columns in the `eval_add_metadata` table: write a clear description for each, tag each with its field type, the model that produced it, and its version, mark the newer one as the latest, and group both under a single logical column.
> ```

> [accordion] 602: delete one metadata key
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> The `model` tag on the `image_clip_v1` column of `eval_delete_metadata` is wrong. Remove just that tag — leave the column's description and other tags alone.
> ```

> [accordion] 603: explain column origin
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Some columns in the `eval_lin_origin` table were generated by the platform rather than loaded with the data. Investigate the column `title_sentiment`: is it produced by a UDF or by a SQL expression, what produces it, and which columns does it read? This is a read-only investigation: do not modify the table.
>
> End your answer with lines of exactly these forms — one INPUT line per input column. Write the generator exactly as the table's own metadata records it (the UDF's registered name, or the SQL expression), not a paraphrase:
>
> KIND: <udf or expression>
> GENERATOR: <udf name or SQL expression>
> INPUT: <input_column_name>
> ```

> [accordion] 604: find downstream dependents
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> We want to drop the `price_usd` column from the `eval_lin_deps` table, but some of the table's generated columns are derived from other columns. Find every column that depends on `price_usd` — directly, or indirectly through another generated column. This is a read-only investigation: do not modify the table.
>
> End your answer with one line per dependent column, each of exactly this form (do not list `price_usd` itself):
>
> DEPENDENT: <column_name>
> ```

> [accordion] 605: trace column refresh job
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> The generated column `discounted_price` in the `eval_lin_job_{db}` table is filled in by a background refresh job, and we need to know which job that is. There is more than one job on this table (a long-lived database can also hold finished or cancelled leftovers), so make sure the one you report is the currently-running job that refreshes `discounted_price`. This is a read-only investigation: do not cancel or modify anything.
>
> End your answer with three lines of exactly these forms (full job id, no truncation). Write `<job_type>` and `<current_state>` exactly as the API reports them, not as synonyms or prose:
>
> JOB: <job_id>
> TYPE: <job_type>
> STATE: <current_state>
> ```

### Namespaces

> [accordion] 701: create namespace
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Create a namespace called `analytics` in this database, ready for new tables to be organized under it.
> ```

> [accordion] 702: create table in namespace
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Under the `staging` namespace of this database, create a table called `sessions` with columns `session_id` (string) and `duration_s` (float64), holding exactly these 2 rows:
>
> | session_id | duration_s |
> |------------|------------|
> | a1b2 | 12.5 |
> | c3d4 | 3.25 |
> ```

> [accordion] 703: list namespace tables
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> What tables live inside the `warehouse` namespace of this database? This is a read-only check. End your answer with one line per table, each of exactly this form:
>
> TABLE: <table_name>
> ```

> [accordion] 704: query namespace table
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Our SRE dashboards read from the `ops` namespace of this database, which holds a `latency` table of per-service p99 latency readings. Which service has the highest `p99_ms`, and what is that value? This is a read-only check. End your answer with two lines of exactly this form:
>
> SERVICE: <service_name>
> P99: <p99_ms value>
> ```

### Table branches

> [accordion] 801: create branch
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Create a branch called `experiment-reindex` on the `eval_create_branch` table, off its current state.
> ```

> [accordion] 802: switch branch and write
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Switch to the `wip-branch` branch of the `eval_switch_branch` table and add a description to its `category` column. The change should land on `wip-branch`, not on main.
> ```

> [accordion] 803: cherry pick branch
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> The `ready-to-cherry-pick` branch of the `eval_cherry_pick` table has been reviewed and approved. Cherry-pick it onto main so its changes land on the main table.
> ```

> [accordion] 804: delete branch
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> We no longer need the `stale-2024` branch on the `eval_delete_branch` table. Delete it.
> ```

### Background jobs

> [accordion] 901: list running jobs
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> What jobs are currently running against the `eval_job_list_{db}` table? Give each one's type and current state. This is a read-only check — do not cancel or modify anything. End your answer with one line per currently-running job, each of exactly this form (full job id, no truncation). Write `<job_type>` and `<current_state>` exactly as the API reports them, not as synonyms or prose — a compaction job that had failed would read `RUNNING: j1-xy-0ab-cdef | table_compaction | failed`:
>
> RUNNING: <job_id> | <job_type> | <current_state>
> ```

> [accordion] 902: describe job
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> An automated maintenance job was recently started against the `eval_job_describe_{db}` table. Find it and report what kind of job it is and its current status. Do not cancel or modify it. End your answer with lines of exactly these forms (full job id, no truncation). Write the type and state exactly as the API reports them, not as synonyms or prose — a compaction job that had failed would read `TYPE: table_compaction` and `STATE: failed`:
>
> JOB: <job_id>
> TYPE: <job_type>
> STATE: <current_state>
> ```

> [accordion] 903: cancel job
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> A cache-prewarm job against the `eval_job_cancel_{db}` table is hogging resources. Cancel it, and leave every other job alone. End your answer with a line of exactly this form (the full id of the job you cancelled, no truncation):
>
> CANCELLED: <job_id>
> ```

### Multi-step workflows

> [accordion] 1001: create embed search
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Set up a small semantic-search demo from scratch in this database. Create a new table called `eval_embed_search` with exactly three columns: `id` (int64), `text` (string), and `embedding` — a fixed-size vector of floats holding an embedding of `text`, computed with the `all-MiniLM-L6-v2` sentence-transformers model (embed each `text` exactly as written; use that same model for every row and for the query below). Populate it with exactly these 8 rows:
>
> | id | text |
> |----|------|
> | 1 | Espresso machine with a 15-bar pump for rich, crema-topped coffee |
> | 2 | Burr coffee grinder for fresh, evenly ground espresso beans |
> | 3 | Pour-over coffee kettle with a gooseneck spout for slow brewing |
> | 4 | Reusable coffee filter for drip brewers and pour-over cones |
> | 5 | Waterproof hiking boots for rocky mountain trails |
> | 6 | Lightweight hiking backpack with a hydration sleeve for day trails |
> | 7 | Trekking poles for steep mountain trail descents |
> | 8 | Merino wool hiking socks for long days on the trail |
>
> Then run two vector searches against the table, both using cosine distance: (1) a 'similar items' search using row 2's own stored embedding as the query, returning the 3 nearest OTHER rows; (2) a text search — embed the query `gear for a mountain hike` with the same model and return the 3 nearest rows. End your answer with two lines of exactly this form, ids comma-separated, nearest first:
>
> NEAREST: <id>,<id>,<id>
> QUERY_HITS: <id>,<id>,<id>
> ```

> [accordion] 1002: build all indexes
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> The `eval_index_all` table is about to back our product search page. The page will run: visual similarity search on the `image_clip_v2` embeddings (cosine distance), keyword search over `body_text`, exact-match filters on `category`, and range filters on `price_usd` — often combined with the searches. Today the table has no indexes at all. Build all the indexes this table will need to make search fast, and make sure every one of them finishes building. Don't build indexes the page won't use — each one costs build time and slows writes — and note that `image_clip_v1` is a legacy column nothing queries anymore. Do not modify the table's rows or schema.
> ```

> [accordion] 1003: embedding models in branches
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> We're choosing an embedding model for the `body_text` column of the `eval_embed_branches` table (24 product descriptions) and want to compare 3 candidates side by side without touching the production data. The candidates: `all-MiniLM-L6-v2`, `bge-small-en-v1.5`, and `gte-small`. Run the experiment on branches: for each candidate, create a branch of the table off main and, on that branch only, add a fixed-size float vector column called `body_embedding` holding that model's embedding of every row's `body_text` (embed the text exactly as stored). Then run the same search on each branch, using cosine distance — the 3 products most similar to the query `a paperback novel to read on the beach`, embedded with that branch's model — so we can compare what each model returns. Main must be left exactly as it is: no new column, no new rows, no other writes. End your answer with one line per branch, each of exactly this form (the model named the way its provider does, e.g. `all-MiniLM-L6-v2`; the three ids comma-separated, most similar first):
>
> BRANCH: <branch_name> | <embedding_model> | <id>,<id>,<id>
> ```

> [accordion] 1004: parquet to lance embed
>
> ```text theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> Convert this Parquet dataset to Lance and add a vector column from the description field. The dataset is `products.parquet` in your working directory. Load it into a new table called `eval_parquet_products` in this database, keeping every Parquet column and row exactly as they are, and add a column `description_embedding`: a fixed-size vector of floats holding an embedding of each row's `description`, computed with a text-embedding model of your choice (the same model for every row).
> ```


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.