Key facts
| API compatibility | OpenAI-shaped /v1/embeddings and /v1/chat/completions (live) |
| Embeddings | plugsky-embed and plugsky-embed-multilingual (live) |
| Migration | Base URL and model names; re-embed the corpus once |
| Vector stores | Any store that accepts float vectors, including pgvector |
| Answer layer | Optional cited answers via JSON mode (live) |
| Models | 30+ models behind one endpoint for the answer layer |
| Pricing | Flat monthly plans with unlimited fair-use usage on self-serve |
| Free tier | plugsky-micro and plugsky-lite on the free plan, no card required |
TL;DR
- Only the embedding call changes; retrieval logic and storage stay as they are.
- Re-embed the whole corpus before switching reads — vector spaces cannot be mixed.
- Keep filters and hybrid scoring where they are; they are provider-independent.
- Add the answer layer later with the same client when you need synthesis.
- Shadow-run retrieval quality before and after the switch.
How it works, step by step
- Record your current embedding model, dimensions and corpus size to plan the backfill.
- Move base URL, key and model names into configuration, with scoped keys per environment.
- Re-embed the corpus with plugsky-embed (or plugsky-embed-multilingual) into a new collection.
- Verify the new collection's dimensions and metadata match your query-time expectations.
- Embed queries with the same model and compare recall against the old index on a fixed question set.
- Optionally add a cited answer step using JSON mode on chat completions.
- Switch reads by configuration, keep the old collection for rollback, and monitor retrieval quality.
Try it yourself
Open the OpenAI-compatible API tester →
The one call that changes
Semantic search touches the model at exactly one point: turning text into vectors. That makes an OpenAI-compatible embeddings endpoint a drop-in replacement — same request shape, same response object, same client library. Ranking, filters, pagination and the user interface are untouched.
Plugsky runs both the embeddings and chat endpoints live, so the optional answer layer that turns passages into cited responses uses the same client. Managed conveniences such as batch and files endpoints are coming soon; until then, schedule large backfills yourself, which is standard practice for re-indexing anyway.
Re-embedding and hybrid ranking
The migration is a data project. Embedding spaces are model-specific, so every document must be re-embedded before the new index can serve queries. Run the backfill into a separate collection, validate it, then switch reads — never mix vectors from two models in one index.
- Dimensions: confirm your store accepts the new vector size before starting the backfill.
- Metadata parity: copy the same filter fields so comparisons are meaningful.
- Hybrid scoring: keep keyword matching alongside vectors for identifiers and names.
- Rollback: retain the old collection until the new index wins on your metrics.
Rollout and evaluation
Compare the old and new indexes on a fixed question set: recall of known source passages, mean rank of the right passage and zero-result rate. These numbers make the switch objective rather than a matter of taste. After cutover, monitor the same metrics on sampled production queries.
If you add the answer layer, evaluate groundedness and citation accuracy separately — retrieval quality and answer quality fail for different reasons. Keep provider configuration in one place so rollback or a future move is a deploy. Where data must stay in a region, pin the workspace to a region-locked plane or run VPC, on-prem or air-gapped with identical client code.
Honest comparison
| Aspect | Plugsky | Staying on OpenAI | Self-hosted embeddings |
|---|---|---|---|
| Client change | Base URL and model names | None | New serving stack |
| Embedding models | plugsky-embed and plugsky-embed-multilingual (live) | Existing model | You operate the server |
| Vector store | Any store, including pgvector | Same | Same |
| Answer layer | Same client with JSON mode | Available | Separate model deployment |
| Pricing | Flat monthly with unlimited fair use on self-serve | Per-token | GPU and ops cost |
Frequently asked questions
Do I need to change my vector database?
No. Plugsky returns standard float vectors, so any store that works today keeps working. Only the embedding call and the collection contents change.
Why must the corpus be re-embedded?
Vectors from different models are not comparable. Query and document embeddings must come from the same model, so a full backfill is required before switching reads.
Can I migrate gradually?
Yes, by running the backfill into a new collection while the old one serves traffic. Switch reads once recall checks pass, and keep the old collection for rollback.
Is the answer layer required?
No. Semantic search delivers value with retrieval alone. Add cited answers with the same client when users need synthesis rather than a passage list.
How do we compare indexes fairly?
Use the same question set and metrics — recall, mean rank, zero-result rate — for both collections. Subjective spot checks tend to favour whatever you tried last.
What about multilingual corpora?
Use plugsky-embed-multilingual so documents and queries across languages share one vector space, which simplifies both indexing and ranking.
Can this run on-prem?
Yes. Plugsky supports region-locked cloud planes plus VPC, on-prem and air-gapped deployment, and your index stays in your environment.