All Products
Search
Document Center

PolarDB:PolarSearch 1.0 performance test

Last Updated:Apr 24, 2026

This document presents the OpenSearch Benchmark performance test results for PolarSearch version 1.0 across three standard workloads: HTTP logs, NYC taxis, and Geonames.

Note

For detailed test steps, refer to the PolarSearch benchmark test method.

Write performance test results

The write tests use the append-no-conflicts-index-only procedure to bulk write the complete corpus to a cluster. These tests evaluate write throughput (docs/s) with a varying number of concurrent write clients (bulk_indexing_clients). Each test starts with an empty index.

HTTP logs

The dataset is based on real web server access logs from the 1998 FIFA World Cup and contains approximately 247 million log records.

  • Test scenario 1: 6 shards and 1 replica

    Throughput (docs/s)

    Client 1

    Client 2

    Client 4

    Client 8 (default)

    Client 16

    Client 32

    PolarSearch 1.0

    127860

    197938

    324857

    454070

    466709

    469483

  • Test scenario 2: 6 shards and 0 replicas

    Throughput (docs/s)

    Client 1

    Client 2

    Client 4

    Client 8 (default)

    Client 16

    Client 32

    PolarSearch 1.0

    172384

    288195

    512037

    741541

    783537

    785893

NYC taxis

The dataset is based on 2015 NYC taxi trip data and contains approximately 165 million records.

  • Test scenario 1: 6 shards and 1 replica

    Throughput (docs/s)

    Client 1

    Client 2

    Client 4

    Client 8 (default)

    Client 16

    Client 32

    PolarSearch 1.0

    77098

    113670

    183412

    259955

    271045

    272685

  • Test scenario 2: 6 shards and 0 replicas

    Throughput (docs/s)

    Client 1

    Client 2

    Client 4

    Client 8 (default)

    Client 16

    Client 32

    PolarSearch 1.0

    126167

    187151

    311023

    451135

    482505

    488001

Search performance

The search test runs after write operations are complete, with replica=1 and target_throughput=0 (full-speed stress testing mode), to evaluate the maximum search throughput (ops/s) under full CPU load.

HTTP logs

term: Exact term match

An exact term match is performed on logs-* with a fixed hit count of 10,000 entries, returning the default 10 entries. This test evaluates the search efficiency of the PolarSearch 1.0 inverted index, the overhead of cross-shard fan-out and merge operations, and the processing capability of the network coordination layer.

term (ops/s)

Client 1

Client 2

Client 4

Client 8

Client 16

Client 32

PolarSearch 1.0

148

312

591

829

1147

1475

asc_sort_timestamp: Sorting by doc values

A match_all query is executed on all documents, and the top 10 results are returned after being sorted in ascending order by timestamp. The @timestamp field is of the date type and is sorted by using doc values columnar storage. This operation evaluates the read efficiency of doc values, top-N heap sorting, and the merging capability of the coordinator node for PolarSearch 1.0.

asc_sort_timestamp (ops/s)

Client 1

Client 2

Client 4

Client 8

Client 16

Client 32

PolarSearch 1.0

133

262

443

579

732

931

range: Time range scan

Perform a dynamic time window range query on the @timestamp field. Because 90% of queries in the log product include a time filter, this task evaluates the efficiency of date range scanning, complementing term queries to provide a comparison between point queries and range queries.

range (ops/s)

Client 1

Client 2

Client 4

Client 8

Client 16

Client 32

PolarSearch 1.0

106

269

431

573

707

815

hourly_agg: Time-series aggregation

This test performs a date_histogram aggregation (bucketing by the hour) across all documents. It evaluates the aggregation throughput for date types, a core operation in log monitoring and statistical analysis scenarios.

hourly_agg (ops/s)

Client 1

Client 2

Client 4

Client 8

Client 16

Client 32

PolarSearch 1.0

1.48

2.97

4.3

4.76

4.8

4.8

NYC taxis

match-all: Baseline scheduling

A match_all query is executed on the entire dataset of approximately 165 million records, returning only the default 10 records without sorting or aggregation. This process tests the efficiency of the basic path for engine request parsing, shard scheduling, and result serialization.

match-all (ops/s)

Client 1

Client 2

Client 4

Client 8

Client 16

Client 32

PolarSearch 1.0

281

564

1115

2022

3167

4508

range: Numeric range scan

Performs a fixed numeric range filter on the total_amount field (fare amount, scaled_float type) to query for trips with a fare between 5 and 15 dollars, and returns 10 results by default. This operation tests the range scanning efficiency of a numeric field.

range (ops/s)

Client 1

Client 2

Client 4

Client 8

Client 16

Client 32

PolarSearch 1.0

10.63

21.07

39

43

43

43

autohisto_agg: Adaptive time aggregation

Perform an auto_date_histogram aggregation (automatic bucketing, buckets=20) on data within a 20-day time window to examine the engine's adaptive aggregation capabilities. This complements range (range is for numerical range queries, while auto_date_histogram is for time range aggregations).

autohisto_agg (ops/s)

Client 1

Client 2

Client 4

Client 8

Client 16

Client 32

PolarSearch 1.0

17.55

37.64

64.55

73.38

74

75.84

Geonames

The Geonames dataset is based on global points of interest (POI) data, containing approximately 11.4 million records with fields such as place names, country codes, population, and geographic coordinates. It is primarily used to evaluate performance across various query types. Because the Geonames dataset is much smaller than the HTTP logs and NYC taxis datasets, its write times are short. Consequently, the write performance differences for PolarSearch 1.0 are not significant enough for a meaningful comparison. Therefore, the Geonames tests focus on search scenarios, covering exact queries, full-text search, aggregations, geospatial queries, and script scoring to evaluate the product's query processing capabilities.

term: Exact term match

term (ops/s)

Client 1

Client 2

Client 4

Client 8

Client 16

Client 32

PolarSearch 1.0

434

866

1615

2887

4433

5755

phrase: Full-text phrase match

This test evaluates phrase match performance in full-text search. A phrase match requires verifying term position information in the inverted index and is therefore more computationally complex than a standard term query.

phrase (ops/s)

Client 1

Client 2

Client 4

Client 8

Client 16

Client 32

PolarSearch 1.0

408

782

1341

2523

3737

4925

country_agg_uncached: Terms aggregation with nesting

This test performs a terms aggregation (bucketing by country code) with a nested sum aggregation across all documents. The aggregation cache is disabled to reflect the true computational overhead. This test evaluates the engine's CPU utilization efficiency under heavy aggregation loads, making it representative of compute-intensive aggregation scenarios.

country_agg_uncached (ops/s)

Client 1

Client 2

Client 4

Client 8

Client 16

Client 32

PolarSearch 1.0

12

24.62

45

50.55

51

51

decay_geo_gauss_function_score: Geospatial distance decay scoring

A scoring query with a geo-distance decay function (Gaussian decay) is run on the geo_point field to evaluate the query efficiency of the geospatial index and the score calculation capability.

decay_geo_gauss (ops/s)

Client 1

Client 2

Client 4

Client 8

Client 16

Client 32

PolarSearch 1.0

5

9.73

17

18.62

19

19

painless_static: Painless script scoring

This test uses a Painless script to compute a custom score for each document. The script is pre-compiled and executed statically (static binding). This test evaluates the computational throughput of the script engine, including JIT compilation. It is representative of highly customized script scoring scenarios.

painless_static (ops/s)

Client 1

Client 2

Client 4

Client 8

Client 16

Client 32

PolarSearch 1.0

5.52

10.85

19

20.89

21

21

desc_sort_population: Numeric sorting by doc values

Sort all documents by the population field (integer type) in descending order and return the top 10 results. The sorting is performed by using doc values columnar storage. This operation tests the efficiency of reading numeric fields from columnar storage and the performance of top-N sorting.

desc_sort_population (ops/s)

Client 1

Client 2

Client 4

Client 8

Client 16

Client 32

PolarSearch 1.0

250

464

864

1451

1960

2469