Pgvector Semantic Search

Timescale (TigerData)OfficialCreated by tigerdataDistributed by Timescale (TigerData)

Skill
Tool integration
Data and AI
Apache-2.0
No issues found

From the author

Use this skill for setting up vector similarity search with pgvector for AI/ML embeddings, RAG applications, or semantic search. **Trigger when user asks to:** - Store or search vector embeddings in PostgreSQL - Set up semantic search, similarity search, or nearest neighbor search - Create HNSW or IVFFlat indexes for vectors - Implement RAG (Retrieval Augmented Generation) with PostgreSQL - Optimize pgvector performance, recall, or memory usage - Use binary quantization for large vector datasets **Keywords:** pgvector, embeddings, semantic search, vector similarity, HNSW, IVFFlat, halfvec, cosine distance, nearest neighbor, RAG, LLM, AI search Covers: halfvec storage, HNSW index configuration (m, ef_construction, ef_search), quantization strategies, filtered search, bulk loading, and performance tuning.

— the description by tigerdata

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a comprehensive guide for integrating pgvector into PostgreSQL to enable semantic search, RAG, and nearest neighbor lookups. It covers the full lifecycle of vector management, including storage optimization with halfvec, index selection (HNSW vs. IVFFlat), performance tuning, and handling filtered queries. The guide emphasizes best practices for maintaining high recall and low latency, including strategies for large-scale datasets through binary quantization and re-ranking.

What it does

Configures PostgreSQL for vector similarity search using the pgvector extension.
Implements HNSW indexing for optimal speed-recall trade-offs.
Optimizes storage and memory usage using halfvec and binary quantization.
Provides patterns for filtered vector search using iterative scans or partitioning.
Offers guidance on bulk loading data and index maintenance.
Includes diagnostic queries for monitoring index performance and recall.

When to use it

When building RAG applications that require vector storage within PostgreSQL.
When you need to perform semantic or nearest neighbor searches on high-dimensional embeddings.
When optimizing existing vector search performance for large datasets.
When managing memory constraints for large-scale vector indexes.
When implementing filtered search alongside vector similarity.

Advantages

Enables vector search directly within your existing database infrastructure.
Provides clear paths for scaling to millions of vectors.
Includes specific tuning parameters for balancing latency and recall.
Offers robust strategies for handling filtered queries without sacrificing accuracy.
Reduces storage footprint significantly using halfvec and binary quantization.

Usage examples

“How do I set up a table to store 1536-dimensional embeddings and index them for fast search?”: The agent provides the SQL to create a table using the halfvec(1536) data type and an HNSW index with recommended parameters (m=16, ef_construction=64).
“My filtered vector search is returning fewer results than expected. How do I fix this?”: The agent explains the HNSW early termination issue and guides you to enable iterative scans or use partitioning to ensure accurate results.
“I have a very large dataset and the HNSW index is exceeding my available RAM. What should I do?”: The agent suggests switching to binary quantization with re-ranking to reduce memory usage while maintaining acceptable search accuracy.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/timescale/pgvector-semantic-search/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip pgvector-semantic-search.zip -d .agents/skills

Documentation by tigerdata

pgvector for Semantic Search

Semantic search finds content by meaning rather than exact keywords. An embedding model converts text into high-dimensional vectors, where similar meanings map to nearby points. pgvector stores these vectors in PostgreSQL and uses approximate nearest neighbor (ANN) indexes to find the closest matches quickly—scaling to millions of rows without leaving the database. Store your text alongside its embedding, then query by converting your search text to a vector and returning the rows with the smallest distance.

This guide covers pgvector setup and tuning—not embedding model selection or text chunking, which significantly affect search quality. Requires pgvector 0.8.0+ for all features (halfvec, binary_quantize, iterative scan).

Golden Path (Default Setup)

Use this configuration unless you have a specific reason not to.

Embedding column data type: halfvec(N) where N is your embedding dimension (must match everywhere). Examples use 1536; replace with your dimension N.
Distance: cosine (<=>)
Index: HNSW (m = 16, ef_construction = 64). Use halfvec_cosine_ops and query with <=>.
Query-time recall: SET hnsw.ef_search = 100 (good starting point from published benchmarks, increase for higher recall at higher latency)
Query pattern: ORDER BY embedding <=> $1::halfvec(N) LIMIT k

This setup provides a strong speed–recall tradeoff for most text-embedding workloads.

Core Rules

Enable the extension in each database: CREATE EXTENSION IF NOT EXISTS vector;
Use HNSW indexes by default—superior speed-recall tradeoff, can be created on empty tables, no training step required. Only consider IVFFlat for write-heavy or memory-bound workloads.
Use halfvec by default—store and index as halfvec for 50% smaller storage and indexes with minimal recall loss.
Index after bulk loading initial data for best build performance.
Create indexes concurrently in production: CREATE INDEX CONCURRENTLY ...
Use cosine distance by default (<=>): For non-normalized embeddings, use cosine. For unit-normalized embeddings, cosine and inner product yield identical rankings; default to cosine.
Match query operator to index ops: Index with halfvec_cosine_ops requires <=> in queries; halfvec_l2_ops requires <->; mismatched operators won't use the index.
Always cast query vectors explicitly ($1::halfvec(N)) to avoid implicit-cast failures in prepared statements.
Always use the same embedding model for data and queries. Similarity search only works when the model generating the vectors is the same.

Type Rules

Store embeddings as halfvec(N)
Cast query vectors to halfvec(N)
Store binary quantized vectors as bit(N) in a generated column
Do not mix vector / halfvec / bit without explicit casts
Never call binary_quantize() on table columns inside ORDER BY; store it instead
Dimensions must match: a halfvec(1536) column requires query vectors cast as ::halfvec(1536).

Standard Pattern

-- Store and index as halfvec
CREATE TABLE items (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  contents TEXT NOT NULL,
  embedding halfvec(1536) NOT NULL  -- NOT NULL requires embeddings generated before insert, not async
);
CREATE INDEX ON items USING hnsw (embedding halfvec_cosine_ops);

-- Query: returns 10 closest items. $1 is the embedding of your search text.
SELECT id, contents FROM items ORDER BY embedding <=> $1::halfvec(1536) LIMIT 10;

For other distance operators (L2, inner product, etc.), see the pgvector README.

HNSW Index

The recommended index type. Creates a multilayer navigable graph with superior speed-recall tradeoff. Can be created on empty tables (no training step required).

CREATE INDEX ON items USING hnsw (embedding halfvec_cosine_ops);

-- With tuning parameters
CREATE INDEX ON items USING hnsw (embedding halfvec_cosine_ops) WITH (m = 16, ef_construction = 64);

HNSW Parameters

Parameter	Default	Description
`m`	16	Max connections per layer. Higher = better recall, more memory
`ef_construction`	64	Build-time candidate list. Higher = better graph quality, slower build
`hnsw.ef_search`	40	Query-time candidate list. Higher = better recall, slower queries. Should be ≥ LIMIT.

ef_search tuning (rough guidelines—actual results vary by dataset):

ef_search	Approx Recall	Relative Speed
40	lower (~95% on some benchmarks)	1x (baseline)
100	higher	~2x slower
200	very-high	~4x slower
400	near-exact	~8x slower

-- Set search parameter for session
SET hnsw.ef_search = 100;

-- Set for single query
BEGIN;
SET LOCAL hnsw.ef_search = 100;
SELECT id, contents FROM items ORDER BY embedding <=> $1::halfvec(1536) LIMIT 10;
COMMIT;

IVFFlat Index (Generally Not Recommended)

Default to HNSW. Use IVFFlat only when HNSW’s operational costs matter more than peak recall.

Choose IVFFlat if:

Write-heavy or constantly changing data AND you're willing to rebuild the index frequently
You rebuild indexes often and want predictable build time and memory usage
Memory is tight and you cannot keep an HNSW graph mostly resident
Data is partitioned or tiered, and this index lives on colder partitions

Avoid IVFFlat if you need:

highest recall at low latency
minimal tuning
a “set and forget” index

Notes:

IVFFlat requires data to exist before index creation.
Recall depends on lists and ivfflat.probes; higher probes = better recall, slower queries.

Starter config:

CREATE INDEX ON items
USING ivfflat (embedding halfvec_cosine_ops)
WITH (lists = 1000);

SET ivfflat.probes = 10;

Quantization Strategies

Quantization is a memory decision, not a recall decision.
Use halfvec by default for storage and indexing.
Estimate HNSW index footprint as ~4–6 KB per 1536-dim halfvec (m=16) (order-of-magnitude); 3072-dim is ~2×; m=32 roughly doubles HNSW link/graph overhead.
If p95/p99 latency rises while CPU is mostly idle, the HNSW index is likely no longer resident in memory.
If halfvec doesn’t fit, use binary quantization + re-ranking.

Guidelines for 1536-dim vectors

Approximate halfvec capacity at m=16, 1536-dim (assumes RAM mostly available for index caching):

RAM	Approx max halfvec vectors
16 GB	~2–3M vectors
32 GB	~4–6M vectors
64 GB	~8–12M vectors
128 GB	~16–25M vectors

For 3072-dim embeddings, divide these numbers by ~2.
For m=32, also divide capacity by ~2.

If the index cannot fit in memory at this scale, use binary quantization.

These are ranges, not guarantees. Validate by monitoring cache residency and p95/p99 latency under load.

Binary Quantization (For Very Large Datasets)

32× memory reduction. Use with re-ranking for acceptable recall.

-- Table with generated column for binary quantization
CREATE TABLE items (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  contents TEXT NOT NULL,
  embedding halfvec(1536) NOT NULL,
  embedding_bq bit(1536) GENERATED ALWAYS AS (binary_quantize(embedding)::bit(1536)) STORED
);

CREATE INDEX ON items USING hnsw (embedding_bq bit_hamming_ops);

-- Query with re-ranking for better recall
-- ef_search must be >= inner LIMIT to retrieve enough candidates
SET hnsw.ef_search = 800;
WITH q AS (
  SELECT binary_quantize($1::halfvec(1536))::bit(1536) AS qb
)
SELECT *
FROM (
  SELECT i.id, i.contents, i.embedding
  FROM items i, q
  ORDER BY i.embedding_bq <~> q.qb -- computes binary distance using index
  LIMIT 800
) candidates
ORDER BY candidates.embedding <=> $1::halfvec(1536) -- computes halfvec distance (no index), more accurate than binary
LIMIT 10;

The 80× oversampling ratio (800 candidates for 10 results) is a reasonable starting point. Binary quantization loses precision, so more candidates are needed to find true nearest neighbors during re-ranking. Increase if recall is insufficient; decrease if re-ranking latency is too high.

Performance by Dataset Size

Scale	Vectors	Config	Notes
Small	<100K	Defaults	Index optional but improves tail latency
Medium	100K–5M	Defaults	Monitor p95 latency; most common production range
Large	5M+	`ef_construction=100+`	Memory residency critical
Very Large	10M+	Binary quantization + re-ranking	Add RAM or partition first if possible

Tune ef_search first for recall; only increase m if recall plateaus and memory allows. Under concurrency, tail latency spikes when the index doesn't fit in memory. Binary quantization is an escape hatch—prefer adding RAM or partitioning first.

Filtering Best Practices

Filtered vector search requires care. Depending on filter selectivity and query shape, filters can cause early termination (too few rows, missing results) or increase work (latency).

Iterative scan (recommended when filters are selective)

By default, HNSW may stop early when a WHERE clause is present, which can lead to fewer results than expected. Iterative scan allows HNSW to continue searching until enough filtered rows are found.

Enable iterative scan when filters materially reduce the result set.

-- Enable iterative scans for filtered queries
SET hnsw.iterative_scan = relaxed_order;

SELECT id, contents
FROM items
WHERE category_id = 123
ORDER BY embedding <=> $1::halfvec(1536)
LIMIT 10;

If results are still sparse, increase the scan budget:

SET hnsw.max_scan_tuples = 50000;

Trade-off: increasing hnsw.max_scan_tuples improves recall but can significantly increase latency.

When iterative scan is not needed:

The filter matches a large portion of the table (low selectivity)
You are prefiltering via a B-tree index
You are querying a single partition or partial index

Choose the right filtering strategy

Highly selective filters (under ~10k rows) Use a B-tree index on the filter column so Postgres can prefilter before ANN.

CREATE INDEX ON items (category_id);

Low-cardinality filters (few distinct values) Use partial HNSW indexes per filter value.

CREATE INDEX ON items
USING hnsw (embedding halfvec_cosine_ops)
WHERE category_id = 11;

Many filter values or large datasets Partition by the filter key to keep each ANN index small.

CREATE TABLE items (
  embedding halfvec(1536),
  category_id int
) PARTITION BY LIST (category_id);

Key rules

Filters that match few rows require prefiltering, partitioning, or iterative scan.
Always validate filtered queries by measuring p95/p99 latency and tuples visited under realistic load.

Alternative: pgvectorscale for label-based filtering

For large datasets with label-based filters, pgvectorscale's StreamingDiskANN index supports filtered indexes on smallint[] columns. Labels are indexed alongside vectors, enabling efficient filtered search without the accuracy tradeoffs of HNSW post-filtering. See the pgvectorscale documentation for setup details.

Bulk Loading

-- COPY is fastest; binary format is faster but requires proper encoding
-- Text format: '[0.1, 0.2, ...]'
COPY items (contents, embedding) FROM STDIN;
-- Binary format (if your client supports it):
COPY items (contents, embedding) FROM STDIN WITH (FORMAT BINARY);

-- Add indexes AFTER loading
SET maintenance_work_mem = '4GB';
SET max_parallel_maintenance_workers = 7;
CREATE INDEX ON items USING hnsw (embedding halfvec_cosine_ops);

Maintenance

VACUUM regularly after updates/deletes—stale entries may persist until vacuumed
REINDEX if performance degrades after high churn (rebuilds the graph from scratch)
For write-heavy workloads with frequent deletes, consider IVFFlat or partitioning by time using hypertables

Monitoring & Debugging

-- Check index size
SELECT pg_size_pretty(pg_relation_size('items_embedding_idx'));

-- Debug query performance
EXPLAIN (ANALYZE, BUFFERS) SELECT id, contents FROM items ORDER BY embedding <=> $1::halfvec(1536) LIMIT 10;

-- Monitor index build progress
SELECT phase, round(100.0 * blocks_done / nullif(blocks_total, 0), 1) AS "%" 
FROM pg_stat_progress_create_index;

-- Compare approximate vs exact recall
BEGIN;
SET LOCAL enable_indexscan = off;  -- Force exact search
SELECT id, contents FROM items ORDER BY embedding <=> $1::halfvec(1536) LIMIT 10;
COMMIT;

-- Force index use for debugging
BEGIN;
SET LOCAL enable_seqscan = off;
SELECT id, contents FROM items ORDER BY embedding <=> $1::halfvec(1536) LIMIT 10;
COMMIT;

Common Issues (Symptom → Fix)

Symptom	Likely Cause	Fix
Query does not use ANN index	Missing `ORDER BY` + `LIMIT`, operator mismatch, or implicit casts	Use `ORDER BY` with a distance operator that matches the index ops class; explicitly cast query vectors
Fewer results than expected (filtered query)	HNSW stops early due to filter	Enable iterative scan; increase `hnsw.max_scan_tuples`; or prefilter (B-tree), use partial indexes, or partition
Fewer results than expected (unfiltered query)	ANN recall too low	Increase `hnsw.ef_search`
High latency with low CPU usage	HNSW index not resident in memory	Use `halfvec`, reduce `m`/`ef_construction`, add RAM, partition, or use binary quantization
Slow index builds	Insufficient build memory or parallelism	Increase `maintenance_work_mem` and `max_parallel_maintenance_workers`; build after bulk load
Out-of-memory errors	Index too large for available RAM	Use `halfvec`, reduce index parameters, or switch to binary quantization with re-ranking
Zero or missing results	NULL or zero vectors	Avoid NULL embeddings; do not use zero vectors with cosine distance

Files

ATTRIBUTION.mdAdded by AutoGineer987 B
LICENSELicence file added by AutoGineer9.4 KiB
NOTICELicence file added by AutoGineer573 B
SKILL.md14.8 KiB

LICENSE


                             Apache License
                       Version 2.0, January 2004
                    http://www.apache.org/licenses/

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

1. Definitions.

  "License" shall mean the terms and conditions for use, reproduction,
  and distribution as defined by Sections 1 through 9 of this document.

  "Licensor" shall mean the copyright owner or entity authorized by
  the copyright owner that is granting the License.

  "Legal Entity" shall mean the union of the acting entity and all
  other entities that control, are controlled by, or are under common
  control with that entity. For the purposes of this definition,
  "control" means (i) the power, direct or indirect, to cause the
  direction or management of such entity, whether by contract or
  otherwise, or (ii) ownership of fifty percent (50%) or more of the
  outstanding shares, or (iii) beneficial ownership of such entity.

  "You" (or "Your") shall mean an individual or Legal Entity
  exercising permissions granted by this License.

  "Source" form shall mean the preferred form for making modifications,
  including but not limited to software source code, documentation
  source, and configuration files.

  "Object" form shall mean any form resulting from mechanical
  transformation or translation of a Source form, including but
  not limited to compiled object code, generated documentation,
  and conversions to other media types.

  "Work" shall mean the work of authorship, whether in Source or
  Object form, made available under the License, as indicated by a
  copyright notice that is included in or attached to the work
  (an example is provided in the Appendix below).

  "Derivative Works" shall mean any work, whether in Source or Object
  form, that is based on (or derived from) the Work and for which the
  editorial revisions, annotations, elaborations, or other modifications
  represent, as a whole, an original work of authorship. For the purposes
  of this License, Derivative Works shall not include works that remain
  separable from, or merely link (or bind by name) to the interfaces of,
  the Work and Derivative Works thereof.

  "Contribution" shall mean any work of authorship, including
  the original version of the Work and any modifications or additions
  to that Work or Derivative Works thereof, that is intentionally
  submitted to Licensor for inclusion in the Work by the copyright owner
  or by an individual or Legal Entity authorized to submit on behalf of
  the copyright owner. For the purposes of this definition, "submitted"
  means any form of electronic, verbal, or written communication sent
  to the Licensor or its representatives, including but not limited to
  communication on electronic mailing lists, source code control systems,
  and issue tracking systems that are managed by, or on behalf of, the
  Licensor for the purpose of discussing and improving the Work, but
  excluding communication that is conspicuously marked or otherwise
  designated in writing by the copyright owner as "Not a Contribution."

  "Contributor" shall mean Licensor and any individual or Legal Entity
  on behalf of whom a Contribution has been received by Licensor and
  subsequently incorporated within the Work.

2. Grant of Copyright License. Subject to the terms and conditions of
  this License, each Contributor hereby grants to You a perpetual,
  worldwide, non-exclusive, no-charge, royalty-free, irrevocable
  copyright license to reproduce, prepare Derivative Works of,
  publicly display, publicly perform, sublicense, and distribute the
  Work and such Derivative Works in Source or Object form.

3. Grant of Patent License. Subject to the terms and conditions of
  this License, each Contributor hereby grants to You a perpetual,
  worldwide, non-exclusive, no-charge, royalty-free, irrevocable
  (except as stated in this section) patent license to make, have made,
  use, offer to sell, sell, import, and otherwise transfer the Work,
  where such license applies only to those patent claims licensable
  by such Contributor that are necessarily infringed by their
  Contribution(s) alone or by combination of their Contribution(s)
  with the Work to which such Contribution(s) was submitted. If You
  institute patent litigation against any entity (including a
  cross-claim or counterclaim in a lawsuit) alleging that the Work
  or a Contribution incorporated within the Work constitutes direct
  or contributory patent infringement, then any patent licenses
  granted to You under this License for that Work shall terminate
  as of the date such litigation is filed.

4. Redistribution. You may reproduce and distribute copies of the
  Work or Derivative Works thereof in any medium, with or without
  modifications, and in Source or Object form, provided that You
  meet the following conditions:

  (a) You must give any other recipients of the Work or
      Derivative Works a copy of this License; and

  (b) You must cause any modified files to carry prominent notices
      stating that You changed the files; and

  (c) You must retain, in the Source form of any Derivative Works
      that You distribute, all copyright, patent, trademark, and
      attribution notices from the Source form of the Work,
      excluding those notices that do not pertain to any part of
      the Derivative Works; and

  (d) If the Work includes a "NOTICE" text file as part of its
      distribution, then any Derivative Works that You distribute must
      include a readable copy of the attribution notices contained
      within such NOTICE file, excluding those notices that do not
      pertain to any part of the Derivative Works, in at least one
      of the following places: within a NOTICE text file distributed
      as part of the Derivative Works; within the Source form or
      documentation, if provided along with the Derivative Works; or,
      within a display generated by the Derivative Works, if and
      wherever such third-party notices normally appear. The contents
      of the NOTICE file are for informational purposes only and
      do not modify the License. You may add Your own attribution
      notices within Derivative Works that You distribute, alongside
      or as an addendum to the NOTICE text from the Work, provided
      that such additional attribution notices cannot be construed
      as modifying the License.

  You may add Your own copyright statement to Your modifications and
  may provide additional or different license terms and conditions
  for use, reproduction, or distribution of Your modifications, or
  for any such Derivative Works as a whole, provided Your use,
  reproduction, and distribution of the Work otherwise complies with
  the conditions stated in this License.

5. Submission of Contributions. Unless You explicitly state otherwise,
  any Contribution intentionally submitted for inclusion in the Work
  by You to the Licensor shall be under the terms and conditions of
  this License, without any additional terms or conditions.
  Notwithstanding the above, nothing herein shall supersede or modify
  the terms of any separate license agreement you may have executed
  with Licensor regarding such Contributions.

6. Trademarks. This License does not grant permission to use the trade
  names, trademarks, service marks, or product names of the Licensor,
  except as required for reasonable and customary use in describing the
  origin of the Work and reproducing the content of the NOTICE file.

7. Disclaimer of Warranty. Unless required by applicable law or
  agreed to in writing, Licensor provides the Work (and each
  Contributor provides its Contributions) on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
  implied, including, without limitation, any warranties or conditions
  of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
  PARTICULAR PURPOSE. You are solely responsible for determining the
  appropriateness of using or redistributing the Work and assume any
  risks associated with Your exercise of permissions under this License.

8. Limitation of Liability. In no event and under no legal theory,
  whether in tort (including negligence), contract, or otherwise,
  unless required by applicable law (such as deliberate and grossly
  negligent acts) or agreed to in writing, shall any Contributor be
  liable to You for damages, including any direct, indirect, special,
  incidental, or consequential damages of any character arising as a
  result of this License or out of the use or inability to use the
  Work (including but not limited to damages for loss of goodwill,
  work stoppage, computer failure or malfunction, or any and all
  other commercial damages or losses), even if such Contributor
  has been advised of the possibility of such damages.

9. Accepting Warranty or Additional Liability. While redistributing
  the Work or Derivative Works thereof, You may choose to offer,
  and charge a fee for, acceptance of support, warranty, indemnity,
  or other liability obligations and/or rights consistent with this
  License. However, in accepting such obligations, You may act only
  on Your own behalf and on Your sole responsibility, not on behalf
  of any other Contributor, and only if You agree to indemnify,
  defend, and hold each Contributor harmless for any liability
  incurred by, or claims asserted against, such Contributor by reason
  of your accepting any such warranty or additional liability.

END OF TERMS AND CONDITIONS

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

The author says: Requires PostgreSQL 15+ with the pgvector extension

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by

tigerdata

Publisher

Timescale (TigerData) (Official)

Distributed by

Timescale (TigerData)

Source

timescale/pg-aiguide · skills/pgvector-semantic-search · commit c39008a

Licence

Apache License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
NOTICE (added by AutoGineer from NOTICE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

AutoGineer is not affiliated with or endorsed by tigerdata or Timescale (TigerData).

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download pgvector-semantic-search.zip