Tools: Open Source Quest To Find The Fastest Search Stack

Tools: Open Source Quest To Find The Fastest Search Stack

Posted on Jan 21

• Originally published at wolk.work

Recently I was tasked with implementing search in a large eCommerce application. While researching hosted search applications, Algolia's InstantSearch mesmerized me with its speed - consistently delivering results in under 50ms globally. Essentially showing me results as I type!

Hosted search applications like Algolia specialize in providing a great search experience for users of applications, e-commerce or knowledge websites.

Inspired by Algolia, I challenged myself to see if I could replicate this kind of performance using familiar technologies. This turned out to be harder than expected. I went through four different architectures before finding something that worked well. Here's what I learned along the way.

I started with my usual stack: Next.js deployed to Vercel with a Neon PostgreSQL database. Neon supports many extensions and comes with the powerful pg_search and pgvector extensions included, so I could store embeddings and do semantic search alongside regular keyword search.

The implementation was very quick to setup and worked great functionally.

The issue was latency. Even though my Next.js API routes were running at the edge via Vercel, every search still required a network call to Neon's centralized PostgreSQL instance. Database queries alone were taking 100-200ms due to network latency. Cold starts added another 100-200ms on top of that.

The takeaway was clear: database location matters more than compute location. Edge functions don't help if your data is centralized.

Since data locality seemed to be the issue, I tried Cloudflare Workers with D1. Workers run globally, are known for their speed and support a massive network of edge locations. D1 replicates SQLite databases globally, so both compute and data would be close to users. Perfect!

The rebuild went reasonably well. D1's SQLite with FTS5 handles keyword search very efficiently when the database was co-located with the worker. But vector search was problematic.

Source: Dev.to