Introducing Luxir

Sep 21, 2026

I’ve been working on a new search engine. It’s called Luxir, it’s open source under the Apache License 2.0, and you can download it and try it today. It’s a hybrid search engine written in modern C++ with full-text search, vector search, faceting, and analytics. You talk to it over gRPC or HTTP/JSON.

The name is lux (light) plus IR (information retrieval). I pronounce it like “Luxeer”, but you can pronounce it however you like.

Why write another search engine

I wrote the first version of Solr in 2004 at CNET. Servers were smaller back then - less RAM, fewer CPU cores, and spinning disks. Java was a decent choice for that machine, and Lucene was (and still is) a great library to build on.

The hardware kept changing, and the JVM wasn’t keeping up. Native code offered the following benefits:

Removal of GC pauses, which continued to be a major issue
Smaller total RAM needs (garbage collection needs extra space)
Direct access to SIMD instructions
Better resource sharing with other processes on a host (you can give memory back to the OS)
Predictable latency and code generation (JIT can compile differently based on what traffic it sees first)
No warmup - much faster time from process launch to first search

In 2014, I created the Heliosearch fork of Solr to try to address some of the issues. I moved filters and the field-cache off-heap, and added native code (C++) faceting that was twice as fast as the Java version. The new faceting API from Heliosearch went back into Solr as the JSON Facet API. The off-heap and native code work did not.

Around 2015, I began thinking about how I would go about writing a successor to Lucene and Solr. I also started thinking about what cloud computing changes for infrastructure software:

Compute was no longer a sunk cost, but a recurring cost that would be much more visible to developers. For common shared pieces of infrastructure like open source databases or search engines, it made sense to put in the harder engineering work to get to faster and more efficient solutions.
Pricing changed: bigger machines no longer carried a price premium (for example within an instance family in AWS, doubling the CPUs and RAM doubles the price). Scaling up can yield better efficiency by avoiding networking hops, host coordination, and other per-node costs.

In 2020, I retired from my “working” career, and among other things, started to work on Luxir, designed from the start to get the most out of every core and every gigabyte of one large node. Starting with a clean slate and twenty years of hindsight allowed for better decisions and fixing things I had wanted to fix for a long time (things like automatic parallel indexing and an easier multi-select faceting API). Check out the full features list on the website for more.

Performance

The whole point of building a successor to Lucene/Solr from the ground up is efficiency and speed.

In the first full-text benchmarks comparing Luxir with Elasticsearch and OpenSearch, Luxir’s throughput is 1.6 times Elasticsearch’s and 2.0 times OpenSearch’s (geometric mean across 60 query types).

The benchmark harness, the engine configurations, and the raw results are all public, so anyone can re-run them and check my work. More will follow: faceting, indexing throughput, memory use, and vector search.

Where it stands

Luxir is pre-release software. The APIs and the on-disk index format will change without notice before 1.0, so expect to reindex when you upgrade (reindexing is fast). It is a single-node engine today. Replication and distributed search are not implemented yet, and neither is authentication or TLS, so run it behind your own security boundary. Binary releases are for Linux on x86-64.

Try it

Download a single binary and start it:

./luxir
curl http://localhost:9400/health

The quickstart gets you from there to your first requests. The source is on GitHub.

I’d love to hear how it works for you. Questions and ideas go in GitHub Discussions, and bugs in Issues.