English Vocabulary for Typesense Developers

Typesense is an open-source, typo-tolerant search engine designed for speed and simplicity. It positions itself as an easier-to-operate alternative to Elasticsearch and competes with Meilisearch for developer-friendly search use cases. Typesense has its own schema-first design — you define field types explicitly before indexing documents — and a rich set of search parameters for faceting, grouping, and geo-queries. If your team uses Typesense for product search, documentation search, or any other user-facing search feature, understanding its vocabulary will help you configure it correctly and contribute to architecture discussions. This post covers the essential Typesense terms.

Key Vocabulary

Collection schema The definition of a Typesense collection — specifying the collection name, the field names, their data types (string, int32, float, bool, geopoint, string[]), and which fields are facetable or sortable. You must create the schema before indexing any documents. Schema changes require re-indexing. Example: “Define the collection schema before you index anything — Typesense is schema-first, so it needs to know the field types upfront. Add facet: true to category and brand if you want faceted search on those fields.”

Document An individual record in a Typesense collection, represented as a JSON object. Every document must include an id field (a string). Typesense indexes all schema fields and makes them searchable or filterable according to the schema definition. Example: “Index 50,000 product documents using the import endpoint — Typesense’s bulk import is significantly faster than individual document inserts for initial loads.”

Search parameters The set of options passed to the /collections/{name}/documents/search endpoint to control what is searched and how results are returned. Key parameters include q (query), query_by (which fields to search), filter_by, sort_by, facet_by, per_page, and group_by. Example: “Set query_by to name,description,tags in order of priority — Typesense will rank matches in the name field higher than matches in description.”

facet_by A search parameter that specifies which fields to aggregate into facet counts. The response includes both the matched documents and a facets object with value counts for the specified fields, enabling sidebar filters in search UIs. Example: “Add facet_by=category,brand,price_range to the search request — the frontend uses the facet counts to render the filter sidebar without a separate aggregation query.”

per_page A search parameter that controls the number of documents returned per page. The default is 10; the maximum is 250. Combined with page, it enables cursor-free pagination. Example: “Set per_page=24 to match the frontend’s grid layout — the product team wants 24 items per page, not the default 10.”

group_by A search parameter that groups results by the unique values of a specified field, returning only one or a few documents per group. Useful for showing one result per brand, one result per category, or one result per product variant group. Example: “Use group_by=product_id&group_limit=1 to deduplicate search results — we have multiple color variants of each product and we only want to show one per product in the results list.”

Instant-Search adapter An official Typesense adapter for Algolia’s InstantSearch.js library, allowing you to use the rich InstantSearch UI component ecosystem with a Typesense backend. Teams use it to quickly build polished search interfaces without writing custom UI components from scratch. Example: “Use the Typesense InstantSearch adapter instead of building the search UI from scratch — we get refinement lists, pagination, and hit highlighting for free, and the adapter handles translating InstantSearch’s query format to Typesense’s API.”

Geo-search Typesense’s ability to filter and sort documents by geographic proximity using a geopoint field. You can filter to documents within a radius of a coordinate, or sort results by distance from a given location. Example: “Add a location field of type geopoint to the store collection schema — then use filter_by=location:(51.5,-0.1, 10 km) to return only stores within 10 km of the user’s coordinates.”

How to Use This Vocabulary

Typesense integration discussions typically start with schema design — “which fields need to be facet: true?” and “what fields does the frontend search against?” Getting the schema right before initial indexing avoids costly re-indexing later. Teams often debate the trade-off between making many fields facetable (more flexible UI) and the memory overhead of faceting (facetable fields are stored in RAM).

Search parameter discussions focus on query_by field order (which determines ranking priority), facet_by selection, and whether group_by is needed for deduplication. The Instant-Search adapter is a common recommendation when the team wants to move fast — it provides a complete search UI with minimal custom code.

Example Conversation

Kemal: The search is returning duplicate color variants of the same product. Users are seeing 5 rows for the same shirt in different colors. Lena: Use group_by=product_id with group_limit=1 — that’ll collapse all variants into one result per product. Kemal: Will that affect the facet counts? We’re using facet_by=color. Lena: Facets count before grouping, so the color counts will still be accurate. Test it in staging first.

Practice

1. Design a Typesense collection schema for a job listings search engine. Identify which fields should have facet: true (e.g., job type, location, salary range) and which should be index: false (e.g., internal metadata). Write out your reasoning in English.
2. Explain to a colleague what group_by does and give an example where it prevents a UX problem. Use the words “deduplication,” “variant,” and “group limit.”
3. Compare facet_by in Typesense to a GROUP BY clause in SQL. What is similar? What is different? Write two to three sentences.