Search isn't "find the matching rows." It's "find the best result, even if the input isn't perfect."
What is Typesense?
Typesense is an open-source search engine — a lighter, simpler alternative to Elasticsearch. It's built for one thing: fast, typo-tolerant, faceted search.
Think of any e-commerce search bar that shows results instantly as you type, even with a typo. That's the experience Typesense is designed for.
A collection works like a table. Each record inside it is a JSON document. You define a schema (which fields are searchable, sortable, etc.), Typesense indexes everything, and queries return in milliseconds.
Collection: books
Document: { "title": "Atomic Habits", "author": "James Clear", "year": 2018 }
search "atomik" in "title" → still returns: Atomic Habits
That typo tolerance, plus filtering (narrow by exact criteria), faceting (show counts like "Fiction (120)" next to filters), and sorting — that's the whole toolkit.
Putting It to Work on a Job Platform
I used this on a real job platform — 6,000 jobs, 5,000 cities, 1 lakh+ candidate profiles. Employers search candidates by skills, experience, education, even resume content. Job seekers search jobs by keywords, salary, location.
The backend runs Frappe + MariaDB. Typesense lives on a separate server, connected purely over its REST API (API key + host). Collections mirror the database tables — jobs, candidates, departments — each row becoming a JSON document.
Typo tolerance is set to 3 characters (so "Bangalor" still finds "Bangalore"), combined with filtering, faceting, and sorting for the full search experience.
What Nobody Tells You
Typesense gives "good enough," not "exact." A recruiter searching for exactly 5 years experience might still see 4.5 or 5.5 years ranked close by, thanks to fuzzy relevance scoring. Great as a fallback — but precision-critical searches still need a path back to the database.
Schema changes aren't free. Adding a new field isn't like an SQL ALTER TABLE. It needs explicit API calls and sometimes re-indexing existing data. Plan your schema upfront.
One collection per table, or one unified collection? Mirroring the database was the easy starting point. But a single denormalized collection — where one document holds job + department + location together — could make cross-entity search ("Senior Backend Developer, Engineering, Ahmedabad") a single query instead of stitched-together results. Still evaluating the trade-off, since denormalizing means more update complexity when source data changes.
Real-time sync is the actual hard part. Every MariaDB write needs to reflect in Typesense, or search goes stale. This is less a Typesense problem and more a "what changed, and where does it need to propagate" coding problem — and it gets more tangled as more entities get linked together.
The Takeaway
The performance gain is real — sub-millisecond, typo-tolerant, faceted search across 1 lakh+ profiles isn't something plain SQL handles gracefully at this scale. Typesense does the heavy lifting. The actual engineering work is in the data flow around it: schema design, sync logic, and knowing when to fall back to the database for precision.
Resources: Typesense Docs · API Reference
I'm Khushi Pandya, a software engineer working on AI-driven backends and search infrastructure. Find me on Dev.to | GitHub | Kaggle
Top comments (0)