docs: document pgvector's 2000-dim HNSW limit for embedding config#902
docs: document pgvector's 2000-dim HNSW limit for embedding config#902LazyEngineer99 wants to merge 2 commits into
Conversation
VECTOR_DIMENSIONS has no upper-bound validation at config-load time, so a model that defaults to higher output dimensions than pgvector's HNSW index supports (e.g. Gemini's gemini-embedding-001, which defaults to 3072) will only fail later, at index creation, with no indication of why. Document the limit next to VECTOR_DIMENSIONS in config.toml.example and in the README's config section list, which was also missing a dedicated [embedding] entry (it was folded into [app]'s description, but [app] has no embedding-related keys).
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughConfiguration documentation separates embedding settings from the app section and documents the ChangesEmbedding dimension documentation
Estimated code review effort: 1 (Trivial) | ~2 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@config.toml.example`:
- Around line 70-72: Revise the VECTOR_DIMENSIONS comment in the configuration
example to state that values above 2000 may be rejected during startup
configuration validation or by pgvector during index creation, rather than
implying pgvector is the only failure point.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 2e03fd38-959c-459c-89c6-d475e4d4e1c7
📒 Files selected for processing (2)
README.mdconfig.toml.example
CodeRabbit review on plastic-labs#902 correctly pointed out that src/startup/embedding_validator.py can also catch a VECTOR_DIMENSIONS mismatch at boot (by comparing against the existing pgvector column), before ever reaching index creation. The original comment implied pgvector was the only place this fails.
What
VECTOR_DIMENSIONShas no upper-bound validation at config-load time. Someembedding models default to output dimensions higher than pgvector's HNSW
index hard limit (2000) — e.g. Gemini's
gemini-embedding-001defaults to3072. If you switch to such a model without explicitly setting
VECTOR_DIMENSIONSto a supported value, the failure only shows up later,at index creation, with no indication of why.
This documents the limit directly next to
VECTOR_DIMENSIONSinconfig.toml.example, and adds a dedicated[embedding]entry to theREADME's config section list (it was previously folded into
[app]'sdescription, but
[app]has no embedding-related keys — that line wasstale).
Why
Ran into this directly running a self-hosted instance with Gemini as the
embedding provider — nothing in the docs or code warns about the 2000-dim
ceiling before you hit it.
Testing
config.toml.examplestill loads correctly against the realAppSettingspydantic schema (docker run ... python3 -c "from src.config import settings; ...").README.mdpassesmarkdownlint-cli2clean.Summary by CodeRabbit