PolarVector

Updated at:

PolarDB for MySQL vector search deeply integrates vector similarity search capabilities into the database kernel. While storing and processing structured data, the database also performs efficient similarity searches on vectors generated from unstructured data such as text, images, and audio. Without deploying or maintaining a separate vector database or a complex data synchronization pipeline, you can build AI applications in your PolarDB cluster, such as semantic search, intelligent recommendations, and search by image.PolarDB provides two vector search protocols for different technology stacks and business scenarios: a protocol that is fully compatible with MySQL, and the OpenSearch protocol (PolarSearch), which is compatible with the mainstream search ecosystem.

Key concepts

  • Vector embedding: A technique that uses a pre-trained embedding model to convert real-world unstructured data, such as text and images, into numerical arrays (vectors). These vectors capture the deep semantic information of the data, enabling machines to understand and compare their similarity.

  • Similarity search (k-NN): Also known as k-nearest neighbor search. Its core goal is to find the k vectors closest in “distance” to a given query vector among massive volumes of vector data. This “distance” can be calculated by using different mathematical formulas and represents the semantic similarity of the data.

  • Vector index: To avoid exhaustive one-by-one comparisons across massive volumes of data, build a vector index in advance. An index is a data structure optimized for efficient queries. It uses the distribution characteristics of vectors to quickly narrow the search scope at query time, reducing retrieval latency from seconds to milliseconds while maintaining the recall rate.

  • Comparison of vector index algorithms: PolarDB supports several mainstream vector index algorithms. HNSW and IVF are the two most common, each with different strengths in performance, resource consumption, and applicable scenarios.

    • HNSW (Hierarchical Navigable Small World): A graph-based index with high performance and a high recall rate, but a correspondingly high memory overhead. It is suitable when query latency and accuracy requirements are extremely high and the dataset fits in available memory.

    • IVF (Inverted File): A clustering-based inverted index with lower memory usage. It is more suitable for processing ultra-large datasets in memory-constrained environments, although its search accuracy is usually slightly lower than that of HNSW.

Key advantages

PolarDB vector search engine combines the ease of use of a relational database with the high performance of a specialized vector database. Compared with other technology choices, it offers significant advantages.

Feature

Traditional relational database

Specialized vector database

PolarDB vector search engine

SQL support

Supported

Not supported

Supported

Vector search

Poor performance

High performance

High performance

Learning cost

Low

High

Low

Ecosystem compatibility

Rich

Limited

Dual ecosystem

Scalability

Limited

Good

Excellent

O&M complexity

Simple

Complex

Simple

In addition, it offers the following core advantages:

  • All-in-one solution: You do not need to introduce a separate vector database. PolarDB enables you to process business data and vector data at the same time, simplifying the system architecture and reducing O&M costs.

  • Enterprise-grade reliability: It fully supports ACID transactions to ensure data consistency. Its distributed architecture supports high availability and automatic failover, ensuring business continuity.

  • Tight integration with LLMs: Built-in inference for the Qwen model simplifies the AI application development pipeline.

Core capabilities and performance metrics

Search performance

  • Latency: P99 (99% of requests) < 10 ms and P95 (95% of requests) < 5 ms.

  • Throughput: More than 10,000 QPS per single node.

  • Precision: A recall rate greater than 99%.

Scalability

  • Data scale: Supports PB-scale vector data and vector search across billions of vectors.

  • Concurrency: Supports tens of thousands of concurrent queries.

  • Cluster size: Supports dynamic scaling to hundreds of nodes with an intelligent data-sharding strategy.

Resource efficiency

  • Storage compression: Vector data has a compression ratio greater than 50%.

  • Memory usage: Layered caching efficiently supports TB-scale graph indexes.

  • CPU utilization: Multi-core parallel optimization achieves CPU utilization greater than 80%.

Use cases

PolarDB provides a dual-protocol design. You can choose the appropriate protocol based on your team’s technology stack, business needs, and performance expectations.

Comparison dimension

MySQL protocol

OpenSearch protocol

Access method

Standard SQL

RESTful API (compatible with Elasticsearch/OpenSearch)

Core advantages

Business data integration: You can add vector columns to existing tables and use ACID transactions, with a low learning cost.

Hybrid search capabilities: Supports combined queries on vectors, full text, and scalars, with a mature ecosystem.

Underlying dependency

Depends on In-Memory Column Index (IMCI). Vector search runs on IMCI read-only nodes, isolating analytical workloads from transactional workloads.

Runs on an independent search node (PolarSearch) to provide a search engine-like service.

Data synchronization

Not required. After data is written to the primary database, it automatically becomes visible to the IMCI read-only nodes.

Not required. After data is written to the primary database, it automatically becomes visible to the search nodes.

Intelligent Q&A and customer service chatbots

  • Business pain point: Traditional keyword matching cannot understand the actual intent behind user questions, resulting in inaccurate answers.

  • Solution: Convert question-and-answer pairs in a knowledge base into stored vectors. When a user asks a question, convert the question into a vector and use similarity search to find the most relevant knowledge points, providing more accurate answers.

  • Recommended protocol:

    • MySQL protocol: This option is more convenient if you need only basic semantic matching and want to integrate quickly with an existing MySQL application.

    • OpenSearch protocol: Use its hybrid search capability when you need complex filtering with keywords, category labels, and other criteria.

Personalized recommendation systems

  • Business pain point: How to recommend products or content that users may find interesting based on their historical behavior, such as browsing, clicks, and purchases.

  • Solution: Represent both users and items (products, articles, and videos) as vectors. Calculate the similarity between user vectors and item vectors to retrieve a set of candidates that may interest the user. Then apply other strategies for fine ranking.

  • Recommended protocol:

    • OpenSearch protocol: The retrieval layer of a recommendation system usually involves large data volumes and is sensitive to performance and cost. The IVF index and Product Quantization (PQ) technology provided by the OpenSearch protocol are suitable for handling massive data while controlling memory costs.

Search by image and multi-modal retrieval

  • Business pain point: How to find similar images by uploading an image, or find images by using a text description.

  • Solution: Convert both images and text into vectors and store them in PolarDB. Whether the input is an image or text, it is converted into a query vector for similarity search in the database.

  • Recommended protocol:

    • MySQL protocol: For scenarios that require strong consistency between image feature vectors and business data such as product IDs and prices, the transaction capability of the MySQL protocol is an important safeguard.

FAQ

PolarDB vector engine: What are the advantages compared with a standalone vector database (such as Milvus)?

The main advantages are its all-in-one design and low cost.

  • No data synchronization required: Vector data and business data are stored in the same system, avoiding the complex data synchronization pipeline required by a traditional “MySQL + vector database” architecture.

  • Simplified technology stack: Removing a separate database system reduces the complexity of development, O&M, and learning, as well as the total cost of ownership (TCO).

  • Transactional consistency: With the MySQL protocol, vector operations and business data operations can be completed in the same transaction, ensuring data consistency.

Why does vector search with the MySQL protocol require IMCI read-only nodes?

This design achieves workload isolation and performance optimization. Vector search is a compute-intensive analytical processing (AP) query, whereas a database primary node typically carries online transaction processing (OLTP) workloads.

  • Running vector search on an IMCI read-only node uses columnar storage and parallel computing to accelerate queries.

  • This architecture physically isolates analytical workloads from transactional workloads, preventing vector queries from affecting the stability and response time of core business services.