# How we selected the next vector database at Booking.com

DevFeed: [How we selected the next vector database at Booking.com](<https://devfeed.tech/articles/how-we-selected-the-next-vector-database-at-booking-com-30452.md>)

Original publisher: [Read original article](<https://booking.ai/how-we-selected-the-next-vector-database-at-booking-com-1e738a5e3bb0?source=rss----4d265f07defc---4>)

Author: Başak Tuğçe Eskili

Published: 2026-08-11T10:31:50Z

Content type: article

Language: en

Sources: [Booking.com Data Science](<https://devfeed.tech/sources/booking-com-data-science.md>)

Topics: [Database](<https://devfeed.tech/topics/database.md>), [Retrieval Augmented Generation (RAG)](<https://devfeed.tech/topics/retrieval-augmented-generation-rag.md>), [Embeddings](<https://devfeed.tech/topics/embeddings.md>), [Back end](<https://devfeed.tech/topics/backend.md>), [opensearch](<https://devfeed.tech/topics/opensearch.md>), [AI search](<https://devfeed.tech/topics/ai-search.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [database](<https://devfeed.tech/tags/database.md>), [embeddings](<https://devfeed.tech/tags/embeddings.md>), [featured](<https://devfeed.tech/tags/featured.md>), [genai](<https://devfeed.tech/tags/genai.md>), [hybrid-search](<https://devfeed.tech/tags/hybrid-search.md>), [retrieval-augmented-generation](<https://devfeed.tech/tags/retrieval-augmented-generation.md>), [retrieval-augmented-generation-rag](<https://devfeed.tech/tags/retrieval-augmented-generation-rag.md>), [semantic](<https://devfeed.tech/tags/semantic.md>), [vector-database](<https://devfeed.tech/tags/vector-database.md>)

## AI overview

Booking.com explains why selecting a vector database became an infrastructure decision as embeddings and vector search expanded across its machine learning and GenAI systems. The article describes diverse functional and operational requirements, including hybrid search, multi-vector support, capacity, request rates, metadata filtering, and concurrency, and introduces OpenSearch as the initial choice.

## Source excerpt

This work was done in collaboration with Klaus Schaefers. Over the past few years, embeddings and vector search have become an important capability in many of our machine learning and GenAI systems at Booking.com. We initially started with a handful of use cases and experiments, and later this capability has grown into shared infrastructure that powers similarity search, semantic filtering, and retrieval-augmented generation (RAG). We used to treat vector search as a backend implementation detail, but today it directly drives the user experience. The real win isn't only speed but also the context. Expanding the variety of domain data we can retrieve efficiently gives our system the depth of context it needs to deliver accurate, and personalized experiences across the platform. This makes selecting the underlying vector database an infrastructure decision similar to choosing a primary datastore or message queue. It has to be predictable and scalable. As more teams started using our vector store, we began seeing highly diverse functional and operational requirements across different use cases. Some teams needed advanced capabilities like hybrid search or multi-vector support, while others demanded larger vector capacities and higher RPS metrics. These architectural needs ultimately brought us to a point where we needed to reassess whether our current setup could support this next phase of growth. Context: how embeddings fit into our stack Embeddings are vectors: fixed-length arrays of numbers produced by a model to represent an item (text, image, etc.). Each vector can be seen as a point in a high-dimensional space, where distance (or similarity) between points approximates semantic relatedness. By searching for the nearest vectors to a query vector, we retrieve items that are semantically "similar". This simple mechanism enables a wide range of use cases for us due its ability to do semantic similarity search. RAG-based use cases are the most well known examples. Ano