Typesense

Last reviewed Aug 26, 2026 · 837 words

Typesense keeps the entire index in RAM, so the one number that decides whether it fits your box is dataset size: budget roughly 2 to 3 times the size of your JSON documents in memory, and the 512 MB floor in our catalogue is only true for toy collections. Get that sum right and everything else about Typesense is easy. It is a single C++ binary, it answers typo-tolerant queries in single-digit milliseconds, and it needs none of the JVM heap tuning that makes Elasticsearch a part-time job.

It replaces Algolia, not your log stack

The 26,478-star project markets itself as an alternative to Algolia and Elasticsearch, and only the first claim is honest for most people. Typesense is built for search-as-you-type on product catalogues, documentation, and app data: a few hundred thousand to a few tens of millions of records, instant results, faceting, geo queries, and since the mid-2020s vector and hybrid search. It is not a place to ship logs, run aggregations over terabytes, or store anything you cannot regenerate. If your Elasticsearch use is Kibana dashboards, stay where you are. If it is a search box on a site, Typesense will do the same job on a tenth of the hardware.

Running it is one container and one key

There is no config file to speak of; the server takes flags. The compose block that most people end up with:

services:
  typesense:
    image: typesense/typesense:29.0   # pin a real tag; the project publishes no latest
    command: --data-dir /data --api-key=change-me-now --enable-cors
    ports:
      - "8108:8108"
    volumes:
      - ./typesense-data:/data
    restart: unless-stopped

Port 8108 is the API, GET /health is the probe you point Uptime Kuma at, and the key in --api-key is the admin key that can create and delete collections. Never put that one in a browser. Instead generate a scoped, search-only key through the /keys endpoint and ship that to your front end; it can query but cannot write. The catalogue rates the setup Easy and I agree: a schema, a bulk import over JSONL, and a query_by parameter gets you from nothing to a working search box inside an hour.

Schema-first is the trade you are making

Unlike Meilisearch, which will happily index whatever JSON you throw at it, Typesense wants a collection schema up front: field names, types, and which ones are facetable. It supports auto-schema detection, but I would not use it in production, because a wrongly inferred type on day one means a reindex later. That rigidity buys you predictable memory use and faster imports, and it pushes you into the good habit of deciding what is searchable before you ship. The difference between the two engines is mostly taste plus one hard fact: Typesense has open-source clustering and Meilisearch does not.

Clustering is free, which is the real Algolia killer

Three nodes with a --nodes file pointing at each other give you a Raft cluster: writes go through the leader, reads are served from any node, and a node loss is survived without a page. That is the feature Algolia charges for by the request and that Elasticsearch makes you earn with shard and replica planning. For a single-person site I would still run one node with a nightly snapshot from the /operations/snapshot endpoint copied off-box, because HA costs you three times the RAM and most outages are the disk under it, not the process. The moment a search outage costs you money, the second and third node are the cheapest insurance in this category.

Vector search is real but not the reason to pick it

Typesense will store embeddings, do approximate nearest-neighbour queries, and blend them with keyword matches in one request, and it can call out to an embedding model to generate vectors on ingest. That is convenient for a docs site where "how do I reset a password" should find "credential recovery". It is not a replacement for Qdrant if vectors are the whole workload: the tooling for filtering, quantisation, and very large collections is thinner. The notes in embeddings and search in production cover when hybrid search is worth the complexity at all; for most catalogue and documentation searches, good typo tolerance and synonyms beat a vector index that nobody tunes.

What I'd do

One Typesense node on a box with RAM at least 3 times the exported JSON, pinned image tag, admin key in an environment file, a search-only scoped key in the front end, nightly snapshot to another machine. Grow to three nodes only when search downtime has a price. Choose Meilisearch instead if you want zero schema thinking and will never need a cluster; stay on Elasticsearch only if you are actually using it for something other than search. For a self-hosted search box on real traffic, Typesense is the one I reach for.