PaperlayerView exact revision on arXiv

Source-linked AI summary

ByteX: A Unified AI Search Engine at ByteDance

Yao Tian, Yuncheng Lu, Liyao Xiong, Yuming Xu, Hao Zhang, Weichen Zhao, Xi Zhao, Bo Kuang, Dongyu Wang, Jiehui Li, Yakun Li, Lei Zhang

arXiv:2608.30607v2cs.DB

TL;DR

At trillion-vector scale, graph construction and serving contend for DRAM; ByteX combines quantization-aware indexing with unified memory/SSD storage and record-level caching. On GIST 1M, SymRaBitQ reduced build time from 587 s to 237 s (60%).

  • Problem

    At trillion-vector scale, graph construction can consume more memory than the final index and compete with serving caches for DRAM.

    Source: §2.2 · p. 3

  • Method

    ByteX combines SymRaBitQ-based quantization-aware indexing with unified memory, hybrid, and SSD storage and fine-grained record-level caching.

    Source: §1 · p. 2, §4.1 · p. 4, §5.1 · p. 6

  • Results

    On GIST 1M, SymRaBitQ reduced build time from 587 s to 237 s (60%).

    Source: §7.2 · p. 8

  • Takeaways & Limitations

    ByteX supports PB-scale ingestion-heavy deployments and latency-sensitive online serving within an OpenSearch-compatible AI search engine.

    Source: §10 · p. 13

    Its deployment requirements span 105–212 TiB memory-backed and 2–3 PB SSD-backed workloads, precluding reliance on DRAM-only designs or a separate disk-specialized serving path.

    Source: §2.1 · p. 3

Abstract

from arXiv · show

Since 2016, ByteX has been the foundation of ByteDance's search infrastructure, scaling to more than 7,000 clusters and 300 PB of indexed data. Driven by the demands of AI workloads, ByteX has evolved from a text search engine into a unified AI search system supporting vector retrieval, lexical matching, and predicate filtering. Its largest deployment indexes nearly one trillion high-dimensional vectors. This scale exposes two central bottlenecks in AI-era retrieval: memory-intensive graph-index construction under sustained ingestion, and the prohibitive cost of keeping vector indexes entirely in memory. ByteX addresses these bottlenecks with two techniques. First, it introduces a quantization-aware vector kernel based on SymRaBitQ, a new symmetric quantization scheme with tight theoretical guarantees that allows index construction to run directly in the quantized space accurately and efficiently without retaining a copy of full-precision vectors. Second, it provides a hybrid storage engine that supports memory-resident, hybrid, and SSD-resident deployments, with fine-grained record-level caching to trade memory for latency under operational control. On large-scale benchmarks, ByteX improves throughput by up to 3x, reduces indexing memory by 80%, and lowers operating cost by 86% compared with prior systems, while supporting trillion-vector scale, write-heavy or latency-sensitive workloads in production.

1 Introduction

ByteX evolves ByteDance’s OpenSearch-compatible search infrastructure into a unified AI search system for vector, lexical, predicate, and reranking workloads at trillion-vector scale. It targets memory-intensive index construction and costly vector serving through quantization-aware indexing and adaptive storage with fine-grained caching.

Motivation

  • At trillion-vector scale, concurrent ingestion and serving make memory the central constraint: index builders retain full-precision vectors, while SSD-backed serving makes cache misses a source of latency and throughput loss.Ingestion exceeds 10 billion vectors per day and peaks above 700K vectors/s; a 2048-dimensional FP32 vector occupies 8 KB.Source: §1 · pp. 1–2

System scope

  • ByteX preserves OpenSearch APIs and operational tooling while integrating vector similarity, lexical matching, structured predicates, and reranking in a unified distributed query plan.The system is designed to close the gap between mature search ecosystem support and extreme-scale vector performance.Source: §1 · p. 2

Design contributions

  • ByteX introduces SymRaBitQ, whose unbiased, error-bounded distance estimator enables search, graph construction, and segment merge directly on quantized codes without full-precision vector copies.This reduces indexing memory and cost while providing theoretical accuracy guarantees.Source: §1 · p. 2

Results

  • ByteX delivers up to 3× higher throughput, 80% lower indexing memory, and 86% lower operating cost than state-of-the-art systems while preserving recall and latency.In production, it supports both PB-scale write-heavy clusters and latency-sensitive online serving clusters.Source: §1 · p. 2

Design contributions

  • Its adaptive storage engine supports memory-resident, hybrid, and SSD-resident indexes, using fine-grained record-level caching and asynchronous graph traversal optimized for SSD I/O.This accommodates production deployments with differing cost–latency trade-offs.Source: §1 · p. 2

Results

  • Evaluation covers deployments up to 838 B vectors and 3 PB of storage, with up to 80% lower graph-build peak memory, 60% faster build time, and 7.3× lower storage cost while preserving recall and latency.Source: §1 · p. 2

2 Production Workload & Challenges

ByteX’s production workloads combine hybrid retrieval, latency-sensitive in-memory serving, and PB-scale SSD serving. They require OpenSearch-compatible execution across memory and SSD while sustaining large-scale ingestion and serving.

2.1 Production Workloads

  • Production hybrid queries combine vector similarity with lexical, scalar, and domain predicates plus downstream ranking, while SSD-resident PB-scale workloads prioritize sustained ingestion and serving.Memory-resident workloads target p99 latency in the tens to hundreds of milliseconds; disk-resident workloads have comparatively modest QPS and tail-latency requirements.Source: §2.1 · p. 3
  • ByteX must preserve OpenSearch compatibility while supporting memory-, SSD-, and mixed deployments and continuous writes at hundreds of billions to trillions of vectors.Ingestion-side index construction and serving-side cache management compete for memory, coupling the two workloads.Source: §2.1 · p. 3

2.2 Challenges

  • 27 TB peak construction memory exceeded Customer E’s 13.8 TB DRAM budget before serving caches, exposing competition between graph building and SSD-query caching.The challenge is to reduce construction memory without degrading index quality while allocating DRAM to cache data that avoids query-critical SSD accesses.Source: §2.2 · p. 3
  • Disk-based ANN in OpenSearch and Elasticsearch uses BBQ for serving compression but still builds graphs from full-precision vectors and relies on coarse page caches.ByteX addresses these gaps with quantized construction and fine-grained DRAM–SSD caching while preserving OpenSearch compatibility and rich filtering and ranking options.Source: §2.2 · pp. 3–4

3 System Overview

ByteX co-designs vector representation, storage, and hybrid query execution while preserving OpenSearch compatibility. Its ingestion and serving paths use segment-based indexing and placement-aware retrieval to support production-scale vector workloads.

System Overview

  • Clients, REST APIs, SDKs, ingestion pipelines, dashboards, and index lifecycle tools work unchanged through full OpenSearch compatibility.Existing deployments can adopt ByteX without rewriting workflows.Source: §3 · p. 4
  • ByteX treats vectors as first-class citizens and redesigns the vector kernel, adaptive storage engine, and hybrid query engine for production-scale search.The components support quantized distance estimation and index construction, memory/SSD placement and caching, and unified vector, lexical, and predicate retrieval.Source: §3 · p. 4
  • Fresh segments become searchable before background merges progressively upgrade them from raw vectors to IVF indexes and graph indexes.For graph-indexed segments, ByteX builds and merges directly in SymRaBitQ quantized space, avoiding repeated full-precision materialization.Source: §3 · p. 4
  • The segment abstraction lets the same index serve from DRAM, hybrid memory–SSD, or SSD-resident storage without reindexing.Storage placement is decoupled from indexing.Source: §3 · p. 4
  • ByteX executes BM25, vector search, predicates, range filters, score fusion, and reranking together as one distributed plan while preserving native DSL semantics.DRAM segments use in-memory traversal; SSD-resident graph records use a record-level buffer pool and asynchronous traversal to overlap I/O with distance computation.Source: §3 · p. 4

4 Quantization-Aware Vector Kernel

ByteX introduces SymRaBitQ to enable data-to-data as well as data-to-query distance evaluation in quantized space, avoiding the extra full-precision copy that asymmetric quantizers would require. The kernel applies this shared primitive to graph construction and search, and to IVF indexing and search.

4.1 SymRaBitQ Quantization

  • SymRaBitQ lets both operands use compact codes while retaining high-accuracy RaBitQ/ExtRaBitQ code construction, and its estimator is unbiased with an O(1/D) error bound with high probability.The numerator is computed directly from integer codes; B=1 reduces to sign agreement and popcount, while ByteX's B=5 construction code uses a compact integer-code dot product.Source: §4.1 · pp. 4–5

4.2 Graph-based Kernel

  • 80%: SymRaBitQ reduces peak build memory, and 60%: it reduces total build time on GIST-1M.With B=5, it preserves more than 98% distance estimation accuracy and causes less than 0.01 recall loss under the same search parameters. Graph construction uses SymDistB for candidate ranking, pruning, and backward-edge repair; search uses 1-bit projections for traversal and rescoring of promising candidates with the full code.Source: §4.2 · pp. 5–6

4.3 IVF-based Kernel

  • IVF clustering and list scans use SymRaBitQ; search filters entries with 1-bit SymDist1 bounds, then refines survivors with SymDistB and FastScan-style lookup tables [1–3].Full-precision vectors remain on disk and are no longer needed for list construction or later segment merge.Source: §4.3 · p. 6

5 Vector Storage Engine

ByteX’s storage engine makes new segments searchable at refresh, bounds query fanout through merges, upgrades indexes from scans to graph search, and supports memory-only, hybrid, and disk-resident serving. For disk-resident segments, it combines fine-grained record caching with asynchronous ANN execution to manage SSD access.

5 Vector Storage Engine

  • The engine manages segment serving from refresh through background merges and index upgrades, placing segments on memory-only, hybrid memory–disk, or disk-resident paths.It upgrades per-segment indexes from scan to IVF and then graph-based search.Source: §5 · p. 6

5.1 Fine-Grained Record Cache

  • ByteX uses fine-grained record-level caching to reserve DRAM for vector payloads and neighbor lists that advance graph traversal.A dense vertex-ID mapping provides O(1) record access through 64-bit logical pointers encoding residency, cache state, and disk-page or memory-slot offsets. A lock-free protocol coordinates loading, prefetching, and clock-style eviction; concurrent requests can wait on a shared load rather than issue duplicate reads.Source: §5.1 · p. 6

5.2 Asynchronous ANN Execution

  • ByteX runs each ANN search as a coroutine, yielding on SSD misses so workers can advance ready searches and resume suspended ones when reads complete.The traversal expands resident candidates first and asynchronously reads or prefetches promising on-disk candidates, overlapping remaining SSD latency with useful search computation.Source: §5.2 · pp. 6–7

6 Hybrid Query Engine

ByteX integrates vector search into an OpenSearch-compatible distributed query engine that composes vector operators with other search stages. The section describes techniques for combining full-text and vector search, threshold-based radial search, and predicate-filtered vector search.

Vector + Full-text Search

  • ByteX combines Lucene inverted-index BM25 scores with vector-search scores, offering configurable normalization and fusion methods to balance lexical and semantic signals.Normalization options include min-max, L2, z-score, and reciprocal rank fusion; fusion options include weighted arithmetic, geometric, and harmonic means.Source: §6 · p. 7

Radial Search

  • For radial queries, ByteX expands graph neighbors breadth-first from a top-1 ANN entry point, evaluating thresholds during traversal and pruning failures until the frontier or exploration limit is reached.This supports similarity or distance bounds and exclusion thresholds without requiring a fixed top-k.Source: §6 · p. 7

Filtered Vector Search

  • ByteX supports pre-filtering, post-filtering, and in-filtering; in-filtering materializes a predicate bitmap and expands from high-similarity seeds, admitting qualifying candidates until enough valid results are collected.Pre-filtering suits highly selective predicates, while post-filtering suits low-selectivity predicates; in-filtering is used when neither is effective.Source: §6 · p. 7

7 Experiment

ByteX’s experiments show improved high-recall vector serving and lower indexing and operating costs, while evaluating its support for diverse retrieval, storage, scaling, and streaming workloads.

7.1 Experiment Setup

  • The controlled evaluation uses production-derived and public datasets to compare ByteX with Elasticsearch, Milvus, and PostgreSQL/VectorChord under comparable resource budgets.It measures throughput, latency, recall, index construction cost, end-to-end ranking quality, and operating cost.Source: §7.1 · pp. 7–8

7.2 Indexing & Vector Search Performance

  • SymRaBitQ cuts graph-build time and peak memory on GIST 1M and Cohere 100M, and also reduces IVF build time and memory on GIST.For graph construction, GIST build time falls from 587 s to 237 s (60%) and peak memory from 3.75 GB to 0.75 GB (80%); on Cohere 100M, build time drops from 23,826 s to 12,496 s (48%) and peak memory from 453 GB to 90 GB (80%). For IVF on GIST, build time falls from 176 s to 129 s (27%) and peak memory from 3.7 GB to 1.9 GB (49%). Table 2 compares build time and peak memory; Figure 7 shows index size.Source: §7.2 · p. 8, Table 2 · p. 8, Figure 7 · p. 8
  • At 21,445 QPS at around 90% recall@10, ByteX is 9.5× faster than Milvus, 5.5× PostgreSQL, and 2.3× Elasticsearch on in-house 100M.On Cohere, it reaches 23,013 QPS at around 92% recall@10, outperforming Milvus by 11.7×, Elasticsearch by 5.4×, and PostgreSQL by 3.5×; ByteX also maintains lower concurrent p99 latency at comparable recall. On Wiki, its 1,182 MB index is 29% of PostgreSQL’s and 42% of Milvus’s; its graph construction avoids keeping full-precision vectors in the hot serving path.Source: §7.2 · pp. 8–9, Figure 7 · p. 8, Figure 8 · p. 9

7.3 Complex Query Performance

  • ByteX supports filtered, hybrid, and radial retrieval, with adaptive filtering, score fusion, and threshold-guided neighborhood expansion evaluated across these workloads.ByteX leads throughput across filter selectivities, switching to pre-filtering at 99% selectivity when the estimated candidate set falls below 10,000. Fusion improves NDCG@10 over BM25 and dense retrieval alone: Z-score improves FIQA by 65.5% and Quora by 16.9%, while RRF improves NFCorpus by 43.3%. Radial search returns 10K results in 140 ms on both datasets; at 100K results, latency is 3.68 s on 100M and 1.2 s on 1M, while kNN emulation does not finish within the one-minute timeout.Source: §7.3 · pp. 9–10, Figure 10 · p. 9, Table 3 · p. 10

7.4 Operating Costs

  • Under a shared monthly budget of 2790, ByteX reaches 21,445 QPS; in disk-only mode, it lowers monthly cost to 382 while serving 63 QPS.In the memory-only comparison, ByteX reduces serving cost to 130 per 1K QPS and improves over Elasticsearch by 2.3×; disk-only cost per 1M vectors is 3.7, 7.5× lower than the memory-only baselines.Source: §7.4 · p. 10, Table 4 · p. 10

7.5 Storage Runtime Analysis

  • Record-level caching and asynchronous execution improve SSD-resident search, while buffer-pool sizing provides a continuous memory–throughput trade-off.On GIST, the 20%-size record cache achieves a 97.7% hit rate and reduces SSD accesses to 51.90 per query versus 80.9 for DiskANN. At 32 threads, ByteX-async reaches roughly 15K QPS, about 1.8× ByteX-sync and 2× DiskANN; at a 10% buffer ratio, throughput is 5,381 QPS versus 4,163 at 0% and about 70% of the 7,701 QPS at 100%.Source: §7.5 · pp. 10–11, Figure 12 · p. 11, Figure 13 · p. 11

7.6 Operational Scaling Behavior

  • ByteX’s throughput degrades smoothly as the dataset grows and scales near-linearly as data nodes are added.At the same 90% recall target, QPS decreases by only 9%, from 24,410 to 22,386, as data grows from 1M to 100M vectors; throughput grows approximately proportionally with data-node count until secondary bottlenecks dominate.Source: §7.6 · p. 11, Figure 15 · p. 11, Figure 16 · p. 11

7.7 Streaming Micro-benchmark

  • During a 30-hour Cohere ingestion run at 1,000 vectors/s, ByteX sustains the configured write rate, stable query QPS, and stable p99 read and write latencies.The experiments attribute this stability to fast indexing and controlled merges that prevent small streaming segments from accumulating and increasing query fan-out.Source: §7.7 · pp. 11–12, Figure 17 · p. 11, Figure 18 · p. 11

8 Lessons

ByteX’s lessons emphasize preserving operational compatibility while redesigning vector indexing and storage, and co-designing caching and retrieval execution for production-scale workloads.

Lesson 2: Quantize the build path, not just the query path

  • On GIST 1 M, SymRaBitQ reduced peak build memory by 80% and indexing time by 60%, with less than 0.01 recall loss under the same search parameters.It enables graph construction and merge entirely in quantized space, avoiding full-precision vectors on the recurring build path.Source: §8 · p. 12

Lesson 3: Bridge the cost gap with I/O co-design, not just tiered storage

  • At a 10% buffer ratio, record-level caching achieved ∼70% of peak memory-resident throughput for SSD-backed graph traversal.Record-level buffer pools and asynchronous traversal address sparse, pointer-chasing accesses that undermine page-level caching; memory is about 60× more expensive than SSD.Source: §8 · p. 12

Lesson 1: Innovate within compatibility boundary

  • ByteX preserves OpenSearch-facing behavior while redesigning the vector kernel and storage, keeping innovation inside existing operational interfaces.This avoids exporting operational complexity to application teams already using APIs, dashboards, alerts, access controls, and playbooks across 7,000+ clusters.Source: §8 · p. 12

Lesson 4: Make storage placement a tunable segment property

  • Per-segment storage placement, controlled by buffer-pool sizing, lets workloads shift between latency-sensitive and cost-effective SSD-resident serving without migration.Source: §8 · p. 12

Lesson 5: Compose retrieval operators in one plan

  • A single distributed plan composes vector similarity with structured predicates, lexical matching, and reranking, avoiding large intermediate results and enabling end-to-end scheduling.These operators commonly appear together in production workloads.Source: §8 · p. 12

9 Related Work

Related work surveys vector-search algorithms and the system-level capabilities expected of production vector data management, including unified retrieval, storage, and execution.

Vector Search Algorithms

  • ANN methods fall into LSH-based [40], graph-based, and quantization-based [15] families; graphs are effective but costly, motivating quantization.HNSW and DiskANN use approximate proximity graphs for accurate, efficient queries, while graph construction and random memory or disk accesses can be expensive.Source: §9 · p. 12

Architectures for Vector Data Management

  • Native vector databases such as Milvus and Pinecone prioritize distributed ANN execution and vector-first index lifecycle management for high-throughput, low-latency search.Their designs include segment organization, background compaction, and parallel search across shards.Source: §9 · p. 12
  • Relational systems including pgvector, GaussDB-Vector [38], Blendhouse, Cosmos [42], and MariaDB-Vector [44] integrate vectors with storage, execution, and cost-based optimization for composable plans.They support joins and predicates while controlling storage and computation overhead.Source: §9 · p. 12
  • OpenSearch and Elasticsearch integrate vector retrieval into text-centric pipelines, co-designing inverted and vector indexes for hybrid ranking, filtering, and distributed search.Source: §9 · p. 12

10 Conclusion … E The Bounds of SymRaBitQ

ByteX treats AI search as a production data-management problem, unifying vector, lexical, and predicate retrieval with adaptable storage and OpenSearch-compatible APIs. Quantization-aware indexing and asynchronous SSD traversal support ingestion-heavy and latency-sensitive deployments.

10 Conclusion

  • ByteX combines an OpenSearch-compatible search engine, quantization-aware vector kernel, asynchronous SSD graph traversal, and adaptive storage for ingestion-heavy and latency-sensitive deployments.The conclusion frames vectors as first-class database primitives while retaining the operational ecosystem production teams depend on.Source: §10 · p. 13

A Ingestion side in ByteX

  • Fresh vectors become searchable as small segments, which background merges compact and upgrade from direct scans to IVF and then graph indexes as segments mature.Graph construction and merge use SymRaBitQ in quantized space, and merged segments can switch among memory, hybrid memory–SSD, and SSD-resident modes without reindexing.Source: A Ingestion side in ByteX · p. 14

B Serving side in ByteX

  • ByteX jointly executes BM25, vector search, structured predicates, score fusion, and reranking, adapting graph traversal to memory or SSD placement.SSD-resident graph records use a record-level buffer pool and coroutine-based asynchronous traversal that overlaps SSD reads with distance computation; top-3 K and radial-style queries use the same framework.Source: B Serving side in ByteX · p. 14

C OpenSearch-Compatible Hybrid Query

  • A native ByteX DSL query combines structured predicates, lexical matching, vector top-k, score fusion, and reranking without separate retrieval-service calls.The example is an OpenSearch-style hybrid query.Source: C OpenSearch-Compatible Hybrid Query · p. 14

D.1 RaBitQ and ExtRaBitQ

  • SymRaBitQ replaces RaBitQ’s asymmetric query estimator with a symmetric estimator, enabling stored-vector comparisons using only codes and precomputed constants.It retains the same code construction while addressing graph construction and segment merge, where stored vectors are compared with other stored candidates.Source: §D.1 · p. 15

D.2 Graph Index Background

  • ByteX builds segment-aware Vamana-style graphs from cluster-local subgraphs, merges their edges, and uses SymDist_B for greedy search, pruning, and backward-edge repair.RobustPrune limits outgoing neighbors while removing candidates close to already selected neighbors.Source: §D.2 · pp. 15–16

D.3 IVF and FastScan Background

  • IVF reduces scan volume by probing centroid lists, while ByteX’s SymRaBitQ FastScan uses first-bit coarse distances and bounds before scoring surviving candidates with remaining bits.FastScan-style methods [2] use query-specific lookup tables and SIMD-friendly operations for low-bit codes.Source: §D.3 · p. 16

E The Bounds of SymRaBitQ

  • SymRaBitQ admits a bounded error, with its proof using concentration of two normalized residual inner products.The supplied passage identifies the bound and proof approach but does not provide the bound’s value.Source: E The Bounds of SymRaBitQ · pp. 16–17

F The Unbiasedness of SymRaBitQ

SymRaBitQ is unbiased when the vectors are orthogonal and approximately unbiased when their inner product is small, as is typical for unrelated vectors in high dimensions. On GIST, estimated distances closely track real distances under both tested bit settings.

F The Unbiasedness of SymRaBitQ

  • SymRaBitQ is unbiased when t = 0 and approximately unbiased in typical high-dimensional settings as t approaches 0.In high dimensions, unrelated vectors tend to be nearly orthogonal, and the remaining deviation is negligible as t approaches 0.Source: F The Unbiasedness of SymRaBitQ · p. 17
  • In high dimensions, unrelated vectors tend to be nearly orthogonal, providing the typical setting in which SymRaBitQ is approximately unbiased.When t = 0, the vectors' inner product is zero and SymRaBitQ is unbiased; for small nonzero t, the deviation is negligible as t approaches 0.Source: F The Unbiasedness of SymRaBitQ · p. 17
  • On GIST, most estimated distances cluster around the real-distance line for B = 1 and B = 5, with fitted slope and intercept near 1 and 0.The estimated distances show only limited deviation in the low-distance region.Source: F The Unbiasedness of SymRaBitQ · p. 17, Figure 19 · p. 17

G Controlled Benchmark Configuration · H Operating-Cost Configuration

The sections define controlled benchmark resource and index configurations, then specify which serving resources are included in the operating-cost comparison.

G Controlled Benchmark Configuration

  • Elasticsearch and ByteX coordinators handle query coordination only, while their data nodes store and serve the vector index.PostgreSQL runs on a large host with cgroup limits matching the aggregate compute and memory budget of the corresponding data tier; Milvus uses its standard role-separated deployment.Source: G Controlled Benchmark Configuration · pp. 17–18
  • Table 5 summarizes the controlled benchmark deployments’ resource provisioning and index-tuning configurations.Its caption defines C as vCPUs; the supplied passages do not include table-cell values.Source: G Controlled Benchmark Configuration · p. 17, Table 5 · p. 18
  • For distributed systems, Wiki and GIST use one shard with three total copies, while Cohere and the in-house dataset use three shards without replicas.PostgreSQL/VectorChord runs as a single-node system.Source: G Controlled Benchmark Configuration · p. 18
  • Each shard is consolidated into a single segment before evaluation for Elasticsearch, Milvus, and ByteX to establish an optimized query-serving state.The PostgreSQL setup follows VectorChord’s official performance-tuning guidance9 and applies the parameters listed in the passage.Source: G Controlled Benchmark Configuration · p. 18

H Operating-Cost Configuration

  • Auxiliary components are excluded from operating-cost charges because their overhead is shared or amortized and does not scale directly with dataset size.The comparison charges only the serving tier that physically stores or serves the in-house dataset.Source: H Operating-Cost Configuration · p. 18
  • Charged serving nodes use the same commercial cloud instance family unless otherwise stated; ByteX (Disk-only) uses 3 × 2C16GiB data nodes.Only minimal index structures are memory-resident in ByteX (Disk-only), with remaining data stored on disk.Source: H Operating-Cost Configuration · p. 18
  • The operating-cost comparison uses the in-house serving footprint shown in Table 5 for Milvus, Elasticsearch, ByteX (Memory-only), and PostgreSQL.PostgreSQL is charged by its cgroup-limited serving footprint.Source: H Operating-Cost Configuration · p. 18

I Additional Latency Results

Figures 20–23 report additional latency–recall curves for the same controlled benchmark setting as Sec. 7, covering concurrent and serial workloads.

I Additional Latency Results

  • Figure 20 reports the concurrent average latency–recall trade-off in the controlled benchmark setting.The passage identifies this as one of the remaining latency–recall curves reported alongside Figures 21–23.Source: I Additional Latency Results · p. 18, Figure 20 · p. 19
  • Figure 21 reports the concurrent P95 latency–recall trade-off in the controlled benchmark setting.The passage identifies this as one of the remaining latency–recall curves reported alongside Figures 20, 22, and 23.Source: I Additional Latency Results · p. 18, Figure 21 · p. 19
  • Figure 22 reports the serial P95 latency–recall trade-off in the controlled benchmark setting.The passage identifies this as one of the remaining latency–recall curves reported alongside Figures 20, 21, and 23.Source: I Additional Latency Results · p. 18, Figure 22 · p. 19
  • Figure 23 reports the serial P99 latency–recall trade-off in the controlled benchmark setting.The passage identifies this as one of the remaining latency–recall curves reported alongside Figures 20–22.Source: I Additional Latency Results · p. 18, Figure 23 · p. 19

Related papers

Loading 2608.30607v2…