It's called Luxir, it's open source from Yonik Seeley

Yonik Seeley, the creator of Solr, released Luxir, an open source hybrid search engine written in modern C++ under the Apache License 2.0, offering full-text search, vector search, faceting, and analytics over gRPC or HTTP/JSON. 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). Luxir is pre-release software whose APIs and on-disk index format will change without notice before 1.0, and it is single-node today with replication and distributed search not yet implemented.

Introducing Luxir I’ve been working on a new search engine. It’s called Luxir https://luxir.org , 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 Section titled “Why write another search engine” 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 https://yonik.com/blog/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 https://luxir.org/docs/latest/features/ on the website for more. Performance Section titled “Performance” 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 https://yonik.com/bench/full-text/ , Luxir’s throughput is 1.6 times Elasticsearch’s and 2.0 times OpenSearch’s geometric mean across 60 query types . The benchmark harness https://github.com/luxir-search/searchbench , 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 Section titled “Where it stands” 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 Section titled “Try it” try-it Download https://luxir.org/download/ a single binary and start it: The quickstart https://luxir.org/docs/latest/guide/quickstart/ gets you from there to your first requests. The source is on GitHub https://github.com/luxir-search/luxir . I’d love to hear how it works for you. Questions and ideas go in GitHub Discussions https://github.com/luxir-search/luxir/discussions , and bugs in Issues https://github.com/luxir-search/luxir/issues .