# Vector Store metadata

ODD recognises **vector-typed datasets** as a first-class entity in the catalog — a dedicated dataset type plus a dedicated column data type — so vector tables (Postgres `pgvector`, dedicated vector databases) sit alongside relational tables in search, lineage, and ownership without bespoke handling.

The platform ships two complementary additions for vector data:

## Dataset type — `Vector Store`

The platform exposes a dedicated dataset type literal — `Vector Store` — that an adapter can emit when the source is a vector-oriented store. Vector Stores show up on Catalog search facets, the [Directory](/features/data-discovery/directory.md), and entity lists with a Vector-Store icon distinct from regular Datasets.

<figure><img src="/files/3utWiNZWFSaXmXr1khCI" alt=""><figcaption><p>A Vector Store recognised in the ODD catalog</p></figcaption></figure>

The classification is a strong signal for operators: a Vector Store row in the catalog is the same primitive as a relational dataset (it has fields, owners, tags, lineage edges) but the workload it serves is different (similarity search, retrieval-augmented generation, embeddings storage), and surfacing the type makes it explicit.

## Column data type — `Vector`

Each column on a dataset carries a data type. The platform's data-type taxonomy includes `Vector` as a recognised primitive — adapters that ingest a column declared as a vector type (e.g., `pgvector`'s `vector(N)` column type) emit it as `Vector` rather than as a generic Array or Unknown type. The Structure tab renders `Vector` columns explicitly, and downstream surfaces (lineage, schema diff, search filtering by data type) recognise them.

<figure><img src="/files/J2KuY51XOEDNI5pDIndu" alt=""><figcaption><p>A Vector-typed column on a dataset's Structure tab</p></figcaption></figure>

## Specification source

Both additions — the `Vector Store` dataset type and the `Vector` column data type — are defined in the [opendatadiscovery-specification](https://github.com/opendatadiscovery/opendatadiscovery-specification/blob/main/specification/entities.yaml) repo's `entities.yaml`. Adapters speak the specification and emit either type when applicable; the platform ingests whatever the adapter declares.

## Adapter coverage

The first adapter to surface vector cataloguing was the **PostgreSQL adapter** in [`odd-collector`](/integrations/integrations/odd-collector.md). When the adapter encounters a PostgreSQL table containing at least one column with a `vector` data type (`pgvector` extension), it classifies the table as `Vector Store` during ingestion.

Other adapters that ingest vector-storing systems can emit the same dataset type by following the specification. Coverage grows as more adapters add vector recognition; consult per-adapter pages under [Integrations](/integrations/integrations.md) for the latest matrix.

## Where to next

* [Search and Filtering](/features/data-discovery/search.md) — Vector Stores surface on the Type facet (multi-select on the entity-class tab strip).
* [Data Objects Lineage](/features/data-lineage/data-objects.md) — Vector Stores participate in lineage like any other dataset class.
* [`odd-collector`](/integrations/integrations/odd-collector.md) — the canonical pull collector with the PostgreSQL `pgvector` recognition built in.
* [opendatadiscovery-specification](https://github.com/opendatadiscovery/opendatadiscovery-specification/blob/main/specification/entities.yaml) — the specification source for the `Vector Store` dataset type and the `Vector` column data type.
* [Data Discovery overview](/features/data-discovery.md) — the bucket landing this page sits under.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.opendatadiscovery.org/features/data-discovery/vector-stores.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.