Dartfind is a purpose-built catalog search engine: one compiled binary on an ordinary x86 server — ~20 ms per query in production, built for up to 100 million records. No cluster to size, no JVM to feed with RAM, no analyzers and synonym lists to write, no engineer on payroll keeping search alive. One-time license — the client owns it outright.
Built for distributors, wholesalers and e-commerce with large catalogs — from 10,000 to 100 million records.
The download costs nothing. The production reality is a multi-node cluster, a RAM-hungry JVM, and an engineer who keeps it alive — recurring costs that dwarf most license fees. The software is free the way a puppy is free.
Typos, partial part numbers, glued words — in Elasticsearch each case is an analyzer, a synonym list, a fuzziness setting somebody has to configure, test and maintain. Relevance becomes a permanent side project.
Elasticsearch is a general search and analytics platform — brilliant at many things, sized and operated like the platform it is. If the actual job is “customers find products in a catalog,” you're running a freight train to deliver a parcel.
In July 2026 we ran the same queries against the on-site search of nearly thirty North American electrical and industrial distributors. Four failure patterns stood out.
Buying a search vendor did not predict good search — some of the strongest catalogs we tested ran no commercial search product at all. Reproduce any of these on your own storefront in thirty seconds. Type a part number wrong. Read the full audit →
| Dartfind | Elasticsearch | |
|---|---|---|
| Pricing | One-time license, owned outright | Free download; cluster, hosting and engineer — recurring, every year |
| Infrastructure | An ordinary x86 server | Multi-node cluster, RAM-hungry JVM |
| Operations | Nothing to nurse after setup | Shard rebalancing, version upgrades, monitoring, on-call |
| Dirty queries | Native — no analyzers, no synonym lists | Rules and dictionaries someone writes and maintains |
| Spec queries | “20A”, “5W-30”, “3/4 inch” — the spec in the query ranks the results | Whatever the analyzers and mappings were built to do — engineering work |
| Time to live search | 2 days | Weeks to months of setup and tuning |
| Query path | Compiled code — no interpreter, no garbage collector | JVM with GC pauses in the path |
A query typed the way real customers type — and the result list it lands on.
A comparison table where one column wins every row is an ad. Three cases where we’d tell you to stay put:
If the cluster exists only to power product search — and someone's salary exists only to keep that cluster standing — that's the setup Dartfind replaces with one binary, one server and one payment.
A sync script feeds your catalog into the engine — from a database or a plain export — and keeps it updated on schedule. A query endpoint answers searches; your storefront calls it instead of Elasticsearch. Works alongside Adobe Commerce, SAP Commerce, Oro, BigCommerce or fully custom builds, because it sits behind an API rather than inside the platform. For most stacks this is days of work — and the free pilot skips integration entirely.
Those are numbers from a live deployment: an auto-parts retailer runs Dartfind as its counter and catalog search, fed with broken part numbers every day. Full case on the main page.
Send a catalog export — real or fake. Two days later you have a working search box in your infrastructure, next to your current Elasticsearch setup. Type your customers’ worst queries at both. Then decide.