Search Shouldn’t Require a Server Farm
Introducing Lucet — a pure Python search engine that runs in a second and fits in your project
There’s a moment every developer hits where they need search — real search, not WHERE content LIKE '%whale%' — and the options laid out in front of them feel absurd.
Spin up Elasticsearch. Configure a JVM. Stand up a Solr cluster. Wire up a vector database. Pay for a managed service. Write an abstraction layer. Debug a distributed system just to find a word in a document.
For a feature. In a Python app. That needs to ship this week.
This is the infrastructure tax on search, and we’ve collectively decided to treat it as normal. It isn’t.
What Lucene Was Always Supposed to Be
Lucene — the search library at the heart of Elasticsearch and Solr — is genuinely brilliant engineering. Field queries, wildcard matching, phrase search, boolean operators, range filters. It’s expressive, fast, and battle-tested across decades of production use.
But Lucene is Java. And everything built on top of it — Solr, Elasticsearch, OpenSearch — is infrastructure. Servers, clusters, configuration, memory tuning, index management. That’s the right answer at scale. It’s the wrong answer for the other ninety percent of use cases.
I’ve spent years working with Solr in production at enterprise scale. I know what it can do. I also know what it costs to run — not just in dollars, but in operational complexity, in onboarding time, in the cognitive overhead of maintaining a distributed search cluster when all you really needed was to search a few thousand documents.
There had to be a better path for the smaller problem.
Lucet
Lucet is a lightweight, self-contained full-text search engine — pure Python, no Java, no external infrastructure, no cloud dependency. It implements the standard Lucene query language using luqum for AST parsing and runs as a FastAPI service you can spin up in one second and embed directly in your project.
git clone https://github.com/CaptureClub-LLC/Lucet
pip install -r requirements.txt
python3 main.py
That’s it. Search is running.
It supports the query syntax you already know:
title:dickens
author:twain AND content:mississippi
content:"call me ishmael"
word_count:[10000 TO 50000]
Real Lucene syntax. Real field queries. Real boolean logic. No translation layer, no query DSL to learn, no mapping configuration.
The Design Decision That Actually Matters
Most search tools make you choose: index everything upfront (fast queries, slow startup, high memory) or index nothing (fast startup, no search). Lucet does neither.
It uses a two-tier lazy index. Metadata — title, author, filename, word count — for every document is always in RAM. A few megabytes, loaded in under a second. Full text content is only pulled from disk when you explicitly ask for it.
The result: Lucet starts with documents indexed and uses a minimal amount of memory. Load a corpus on demand and search it with located passage snippets — highlighted excerpts per result, each tagged with its position in the document. Unload it when you’re done.
Example State RAM 2,318 books, metadata only ~3 MB After loading one novel ~3.4 MB After loading 10 novels ~7 MB
This isn’t a trick. It’s just the right architecture for the problem.
Why This Matters Now
We’re in an interesting moment for search. Vector databases and semantic search are getting all the press, and rightfully so — embedding-based retrieval is genuinely transformative for certain problems. But the gravitational pull toward AI-native everything has created a blind spot.
A lot of search problems aren’t semantic. They’re structural. A user wants documents by a specific author. A developer needs to find every record where a field contains a phrase. An analyst needs range queries on numeric metadata. These are Lucene problems. They’ve always been Lucene problems. The solution never required a GPU.
Lucet is a recalibration. An argument that the right tool for a bounded search problem is a bounded search tool — one that fits in your repo, starts in a second, and doesn’t ask you to manage infrastructure to answer a simple query.
What’s Next
Lucet ships today as a full-stack application — Python engine, REST API, and a web UI with a library browser, drag-and-drop upload, and document viewer. The engine is also directly embeddable if you just want the search layer without the UI.
The name comes from the Latin lucet — “it shines.” The same root as Lucene. The same idea: illuminate what you’re looking for.
It’s open source. It’s MIT licensed. And it runs in a second.
[GitHub →] [Try it →]
Kevin M. Cowan is a Senior Generative AI/Search Engineer and the founder of Capture Club, LLC.