Skip to content

Announcing VectorsDB: Similarity search as a first-class Appwrite database_

Store embeddings, generate them from text with built-in models, and rank documents by similarity without adding a separate vector service to your stack.

Semantic search, recommendations, and retrieval for AI features all reduce to the same primitive: store vectors, then find the ones closest to a query. Until now, that primitive usually meant adding a dedicated vector service to your stack, with its own hosting, its own client, and its own auth model to reconcile with the rest of your backend.

Today we are announcing VectorsDB, which makes that primitive a first-class Appwrite database.

Create your first database

In your project, go to Databases, click Create database, and choose VectorsDB as the type. Pick a compute specification, then create your first collection with the dimension your embedding model produces. From there, every document you write is a vector ready to be searched.

A schema designed for vectors

Where other Appwrite databases let you define your own fields, a VectorsDB collection has a deliberate, fixed shape. You create it with a dimension, and every document carries two things:

  • embeddings: a vector of exactly that length
  • metadata: optional JSON for whatever belongs alongside the vector, such as the source text, a URL, or labels

That constraint is the feature. The collection always knows what a valid vector looks like, and the HNSW index built on embeddings keeps search fast as your data grows.

Built-in embedding generation

VectorsDB can generate text embeddings with built-in models. You pass a string, and Appwrite turns it into a vector you can store directly, so a working semantic search does not require standing up an embedding service or wiring a third-party API into your ingest path. If you already have embeddings from your own models, store those instead.

Searching is a two-step flow. First, turn the search text into a vector, either with your own model or with the built-in embedding generation:

Then pass that vector as a query to the same listDocuments method used across Appwrite Databases. Choose the metric when you create the index, cosine, dot product, or Euclidean distance, and query with the matching method. The vectors below are shortened for readability; in practice you pass the embedding returned by the step above:

Results come back as documents ranked from most to least similar, with their metadata attached, ready to render.

Shared Appwrite Databases capabilities

VectorsDB shares the platform capabilities available across Appwrite Databases:

  • Permissions control access at the document level, so clients can search safely.
  • Queries, pagination, and ordering work alongside vector queries.
  • Transactions group writes so related changes succeed or fail together.
  • Bulk operations ingest large embedding sets in one request.
  • CSV imports and exports move vectors and metadata in and out.
  • Backups protect your collections with scheduled and manual snapshots.

Your vectors live next to the rest of your application data, behind the same SDKs and the same access control, instead of in a service on the side.

Every VectorsDB database is provisioned for your project with a compute specification you choose at creation, so search performance scales with the tier you pick. The available tiers and their prices are listed on the pricing page.

Get started

VectorsDB is available on Appwrite Cloud today. Create a database, choose VectorsDB as the type, pick a dimension, and you can run your first similarity search in minutes.

Read next

Appwrite now speaks Postgres

Jake Barnby

Run a managed PostgreSQL instance inside your Appwrite project and connect to it with psql, your ORM, and the entire PostgreSQL ecosystem.

6 min read

Ready to build?_