8 Vector Databases Forward Deployed Engineers Actually Deploy

Behind almost every enterprise retrieval system is a vector database, the store that holds the embeddings a model searches to find relevant information. Choosing the right one is a decision a forward deployed engineer makes on many engagements, and it matters more than it looks, because the vector store shapes the performance, cost, operational burden, and fit of a retrieval system inside a customer's environment. This piece walks through eight vector databases that show up in real forward deployed work, what each is good for, and how to choose between them, so you can match the store to the customer's situation rather than reaching for whichever one you know best.

The choice is genuinely consequential in enterprise work, where the constraints of the customer's environment often matter more than raw benchmark performance. Building the judgement to choose and deploy the right vector store, as part of the broader retrieval skill the Forward Deployed Engineering Program teaches, is what separates retrieval systems that work in production from ones that only demo.

Key Highlights

• A vector database stores the embeddings a retrieval system searches, and the choice shapes performance, cost, operational burden, and fit.
• pgvector, which adds vectors to Postgres, is often the pragmatic choice because it avoids adding a new system to the customer's stack.
• Dedicated stores like Pinecone, Weaviate, Qdrant, and Milvus offer specialised performance and features at the cost of another system to run.
• The right choice in enterprise work often depends on the customer's existing stack and operational constraints more than on raw benchmark performance.
• Choosing the store that fits the customer's environment is part of building retrieval that actually survives production.

pgvector: vectors in the database you already have

pgvector is an extension that adds vector capabilities to Postgres, and for forward deployed engineers it is frequently the most pragmatic choice, precisely because it avoids adding a new system to the customer's stack. Many enterprises already run Postgres, so using pgvector means the retrieval system's vectors live in a database the customer already operates, understands, and trusts, rather than requiring them to adopt and maintain a new specialised store.

This matters enormously in forward deployed work, where the operational reality of the customer's environment often outweighs raw performance. A dedicated vector database might offer better benchmark numbers, but if it means the customer has to run, secure, and maintain another system they did not have before, the practical cost can outweigh the benefit. pgvector sidesteps this by fitting into infrastructure the customer already has, which also makes the eventual handoff far easier, because the customer's team already knows Postgres. For many enterprise retrieval systems, especially those of moderate scale, pgvector is the sensible default precisely because it minimises new operational burden, and a forward deployed engineer should reach for it before assuming a specialised store is necessary.

Pinecone: the managed, fully hosted option

Pinecone is a fully managed vector database, meaning the customer does not run it themselves, they use it as a hosted service, which removes the operational burden of maintaining a vector store entirely. For situations where the customer wants strong vector search performance without the responsibility of operating the infrastructure, Pinecone's managed model is appealing, because it handles the scaling, availability, and maintenance that a self-hosted store would require.

The trade with a managed service like Pinecone is the usual one: convenience and reduced operational burden in exchange for cost and the dependence on a third-party hosted service. For some customers, especially those without the appetite or capacity to run a vector store themselves, this is exactly the right trade. For others, particularly those with strict data governance requirements that make sending data to a hosted service difficult, a managed option may not fit, which is a common consideration in the regulated environments where forward deployed engineers often work. Knowing when a managed store like Pinecone is the right fit, and when the customer's constraints rule it out, is part of the judgement the role requires, and it connects to the broader challenge of building under data governance constraints.

Weaviate and Qdrant: open-source, feature-rich stores

Weaviate is an open-source vector database with a rich feature set, offering capabilities beyond basic vector search, and it can be self-hosted or used as a managed service, giving flexibility in how it is deployed. For forward deployed engineers who need more than simple similarity search, Weaviate's broader capabilities can be valuable, and its open-source nature means it can be run inside the customer's environment when data cannot leave, which matters in restricted settings.

Qdrant is another strong open-source vector database, known for performance and a good developer experience, and similarly offering the flexibility of self-hosting or managed use. It is a solid choice when you want dedicated vector-search performance while retaining the option to run it inside the customer's own infrastructure. Both Weaviate and Qdrant occupy the useful middle ground of being purpose-built for vectors, and therefore more capable and performant than a general database for demanding retrieval, while remaining open-source and self-hostable, which addresses the data-residency concerns that rule out managed services in many enterprises. For engineers who need real vector-search capability but must keep data within the customer's environment, these stores are frequently the right answer.

Milvus: built for scale

Milvus is an open-source vector database built specifically for large-scale vector search, and it enters the picture when the scale of a retrieval system grows beyond what simpler options handle comfortably. For customers with very large document collections or high query volumes, Milvus offers the architecture to handle vector search at serious scale, which is exactly what some enterprise deployments require.

The consideration with a scale-focused store like Milvus is that its power comes with operational complexity, so it is the right choice when the scale genuinely demands it and an over-engineered choice when it does not. A forward deployed engineer building a moderate-scale retrieval system does not need Milvus and would be adding unnecessary operational burden by choosing it, while one building a system over an enormous corpus with high throughput may find it exactly the right tool. This is the recurring theme of vector database selection: matching the store to the actual scale and needs of the deployment rather than reaching for the most powerful option by default. Choosing a scale-focused store when the scale calls for it, and a simpler one when it does not, is the kind of judgement that keeps a retrieval system both capable and maintainable, which matters because enterprise RAG fails as often from unnecessary complexity as from insufficient capability.

FAISS and Redis: libraries and in-memory options

FAISS, from Meta, is not a full database but a library for efficient similarity search, and it appears where an engineer wants fast vector search embedded directly in their application rather than as a separate service. For situations that do not need a full database, FAISS provides high-performance similarity search that can be built into the application itself, which can be the simplest option for smaller or more contained systems. It is a lower-level tool, giving performance and control at the cost of the features and operational conveniences of a full database.

Redis, the in-memory data store, also offers vector search capabilities, which makes it a natural option when a customer already uses Redis or when the speed of in-memory search matters. Because Redis is already common in many stacks for caching and fast data access, using its vector capabilities can mean, like pgvector, avoiding the addition of a new system. Both FAISS and Redis illustrate that a full dedicated vector database is not always necessary, and that sometimes the right choice is a library embedded in the application or the vector capabilities of a store the customer already runs. Recognising when a lighter-weight option suffices, rather than defaulting to a dedicated vector database, is part of the pragmatic judgement that keeps forward deployed systems fit for their actual purpose.

Performance considerations that actually matter in production

While fit with the customer's environment usually dominates the choice, there are real performance considerations that matter once a system is live, and understanding them helps you avoid choosing a store that works in testing and struggles in production. The main ones are search speed, how quickly the store returns relevant results, which matters for user-facing systems where latency is felt directly; indexing performance, how the store handles adding and updating vectors, which matters when the corpus changes frequently; and scale behaviour, how the store performs as the number of vectors grows from thousands to millions, which is where naive choices often break.

These considerations become binding at scale, where a store that performed fine on a small test corpus can degrade badly on a large production one. The mistake to avoid is choosing purely on how a store behaves in a small demo, since that tells you little about its production behaviour, and then discovering the performance problems only after deployment. An experienced engineer thinks about the production scale and query patterns from the start, choosing a store whose performance characteristics match the real workload rather than the demo. This is another instance of the demo-to-production gap that defines so much forward deployed work, where what works in a clean small test fails at real scale, and it is why the same discipline that makes enterprise RAG survive production applies to the vector store beneath it. Matching the store's performance to the actual production workload, not the demo, is part of building retrieval that lasts.

Migration and lock-in are real risks

A consideration that engineers often overlook until it hurts is the risk of lock-in and the difficulty of migrating between vector stores later, which is worth weighing at the point of choice because it shapes the customer's future flexibility. Once a system is built around a particular vector store, moving to a different one can be costly, involving re-indexing the data, adapting the code, and re-testing the whole retrieval system. This means the initial choice carries a degree of commitment, and choosing a store that later proves wrong for the customer's needs imposes a real migration cost.

The way to manage this risk is partly to choose well up front, matching the store to the customer's genuine needs and constraints so a migration is less likely to become necessary, and partly to build in a way that does not couple the whole system too tightly to one store's specifics, so that a future migration, if needed, is less painful. Favouring stores with standard interfaces and avoiding excessive dependence on one store's proprietary features keeps options open, which serves the customer's long-term interest. This forward-looking, lock-in-aware thinking is part of building systems that serve the customer well over time rather than just at launch, and it connects to the maintainability and handoff that define a successful engagement. Choosing a vector store is not just a technical decision for today but a commitment that shapes the customer's flexibility for years, which is why the judgement developed through the Forward Deployed Engineering Program weighs the long term alongside the immediate need.

How to choose the right store

Pulling it together, the choice of vector database in forward deployed work is driven less by benchmark performance than by the fit with the customer's environment and needs, and a few questions guide it. First, does the customer already run something with vector capabilities, like Postgres or Redis, in which case pgvector or Redis avoids adding a new system. Second, can data leave the customer's environment, which determines whether a managed service like Pinecone is even an option or whether a self-hostable open-source store is required.

Third, what is the actual scale, since a moderate-scale system does not need a scale-focused store like Milvus and is better served by something simpler. Fourth, who will operate the system after handoff, since a store the customer's team already knows is far easier to hand off than a new specialised one. These questions matter more in enterprise forward deployed work than raw performance benchmarks, because the operational and governance realities of the customer's environment usually dominate the decision. The engineer who chooses the store that fits the customer, rather than the one with the best benchmarks, builds retrieval systems that actually survive in production and can be maintained after handoff, which is the whole goal.

The eight stores at a glance

To help you choose, here is how the eight options compare across what drives the decision.

Read the table as a decision guide keyed to the customer's situation. The right store is usually the one that fits the customer's existing stack, data-residency constraints, actual scale, and the team that will maintain it, rather than the one with the best raw numbers. Choosing on fit rather than benchmarks is the mark of an engineer who builds for production reality.

The deeper skill beneath the store selection is understanding retrieval well enough to know what your system actually needs, which is what the agentic AI practitioner path develops through hands-on work with real retrieval systems. A store is only as good as the retrieval design around it, and an engineer who understands embeddings, indexing, and search quality can make a sensible store choice for any situation, while one who only knows product names cannot. Understanding retrieval deeply is what turns a menu of stores into a deliberate, defensible decision.

This same fit-the-customer discipline runs through every technology choice in the role, from frameworks to cloud platforms, and the vector store is simply one more decision where the customer's environment should lead rather than the benchmark.

The bottom line

The vector database behind a retrieval system shapes its performance, cost, operational burden, and fit inside the customer's environment, and choosing well is a decision forward deployed engineers make repeatedly. pgvector is often the pragmatic default because it avoids adding a new system to a stack that already runs Postgres. Managed Pinecone removes operational burden where data can leave the environment. Open-source stores like Weaviate, Qdrant, and Milvus offer specialised performance with self-hosting for restricted settings and scale. And lighter options like FAISS and Redis suffice when a full dedicated store is unnecessary.

The recurring lesson is that the right choice in enterprise work is driven by the customer's existing stack, data-residency constraints, actual scale, and the team that will maintain the system, rather than by benchmark performance. Choosing the store that fits the customer, and can be handed off cleanly, is part of building retrieval that survives production. Developing that judgement, as part of the broader retrieval and deployment skill the Forward Deployed Engineering Program teaches, is what turns a benchmark-chaser into an engineer who builds systems that actually work in the customer's world.

Building retrieval that lasts

Choosing a vector store well is one piece of the larger skill of building retrieval systems that survive production, and that skill is built through practice rather than benchmarks. Developing it through agentic AI foundations and hands-on engineering with agents is what lets you match the store to the customer's environment, scale, and governance rather than reaching for whichever one you know best. The store is only the foundation, and building retrieval that holds up on real enterprise data, at real scale, and can be handed off cleanly, is the capability that actually matters.