Algolia or Typesense: search you host or search you rent

Algolia runs the index for you; Typesense is software you install and operate. In the first month they look interchangeable — both take your records, forgive a misspelling, rank by fields you weight, and answer fast enough that nobody notices. The difference is operational and it arrives later: one of these is somebody else's pager at two in the morning, and the other is yours. It flips when the data cannot leave a network you control, or when nobody on the team wants to own an upgrade.

What does a managed service actually sell you?

Not the algorithm. Both document how their ranking works, and both let you set weights, synonyms and typo tolerance. What a managed service sells is the work around the index: upgrades applied without you, failover, capacity on the day a campaign triples your traffic, and a status page for when a director asks why search is slow.

That purchase comes with a mental model: you stop thinking about a server and start thinking in operations, where a meter moves with records indexed and searches served. A nightly full reindex is ordinary maintenance on a machine you own and a deliberate act on a metered service, so the team builds incremental sync it might otherwise not need.

What does a second copy of your data cost?

The index is a copy. Every field you send it lives outside your database, in a provider's network, under that provider's access logs, retention rules and breach surface. Not a reason to refuse — a reason to decide field by field. A product name, a description and a category belong in an index. A salary, an identity number, a medical note, a customer's credit limit do not, and the cheapest way to keep them out is a written list agreed before the first record.

The second cost is drift: an index is a projection of your data, never the truth, and two places answering the same question will disagree. A deleted product keeps appearing in results.

What do you take on when you host it yourself?

Typesense is a process you run, usually in a container, on a machine you rent. The predictable part is real: the data stays on infrastructure you control, the bill does not move with query volume, latency is known because the path is short, and an auditor asking where the index lives gets a straight answer.

What you take on is everything the vendor was doing. Major upgrades that require a reindex or a schema change. Snapshots that are not backups until somebody has restored one. Memory sizing, because an index that no longer fits in memory stops being fast in a way that looks like a bug in your application. A plan for the day traffic triples.

Typesense is also sold hosted, and Algolia is not the only option, so the split is between shapes.

How does the index learn that a record changed?

Most incidents start here, in both shapes. Three mechanisms, in ascending order of reliability.

• Write-through. After saving, the application calls the index. Fast, simple, and silent when the call fails, which is why it needs a retry queue and a log rather than a bare try.
• Change data capture. A process reads the database's change log and pushes each change outward. It survives application bugs because it does not depend on the application remembering, but ordering has to be handled and a change can replay twice.
• Scheduled reindex. Rebuild everything on a timetable. Correct eventually, stale in between, and more expensive as the catalogue grows.

The delete path needs its own decision. A job that reads changes row by row can miss a hard delete, and the record lives on in results where a customer can still click it.

Is a stale index for ten minutes acceptable?

Sometimes, and the answer is per field. A product description that lags is invisible. A stock count that lags is an oversell and a phone call. A price that lags is an argument at the counter.

So write the number down: price and stock must be exact, or re-read from the database after the index returns the identifier. Permissions must never be enforcement-by-index — the query that returns a row is not the query that decides whether this user may see it.

How do they compare on what you will actually operate?

Dimension	Managed (Algolia)	Self-hosted (Typesense)
Who runs it	The vendor; you tune relevance	Your team; you patch, size and upgrade
Where the index lives	A second copy in the vendor's network	Inside your own network
Sync job	Yours to build	Yours to build
Failure at 2am	A status page and a support thread	Your phone
Cost shape	Moves with records and queries	A server bill, roughly fixed

What is the decision test?

1. Count the documents, and the fields each carries. A catalogue of four hundred products and a feed of two hundred thousand events are different problems wearing the same words.
2. Count how often each record changes in a day, and how many change at once during an import.
3. Write the acceptable staleness per field, in minutes, and get whoever owns the data to agree.
4. List the fields that may never leave your network. If the list is not empty, the managed option needs a filter or it is out.
5. Build the sync job first, as a separate process with a queue, so the destination can be swapped without touching the application.
6. Rehearse the failure: stop the index and watch the site. A search box that says the search is unavailable is a design decision; a blank page is not.

Where this goes wrong

• The index becomes the source of truth. A record deleted in the database is edited in the index instead, and the two diverge permanently.
• Sync only on create. Edits and deletions never propagate, and support starts hearing about products that no longer exist.
• An admin key in the browser. The key that can write to the index ships to the front end, and anyone can rewrite the catalogue.
• Self-hosting with no restore. A snapshot exists, nobody has opened it, and the first outage is also the first test.

What this advice leaves out

No prices appear here, deliberately: the vendors meter differently and change terms, and a figure would be stale before this page ranked. It also leaves out hybrid search, the analyzer work Arabic needs first, and query analytics. The comparison assumes a database you trust and a search box that serves a product, not a search engine that is the product.

We integrate search around both products, resell neither and take no commission, so nothing above is a recommendation of a vendor.

We build the sync job and the fallback, so a stale index degrades into a slower page rather than a wrong answer.