November 24, 2025
Cold-starts, hot takes
I put a real search engine into a Lambda, so you only pay when you search
Pay-per-search dream sparks cheers, nitpicks, and “computerless” jokes
TLDR: A dev stuffed a real search engine into AWS Lambda so you pay only when you search. Comments cheered the clever hack but argued over memory limits, dropped vendor support, and storage choices—plus jokes about going “computerless” next.
A rogue developer tried cramming a full-on search engine (Nixiesearch) into AWS Lambda—those tiny cloud functions that only run when you call them—so you’d literally pay only when you search. The post throws shade at “serverless” search, calling it an accounting trick with hidden warm machines, then uses GraalVM to compile Java ahead-of-time (AOT) so there’s no slow warm‑up. The crowd? Loud. Split. Entertained.
Fans like infecto gush that search is a money pit—especially “hybrid” setups mixing keywords and AI embeddings—and cheer any path to cheaper queries. Skeptics show up fast: ncgl pokes at outdated limits, asking if the write-up missed 10 GB Lambda memory (link), while psanford drops drama that Quickwit worked great on Lambda… until devs stopped supporting it (link). That’s the mood swing: excitement vs. “will vendors pull the plug?”
Then the architecture detectives arrive. billconan asks why the index (think the search library of files) is written to S3 (cloud storage) and then pulled into EFS (network drive) instead of going straight to EFS—cue head‑scratching. And the memes? Hashmap claims they’ve moved beyond serverless into “computerless architectures.” The vibe is half hacker theater, half cost-cutting crusade, wrapped in ProgrammerHumor energy and a community trying to decide if pay-per-search is genius, fragile, or both.
Key Points
- •The article proposes running a search engine inside AWS Lambda without warm standby nodes by compiling it to a native binary.
- •Three blockers to serverless search are identified: large containers (~700MB for ES 9.x), long startup times (~40s) and cold JVM latency, and distributed index/state rebalancing.
- •Nixiesearch, built on Apache Lucene, is compiled with GraalVM native-image to reduce image size and eliminate JVM warmup, aiming for sub-second startup and scale-to-zero.
- •Remote index storage is explored using AWS S3 and AWS EFS to keep state outside the engine while maintaining reasonable search latency.
- •GraalVM’s tracing agent is used to generate reflection configuration; the native build takes ~2 minutes on a 16-core CPU and yields a ~338MB Docker image based on Ubuntu 24.04.