When Search Meets Rust: A Deep Dive into INFINI Pizza, the Next‑Gen Real‑Time Search Engine

1. What Is INFINI Pizza?

INFINI Pizza is a distributed hybrid search database written in Rust, targeting millisecond‑level latency, petabyte‑scale mutable data, high concurrency, complex joins, and unified handling of structured and unstructured fields.

2. Motivation and Design Philosophy

Elasticsearch’s immutable Lucene segments, fixed refresh_interval, and static shard allocation cause engineering pain for mutable, high‑throughput workloads. Pizza’s official “application boundaries” focus on:

Millisecond‑level latency‑sensitive search

Mutable data requiring fresh inserts and fast queries

High concurrency with complex queries

PB‑scale data serving user‑facing workloads

JOIN‑style relationships

Thousands of fields with only a few frequently changing

Unified processing of structured and unstructured data

From these scenarios Pizza adopts five principles:

Indices are designed per use case, using Views to combine or split document sources.

Storage / Computation Separation – compute and storage are independent.

Storage / Index Separation – the most distinctive difference from Lucene.

Native LLM/ML Integration – AI capabilities are embedded directly in the search pipeline.

Modern Hardware First – the engine is rebuilt for multi‑core CPUs, large memory, NVMe SSDs, and io_uring.

3. Core Concept Hierarchy

Pizza organizes data in a layered model that mirrors Elasticsearch concepts but adds its own abstractions:

Cluster – a set of interconnected nodes.

Zone – logical grouping of nodes (rack/zone awareness).

Region – finer‑grained locality within a zone.

Namespace – multi‑tenant container holding collections.

Collection – a set of similar documents; the primary unit for storage and retrieval.

Rolling – vertical partition of a collection, each rolling holds up to 4.2 billion documents.

Partition – horizontal logical slice of a rolling, fixed at 256 partitions per rolling.

Shard – physical container for a partition; mapping from partition to shard is dynamic.

Store – forward records stored as Parquet files.

Index – inverted or vector structures accelerating queries.

Document and Field – basic data units.

4. Rolling, Partition, and Shard – Solving the Shard‑Adjustment Pain

Rolling enables a collection to grow from zero to petabytes without pre‑defining shard count. Each rolling contains 256 fixed partitions; when a partition fills, a new rolling is created and shards can be re‑configured dynamically. This replaces Elasticsearch’s manual ILM + rollover + reindex workflow.

Partition‑to‑shard mapping is many‑to‑one and supports two strategies:

// Hash strategy: shard_index = hash(partition_id) mod number_of_shards
"hash": { "number_of_shards": 8 }

// Range strategy: explicit mapping of partition ranges to shards
"range": ["0..128, 129..255"]

The benefit is that “shard” remains a stable logical concept for the business, while operations can scale out or merge by remapping partitions to shards without downtime.

5. Storage Layer – Parquet as the Default Store

Documents are persisted as Parquet files in object storage, enabling seamless integration with modern data‑lake ecosystems such as Iceberg, Delta, Hive, Spark, Trino, and DuckDB.

6. Distributed Architecture: Share‑Nothing + Asynchronous I/O

Unlike Elasticsearch’s share‑everything JVM model, Pizza isolates each CPU core with its own thread, memory, and resources, yielding four advantages:

Linear scalability on thousands of cores.

Zero lock contention.

Fault isolation – a core failure does not affect others.

NUMA‑friendly access patterns.

All I/O is driven by Linux io_uring, reducing system‑call overhead, improving buffer management, and matching the share‑nothing model’s per‑core submission/completion.

6.1 Per‑CPU Resource Isolation

Each core runs an independent thread, eliminating shared heap, GC pauses, and cross‑core synchronization.

6.2 Full‑Async io_uring Stack

Lower syscall cost.

More efficient buffer handling.

Higher throughput and lower latency under I/O‑bound workloads.

Zero cross‑core coordination fits the share‑nothing design.

7. True Real‑Time Indexing

Elasticsearch requires a refresh_interval (default 1 s) before newly indexed documents become searchable. Pizza eliminates this by making writes instantly visible to queries while background indexing proceeds, achieving “True Real‑Time”.

Two paths enable this:

Write‑Visible – documents are queryable immediately after insertion.

In‑place Partial Update – fields can be updated without fetching, modifying, and re‑indexing the whole document.

7.1 Partial Update Mechanics

Supported operations include add, replace, remove, and array_append. Updates can be performed in:

sync – immediate visibility.

async – write is appended to the WAL and returns instantly; background workers apply the change, ideal for write‑heavy, read‑light scenarios.

This directly addresses the Elasticsearch pain point where updating a single field in a thousand‑field document requires a full fetch‑modify‑reindex cycle.

8. Unified Hybrid Search

Pizza positions itself as a “Hybrid Search Database”, supporting full‑text, numeric, geopoint, vector (semantic), image/video, and business insights within a single collection. Native integration with LLM/ML makes it an AI‑native data foundation for RAG and agent applications.

9. Ecosystem Components

Pizza Engine (FIRE) – MIT‑licensed Rust library for embedding.

Pizza Server – AGPL‑v3 distributed server (≈15 MB binary).

Pizza WASM – WebAssembly package (≈200 KB gzipped) that runs entirely in the browser with zero dependencies.

Pizza Searchbox – 300 KB UI component (forked from MeiliSearch‑Docsearch) that provides Algolia‑level search for static sites.

9.1 WASM Demo

Running the full query engine in the browser, supporting Lucene‑style syntax, boolean expressions, and field restrictions, with offline indexing and a tiny bundle size.

9.2 Searchbox Integration

Integrates with static site generators (Hugo, Docusaurus, VitePress) by adding a few template lines; the entire search UI and backend run client‑side, preserving data sovereignty.

10. Pizza vs. Elasticsearch – Comparative Table

Key differences include implementation language (Rust vs. Java/JVM), true real‑time indexing, in‑place partial updates, dynamic rolling‑partition‑shard model, Parquet storage, share‑nothing + io_uring architecture, AI‑native capabilities, and WebAssembly support. Elasticsearch remains the industrial‑grade standard for TB‑scale workloads, while Pizza targets the next decade’s PB‑scale, mutable, AI‑driven use cases.

11. Typical Use Cases

User‑facing large‑scale real‑time search (e‑commerce, social feeds).

Entities with frequent partial updates (ad inventory, CRM, IoT device shadows).

Data‑lake integrated retrieval on existing Parquet data.

AI‑native back‑ends for RAG/agent or enterprise search.

Static sites or privacy‑sensitive scenarios where a client‑side search engine is preferred.

12. Outlook

INFINI Labs has a history of search‑related products (Gateway, Console, Easysearch). Pizza represents a bold, open‑source effort to re‑architect search for modern hardware and AI workloads. Although still early‑stage—community size, plugins, observability, and compatibility layers are evolving—the project offers a valuable window for long‑term observation and contribution.

Official site: https://pizza.rs/