Is the VECTOR column type officially supported in Forge SQL?

Forge Forge Platform and Tools
, ,
1

Hi all,

Is the VECTOR column type officially supported in Forge SQL, and is it safe to build on? In the same context

  1. Are vector indexes available, so similarity search stays fast on larger tables, or does each search scan every row?
  2. Are there any limits specific to vector columns, beyond the general Forge SQL storage limits?

While browsing the community threads, I found this post, which demonstrates that TiDB’s vector features work with Forge SQL, with embeddings stored in a VECTOR column. However, I couldn’t find this in the Forge SQL documentation, so It worths checking whether it’s officially supported or could change

Knowing this would help us decide whether to build on it. Thanks!

2

Hi ziadalharash,

Regarding vector indexes: unfortunately, they are not available in Forge SQL at the moment.

TiDB’s vector search indexes (HNSW) rely on TiFlash replicas. According to the TiDB documentation, the vector search index feature requires TiFlash. Since TiFlash is not available in Forge SQL, HNSW vector indexes cannot currently be used there.

The example from my post therefore performs exact vector similarity search without a vector index.

One important detail is that Forge SQL data is isolated per tenant. This means the full scan is limited to the data of a single tenant rather than all installations of the app. For many tenants this may be perfectly acceptable, while tenants with significantly larger vector datasets could eventually experience performance degradation.

This is something that can be detected rather than guessed upfront. For example, using the SQL observability approach I described in my other post, we can track database execution time per resolver/tenant and identify when vector search starts becoming expensive. Slow queries can then be investigated further using their execution plans.

If this becomes a problem for a particular workload, the next step would be to reduce the candidate set before applying vector similarity - for example, by logically partitioning the searchable data or introducing additional application-level filtering instead of running VEC_COSINE_DISTANCE() against every vector in the tenant’s table.

I also created a Forge feature request for this:

FRGE-2141 — Native Vector Search Support in Forge SQL

The goal is to have native vector functionality officially supported and documented by Atlassian, so developers can rely on it rather than depending on an undocumented capability of the underlying TiDB implementation.

So, at the moment, I would summarize it as:

  • VECTOR columns - work in Forge SQL
  • VEC_COSINE_DISTANCE() / vector similarity functions - work
  • Vector indexes - not available because they depend on TiFlash
  • Official Forge SQL support/guarantees for vector functionality - this is what still needs clarification from Atlassian

Hopefully Atlassian can clarify the support status here, especially whether the currently working vector functionality can be safely relied upon for production apps.

3

Vector search, datatypes and functions are currently in preview and not supported for production workloads. Forge SQL does not support vector until the underlying database provider supports it for production use cases.

We don’t have any concrete timelines that we can share at the moment, unfortunately.

4

@vzakharchenko This is really helpful, thanks for taking the time to validate and share.

We tried VECTOR and VEC_COSINE_DISTANCE on a small dataset and indeed, both worked as expected, without indexing ofc.

@varun Good to know about the preview status, thanks for sharing.

So until official support and documentation, it seems the most practical RoA compliant path for semantic search and RAG seems to be by storing embeddings in a BLOB column, handling cosine similarity in app code, and running the embedding model within a Forge function.

Looking forward to native vector support (and +1 on FRGE-2141 — Native Vector Search Support in Forge SQL).