Feature Request: Native pgvector Support in Directus

[AppaNexus]

Summary

Add native support for pgvector columns within Directus, allowing users to manage vector data (e.g. embeddings) directly in the admin UI without resorting to workarounds.

Basic Example

A new “Field Type” called Vector in Directus that recognizes a PostgreSQL column defined as vector(...). Users could input and view the vector as an array (e.g., [0.123, -0.456, 0.789]) in the Directus UI. Under the hood, Directus would correctly store and retrieve data from the vector column.

Motivation

Many AI/ML applications rely on embeddings stored as pgvector columns for semantic searches and vector operations. Currently, Directus does not offer native handling of these columns, forcing users to rely on workarounds—such as storing text “mirrors” of the vector or using external tools to manage embeddings. Native support would streamline workflows and enhance Directus’s value in modern data-driven applications.

Detailed Design

1 Field Type Definition: Create a new field type “Vector,” similar to existing numeric or JSON fields.
2 Data Entry: Allow users to edit vectors in an array-like format or raw text area.
3 Validation: Optionally validate the dimension size (e.g., vector(1536)).
4 Display: Provide a minimal read/write UI that shows the vector data as an array of floats.
5 API Representation: When retrieving or sending data through the Directus REST/GraphQL APIs, maintain the array format or another standardized representation.
6 Compatibility: Ensure that existing features like filters or sorting remain unaffected if the user does not select to do so.

Requirements List

Must Have

A new Directus field type that recognizes vector columns in PostgreSQL
Ability to view the vector in a read-only or basic editable format

Should Have

Validation for expected vector dimension length (e.g., 1536 for certain embeddings)
Friendly UI for adding/removing elements in the array

Could Have

Integration with Directus permissions (e.g., restricting editing of certain fields)
Automatic detection of dimension from the database schema

Drawbacks

• Implementation complexity: introducing a new custom field type might require updates to Directus’s internal schema detection and UI.
• Maintenance cost: ensuring compatibility with future Postgres/pgvector releases.
• Edge cases: not all users need vector data, so it might complicate the UI for some.

Alternatives

• Continue using a “text mirror” column to store a string representation of the vector.
• Develop a purely external solution (scripts, custom endpoints) to handle pgvector data.
• Use a separate table or JSON column, then convert to/from vector in raw SQL.

Adoption Strategy

• This feature would be opt-in: only users who explicitly select the “Vector” field type would see or edit vector data.
• Existing Directus applications will continue to function without changes unless they adopt the new type.
• Minimal risk for breaking changes if implemented behind a feature flag or optional module.

Unresolved Questions

• Should the field offer a specialized UI for large vectors (e.g., 1536+ elements)?
• Is real-time validation needed for dimension length or data type?
• Do we want to support advanced operations, like similarity search, directly from the Directus UI?