VectorsDB_

Manage Appwrite VectorsDB databases, collections, indexes, and embeddings with the official Terraform provider.

3 min read

VectorsDB stores embeddings in collections and searches them by vector similarity. Its Terraform resources mirror DocumentsDB, since the two products share one implementation. One difference matters. A VectorsDB collection has a required dimension and takes no typed attributes.

For full generated schemas, see the Terraform Registry: vectorsdb, vectorsdb_collection, vectorsdb_index, and vectorsdb_document.

Resources

Resource	Purpose
`appwrite_vectorsdb`	Create a VectorsDB database in your project
`appwrite_vectorsdb_collection`	Create a collection of fixed-dimension embeddings
`appwrite_vectorsdb_index`	Index one or more document attributes
`appwrite_vectorsdb_document`	Manage seed and reference embeddings

Data sources

Data source	Purpose
`appwrite_vectorsdb`	Look up a database by ID
`appwrite_vectorsdb_specifications`	List the compute specifications your billing plan allows

VectorsDB has its own API key scopes

VectorsDB does not use the TablesDB scopes (tables.*, rows.*) or the deprecated collections.* and documents.* ones. Give the key vectorsdb.read and vectorsdb.write for databases, vectorsdb.collections.read and vectorsdb.collections.write for collections and indexes, and vectorsdb.documents.read and vectorsdb.documents.write for documents.

Creating a database

Terraform

resource "appwrite_vectorsdb" "main" {
  name = "embeddings"
}

Setting specification places the database on dedicated infrastructure reserved for your project, which is billed separately. Size it from the VectorsDB catalog, since each product publishes its own:

Terraform

data "appwrite_vectorsdb_specifications" "available" {}

output "available_specifications" {
  value = [
    for s in data.appwrite_vectorsdb_specifications.available.specifications :
    { slug = s.slug, cpu = s.cpu, memory = s.memory, price = s.price }
    if s.enabled
  ]
}

resource "appwrite_vectorsdb" "production" {
  name          = "embeddings"
  specification = "s-2vcpu-4gb"
  replicas      = 1
  sync_mode     = "sync"
}

Set the slug you want rather than deriving one from the catalog output. For a precondition that fails the plan when a slug is not enabled on your billing plan, see asserting a specification at plan time.

Some deployments require a specification

Omitting specification runs the database on the deployment's shared pool. Not every deployment has one configured. Where none is, the API rejects creation with dedicated_database_required, and specification becomes required.

replicas does not count the primary, and sync_mode (async, sync, or quorum) applies only when replicas is greater than 0. Creating a database with a dedicated backing waits for that backing to finish provisioning. Read-only attributes report type, engine, status, created_at, and updated_at. engine and status are empty when there is no dedicated backing.

Collections

dimension is required and must match the model producing your embeddings. text-embedding-3-small emits 1536 values, for example. Changing it later re-indexes the collection.

Terraform

resource "appwrite_vectorsdb_collection" "articles" {
  database_id = appwrite_vectorsdb.main.id
  id          = "article-embeddings"
  name        = "Article embeddings"
  dimension   = 1536

  permissions       = ["read(\"any\")"]
  document_security = true
}

VectorsDB collections take no typed attribute definitions. attributes is read-only here, and exists so both products share one state shape. In the other direction, the provider rejects dimension at plan time on a DocumentsDB collection.

Indexes

Terraform

resource "appwrite_vectorsdb_index" "by_source" {
  database_id   = appwrite_vectorsdb.main.id
  collection_id = appwrite_vectorsdb_collection.articles.id
  key           = "by_source"
  type          = "key"
  attributes    = ["source_id"]
}

orders (ASC or DESC) and lengths are positional, matching attributes entry for entry. Indexes have no update route, so changing any argument replaces the index. Terraform waits for a new index to become available, and status reports available, processing, deleting, stuck, or failed.

Documents

A VectorsDB document carries its embedding, which must have exactly the collection's dimension values.

Terraform

resource "appwrite_vectorsdb_collection" "toy" {
  database_id = appwrite_vectorsdb.main.id
  name        = "Toy embeddings"
  dimension   = 4
}

resource "appwrite_vectorsdb_document" "seed" {
  database_id   = appwrite_vectorsdb.main.id
  collection_id = appwrite_vectorsdb_collection.toy.id
  id            = "seed"

  data = jsonencode({
    embedding = [0.1, 0.2, 0.3, 0.4]
    source_id = "article-1"
  })
}

Embeddings come from a model, so your application normally writes them rather than pinning them in configuration. Keep this resource for seed and reference records. Terraform tracks only the keys present in data, so fields written by other clients do not show as drift.

Looking up a database

Terraform

data "appwrite_vectorsdb" "existing" {
  id = "embeddings"
}

resource "appwrite_vectorsdb_collection" "example" {
  database_id = data.appwrite_vectorsdb.existing.id
  name        = "Example"
  dimension   = 1536
}

Importing

Bash

terraform import appwrite_vectorsdb.main <database-id>
terraform import appwrite_vectorsdb_collection.articles <database-id>/<collection-id>
terraform import appwrite_vectorsdb_index.by_source <database-id>/<collection-id>/<key>
terraform import appwrite_vectorsdb_document.seed <database-id>/<collection-id>/<document-id>

DocumentsDB: the same shape, for schemaless JSON
Dedicated databases: PostgreSQL, MySQL, and MongoDB
TablesDB: the relational product on shared infrastructure
Configuration: authentication and endpoints

Was this page helpful?

Share what worked or what we should fix. Once approved, our agents automatically apply suggested updates to the docs.