How Baidu Cloud Transforms Elasticsearch into a High‑Performance Vector Database

1 Baidu Smart Cloud’s Vector Database Technical Practice

InfoQ: Could you introduce your background and current responsibilities?

Li Li: I joined Baidu after graduation and have worked there for over ten years. Initially I focused on infrastructure, especially messaging queues and storage. After Baidu Smart Cloud was founded, I continued developing cloud‑related products, still centered on messaging and storage. In recent years I shifted to big‑data work, developing platforms for open‑source components such as Hadoop and Elasticsearch, as well as kernel optimizations.

InfoQ: When did you first encounter vector databases?

Li Li: Around 2019 Baidu Smart Cloud began planning vector capabilities for the public‑cloud Elasticsearch scenario, which sparked my interest in vector retrieval.

Elasticsearch as a Vector Database

InfoQ: Was Baidu intentionally building a vector database at that time?

Li Li: Elasticsearch is a NoSQL document‑oriented search database. Because many search scenarios require storing vectors, we added vector storage and retrieval capabilities to it.

InfoQ: Is this capability native to Elasticsearch?

Li Li: Yes, the need is inherent.

InfoQ: What specific vector‑search features does Elasticsearch provide?

Li Li: Vectors are used for semantic search of text, images, video thumbnails, etc. Scanning all vectors sequentially is too slow, so we made two improvements: columnar storage for vector columns and integration of an open‑source similarity engine to accelerate search.

In 2017 Facebook open‑sourced Faiss (Facebook AI Similarity Search), a high‑dimensional vector index and clustering library. In 2020 we added a vector column format to Elasticsearch and incorporated Faiss, enabling fast vector retrieval.

Before Faiss, Elasticsearch’s native script‑based similarity calculation was very slow and could not meet business requirements. After integrating Faiss, performance improved dozens of times.

InfoQ: Why not develop your own search engine instead of using Faiss?

Li Li: The community solution already satisfied our needs, and we made some custom adaptations on top of it.

InfoQ: Is the current vector database still based on Elasticsearch + Faiss?

Li Li: Essentially yes. Although we rely on the open‑source engine, we have performed extensive low‑level customizations when coupling Elasticsearch with Faiss.

InfoQ: What customizations did you make?

Li Li: Elasticsearch’s core engine is Lucene, which originally lacked vector support. We designed and implemented a custom columnar storage format for high‑performance vector persistence and loading. We also built integration layers so that Faiss could operate on our storage format, handling format alignment and performance optimizations.

Performance after these changes more than doubled.

InfoQ: How long did it take to productize the vector capability?

Li Li: The vector retrieval feature of Baidu Smart Cloud’s BES (Baidu Elasticsearch) was productized within about a year, even before large‑model hype.

InfoQ: How many optimization cycles have you gone through?

Li Li: Continuous optimization from incubation to mature service. The first version launched in 2020, a major upgrade arrived in 2022, and a third generation released this year, again roughly doubling performance and supporting hundred‑billion‑scale high‑dimensional vectors in production.

InfoQ: Is the architecture distributed?

Li Li: Yes, it is distributed, though it can also run on a single node.

2 Traditional Databases + Search Engines = Vector Databases?

InfoQ: Do you think vector databases are a genuine necessity?

Li Li: Absolutely. Large models rely on external knowledge stored as vectors to provide accurate, up‑to‑date answers. Vector databases enable real‑time retrieval of such knowledge, which is essential for reliable AI applications.

Adding vector capabilities to traditional or NoSQL databases is feasible for small‑scale use cases, but large‑scale workloads (e.g., billions of users) require dedicated, tightly coupled vector‑search systems with architecture considerations such as compute‑storage separation.

InfoQ: What are the main technical challenges of AI‑native vector databases?

Li Li: The first layer is algorithmic—optimizing graph‑based, inverted‑index, or quantization methods for speed and cost. The second layer is system integration—choosing whether to build on an existing database or implement a custom framework, each affecting overall performance.

Many teams adopt existing open‑source engines (Elasticsearch, Redis, etc.) to reduce cost and focus on application logic and ecosystem integration.

InfoQ: How should enterprises choose a vector database?

Li Li: For modest workloads and cost sensitivity, combining an existing database with a vector engine (e.g., Elasticsearch + Faiss, PostgreSQL + vector extension) is quickest. Large enterprises with massive data volumes often prefer self‑developed or heavily customized solutions.

3 Future Outlook

InfoQ: Will the vector‑database market become as competitive as the traditional database market?

Li Li: Not likely. Vector databases are tightly coupled with large‑model demand; if the model ecosystem stalls, the market contracts. Success requires strong AI capabilities and ecosystem integration.

InfoQ: Will all databases eventually support vectors natively?

Li Li: Relational databases are less likely to add extensive vector support due to mismatched workloads. NoSQL databases (Elasticsearch, Redis, MongoDB) are already adding vector features, and analytical databases will follow because big‑data and AI are closely linked.

InfoQ: What trends will shape vector databases?

Li Li: Continued algorithmic research, deeper cloud‑native architecture, and compute‑storage separation to enable elastic scaling of indexing resources and query workloads.