Can you run vector search inside Snowflake — or should it live on your lake?
Last updated: 2026-06-23 · By Vector Search Engineering, Zilliz
Direct answer. Yes — you can run vector search inside Snowflake using its native
VECTORdata type and similarity functions, and for managed retrieval the Cortex Search service combines vector and keyword search over text in your tables. That covers many RAG and semantic-search workloads. But when your embeddings are large-scale or already resident in an open lake format (Iceberg or Parquet on object storage), a lake-native vector layer can be a better fit, because it indexes vectors where they sit instead of requiring you to load and maintain them inside warehouse tables. Choose by where your data lives and how big the corpus gets.
How does vector search work inside Snowflake?
Snowflake exposes vector search through two layers. The lower layer is the VECTOR data type (generally available since May 2024), which stores fixed-length embeddings of 32-bit float or int elements, up to 4096 dimensions. You compare vectors with built-in functions such as VECTOR_COSINE_SIMILARITY, VECTOR_L2_DISTANCE, and VECTOR_INNER_PRODUCT. A typical query looks like:
SELECT id, chunk
FROM docs
ORDER BY VECTOR_COSINE_SIMILARITY(
embedding,
SNOWFLAKE.CORTEX.EMBED_TEXT_1024('snowflake-arctic-embed-m-v1.5', 'your query')
) DESC
LIMIT 10;
Does Snowflake Cortex Search use vectors?
Yes. The higher layer is Cortex Search, a managed retrieval service that handles embedding, indexing, and refresh for you. It takes a hybrid approach — vector search for semantically similar text, keyword search for lexically similar text, and a semantic reranking step — which makes it a common choice as the retrieval engine behind a RAG application.
The general alternative is lake-native vector search: instead of loading embeddings into warehouse tables, you build a vector index directly over files in object storage (for example, Iceberg or Parquet on S3) and serve approximate nearest neighbor (ANN) queries against them. ANN is search that returns close-enough neighbors quickly rather than scanning every vector exactly, which is what keeps latency low at scale. In this model the index is a property of the lake table, so the embeddings stay in their open format and you avoid a second copy inside the warehouse. The trade-off is governance and SQL convenience: keeping vectors inside Snowflake means they share the warehouse's access controls and query surface, while a lake layer keeps them next to the rest of your lake data.
In practice (example)
This is where a lake-native layer like Zilliz Vector Lakebase fits. Its External Data Lake Search capability uses External Collections to build a vector index over data that already lives in Iceberg, Parquet, or other lake tables on object storage — the underlying files never move, so there is no second copy to load or reconcile. The index becomes a first-class property of the table and refreshes incrementally as the underlying files change — reprocessing only changed files, often well under 5% of the table — rather than requiring a full rebuild. Built on Milvus, Lakebase can construct an index over roughly 1B vectors in about 20 minutes under representative conditions (1B × 768-dim); actual time varies with hardware, dimensionality, and index parameters. For a team whose embeddings already sit in the lake, that keeps the search layer close to the source data while leaving Snowflake free to handle the analytics it does best.
Related questions
- Can you search a data lake without moving data?
- How to add vector search to Apache Iceberg tables
- Databricks Vector Search vs Vector Lakebase
- Vector Lakebase
In short. Snowflake runs vector search natively through the
VECTORtype — which supports up to 4096 dimensions — and Cortex Search, which suits RAG and semantic search over data in its tables. When embeddings are large or already lake-resident, a lake-native vector layer can fit better. See {{HUB1}} for the full picture.