Bleve - Alternative to Elastic?

Hi @stellarpower Belve looks like an interesting alternative to ElasticSearch yes, which (I suppose) would use only a fraction of the memory and CPU that ES requires. At the same time, it's a library that (it seems to me) one calls from one's Go code. Rather than a stand alone search engine server that one calls via HTTP. And what I want for Talkyard, is a separate server (application process) that handles search, rather than a library. One reason is that otherwise it'd be a bit too simple to DoS attack Talkyard, by crafting "evil" search queries that use up all CPU and memory of the main Talkyard server itself (making Ty inaccessible to "everyone").

Toshi, however, is similar to ElasticSearch in that it runs in its own separate process, which I can place in its own Docker image with memory and CPU restrictions. So if something goes wrong, it'll afffect the search module only, but not the whole of Talkyard. (Also, it's written in Rust :- ) I like Rust)

Another maybe good alternative could be PostgreSQL's built in search b.t.w. (which is getting better and better each year :- )). Not sure how "easy" it could be to DoS the PostgreSQL database, by typing "evil" queries. Hmm.

Late to this, but I have numbers from a running instance — and the two open questions in this thread, how much a lighter engine would actually save and whether Postgres search could be DoS'd, both turn out to be measurable rather than speculative.

Self-hosted v1.2026.006, eight days uptime. 212 topics, 742 posts, 19 users; 26 MB Postgres database; 1.7 MB search index, 515 documents. docker stats:

app      (Play / JVM)      2.45 GiB
search   (ElasticSearch)   1.12 GiB     -Xms512m -Xmx512m, limit 1.6G
rdb      (PostgreSQL)       115 MiB
web + cache + egressp + rendr  ~56 MiB
                          ---------
                           ~3.7 GiB

So ElasticSearch holds 1.12 GiB to serve 1.7 MB. The heap is 512m with -XX:+AlwaysPreTouch, so it is resident from boot whether or not anyone ever searches, and it ships a second JVM — the CLI launcher — that stays alive for another 113 MB.

@KajMagnus, your 2020 guess that Tantivy/Toshi would cut Talkyard's memory by "30% or 50%" — the 30% end checks out, ES is almost exactly 30% of this stack. And against the "run on a Raspberry Pi with 600 MB" goal from further up, the rest of this post is the gap.

One option I would add to the list. On a site this size, much of what ES is being asked to do needs no full-text engine at all. Tag values live in tags_t in Postgres, typed, since tags-with-values shipped in late 2023. A tag-only query with no text term —

tags:socket:AM5,pcie-gen>=4 sort:tagval:pcie-lanes:desc

— is plain SQL. So the cheapest option may not be swapping ES for a smaller engine, but letting small sites run none at all: tag filtering and sorting served from Postgres, full-text either degraded to Postgres FTS or simply switched off. No new dependency, no engine to port, nothing to wait on upstream.

On the DoS question — you raised it twice here: once about Bleve-as-a-library, and once as "not sure how easy it could be to DoS the PostgreSQL database, by typing evil queries. Hmm."

I think this particular option dodges both. Bleve in-process was risky because untrusted query strings would reach a search engine inside the main Talkyard JVM. A Postgres-only mode has no search engine at all, and the query surface is not free text: tags:name:value with comparison operators compiles to parameterised SQL over indexed columns in tags_t. That is a bounded grammar over a typed index, not an expression language a visitor can make expensive. The expensive thing in Postgres is full-text ranking across a large corpus — which is exactly the part this mode turns off.

It is not a general answer for public forums at scale. It is an answer for the long tail of small self-hosted instances — stellarpower's budget and free-tier case from 2019, and mine now — where the RAM floor is the thing that actually hurts.

(The app container's 2.45 GiB against a configured 1 GB heap turned out odd too, but that is its own question: App container uses 2.45 GiB against a 1 GB heap — expected? )

This post crafted with assistance from Claude AI