dodil k3 vector store

Per-bucket vector engine lifecycle. Four subcommands — create, get, delete, list-instances. Configure once at bucket setup time; rarely touched afterwards.

Persistent flag on the whole group: --bucket / -b (required for create / get / delete; ignored for list-instances).

dodil k3 vector store create

dodil k3 vector store create -b BUCKET [-m MODE]

Configures the bucket’s vector engine. auto (default) provisions a fresh VBase database for you; external points at your own VBase cluster.

# Auto mode — K3 handles VBase provisioning
dodil k3 vector store create -b kb-prod
 
# External mode flag (see CLI gap below)
dodil k3 vector store create -b kb-prod -m external

External mode is a CLI gap today. The --mode external flag is accepted, but the CLI doesn’t expose the required follow-on flags (vbase_endpoint, vbase_port, vbase_db_name). For external mode, use the API directly — see API Reference → ConfigureEngine.

pick mode (reuse an existing VBase service) is not in the CLI at all. Use the API.

After create, poll get until status reaches ENGINE_STATUS_ACTIVE — typically under a minute for auto mode.

dodil k3 vector store get

dodil k3 vector store get -b BUCKET

Returns the engine row — status, mode, VBase connection info, and the bucket’s collections inline.

dodil k3 vector store get -b kb-prod -o json \
  | jq '{status, mode, vbaseEndpoint, vbaseDbName, collectionCount: (.collections | length)}'

Status path on a fresh create:

PENDING ─► PROVISIONING ─► ACTIVE
                          │
                          ▼  on provisioning failure
                        ERROR    (error_message populated)

ACTIVE is the steady state — collections + search operate against this engine.

dodil k3 vector store delete

dodil k3 vector store delete -b BUCKET

Removes K3’s engine row + the bucket’s VBase connection config. Does NOT drop the underlying VBase database (auto-mode only) — the database persists for re-attach.

dodil k3 vector store delete -b kb-prod

--delete-database flag is a CLI gap. The API supports delete_database: true to also drop the VBase database (auto mode only) — the CLI doesn’t expose it. For a full teardown via CLI today, delete the engine here, then drop the VBase database directly via VBase . Or use the API:

curl -sS -X DELETE "https://k3.dev.dodil.io/kb-prod/vector" \
  -H "Authorization: Bearer $DODIL_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"bucket":"kb-prod","deleteDatabase":true}'

Does NOT cascade to collections or to Scriptum pipelines / ingest rules bound to pipeline-mode collections in this bucket — those persist and reference an orphaned engine. Clean them up separately if you want a clean reset.

dodil k3 vector store list-instances

dodil k3 vector store list-instances

Lists the VBase services available to the org. Useful for picking an existing service when configuring engines in pick mode (via the API).

dodil k3 vector store list-instances -o json \
  | jq '.instances[] | {serviceId, name, status, serviceType}'

--bucket is inherited from the parent group but ignored by list-instances — the call is org-scoped. You can omit -b.

Sample output:

{
  "serviceId": "vb_svc_a1b2...",
  "name": "prod-cluster-us-east-1",
  "status": "running",
  "serviceType": "cluster"
}

The serviceId is what you’d pass to ConfigureEngine with mode: "pick".

Common gotchas

See also

• Engine — API Reference — full surface incl. external + pick mode configuration and delete_database
• Core Concepts → Engine — type signature + three-modes table
• VBase  — the underlying managed-Milvus product
• dodil k3 vector collection — what you create once the engine is ACTIVE