Self-hosted search for e-commerce: why 2026 is the right year to own the stack

Five years ago the reasonable advice was: don’t build search yourself. Hand it to Algolia, Doofinder, Searchspring. The cost of building search well — relevance tuning, faceting, typo-tolerance, analytics — was much higher than the SaaS bill.

That isn’t true anymore. Modern Postgres has full-text and trigram indexing that handles typo-tolerance and relevance for most catalogues. Open-source analytics libraries handle queries / CTR. And the operational glue — the code that turns those primitives into a product — is exactly what AI coding tools make 10× cheaper to write.

So if the SaaS price stayed the same and the build cost went down an order of magnitude, the math flipped. For most PrestaShop and WooCommerce shops under ~500k SKUs, owning your search stack is now the more pragmatic choice.

What “owning” means in practice

• Your index lives in your shop’s database. Backups already exist.
• One-time install. No recurring contract.
• When a new PrestaShop or WooCommerce release ships, the same maker who wrote the plugin is the one testing compatibility, not a SaaS roadmap.
• No catalogue export to a third-party. (Increasingly relevant for GDPR conversations.)

The honest counter-cases

If you’re at the scale where you have a dedicated relevance engineer or you need per-user personalization at scale, hosted search still wins. Vector search across hundreds of millions of items is also a SaaS-shaped problem. The self-hosted argument applies to the long tail of shops, not the head.

What we do about it

NP Search is our take on this for PrestaShop. NP Search for WooCommerce is in development for the WordPress side. Both run inside your shop’s DB, both are owned, both come with a compatibility watcher that retests them every time PrestaShop, WordPress, or WooCommerce ships an upstream release.

That’s the bet, in one sentence.