Search as a service: the agent answers

I’d use **Algolia**—provided the cost estimate still works after splitting documents into searchable sections.

It best matches “good search without hiring a search engineer”: managed infrastructure, strong typo tolerance out of the box, fast faceted filtering, a mature Node SDK, synonyms, highlighting, analytics, and relevance controls that non-specialists can understand. Its default ranking prioritizes typo count, matching words, proximity, field priority, and exactness; you can then use popularity or freshness as tie-breakers. [Algolia’s ranking documentation](https://www.algolia.com/doc/guides/managing-results/relevance-overview/in-depth/ranking-criteria) and [filter documentation](https://www.algolia.com/doc/guides/managing-results/refine-results/filtering/in-depth/filters-and-facetfilters) describe those mechanics.

For a knowledge base, I would index sections rather than whole documents:

```js
{
  objectID: "document-123#section-4",
  documentId: "document-123",
  title: "Resetting two-factor authentication",
  heading: "Lost authenticator device",
  body: "...",
  product: "admin-console",
  language: "en",
  audience: ["customer"],
  updatedAt: 1786900000,
  popularity: 42
}
```

Configure roughly:

- Search priority: `title`, then `heading`, then `body`.
- Filters/facets: product, category, language, document type, audience, workspace or tenant.
- Ranking: preserve textual relevance first; use curated/verified status, popularity, and freshness only as tie-breakers.
- Disable typo tolerance for IDs, acronyms, version numbers, and similarly exact terms.
- Group section hits by `documentId` so one long document does not fill the page.
- Return snippets around the matching section, not just the document description.

Algolia explicitly supports prioritized searchable attributes and recommends excluding irrelevant fields from search. [Searchable attributes](https://www.algolia.com/doc/guides/managing-results/must-do/searchable-attributes) and [custom ranking](https://www.algolia.com/doc/guides/managing-results/must-do/custom-ranking) are the principal controls.

What else I’d consider:

| Service | When I’d choose it | Why I wouldn’t choose it first here |
|---|---|---|
| **Typesense Cloud** | Algolia’s quote is uncomfortable and your team can own a little more tuning | Excellent typo tolerance, filtering, and understandable ranking; smaller ecosystem and fewer polished relevance/analytics tools. [Ranking model](https://typesense.org/docs/guide/ranking-and-relevance.html) |
| **Meilisearch Cloud** | You want a simple, developer-friendly product with predictable entry pricing | Very quick to implement and typo tolerance is built in, but I’d benchmark relevance and operational behavior on your corpus before committing. [Typo tolerance](https://www.meilisearch.com/docs/capabilities/full_text_search/relevancy/typo_tolerance_settings), [cloud pricing](https://meilisearch.dev/pricing) |
| **Elastic Cloud Serverless** | You anticipate complex analyzers, hybrid/vector retrieval, aggregations, or unusual ranking requirements | Most flexible, but that flexibility creates the search-engineering work you are trying to avoid. Elastic manages the infrastructure, not your relevance design. [Elastic Serverless](https://www.elastic.co/docs/deploy-manage/deploy/elastic-cloud/serverless) |
| **Postgres full-text search** | Cost is the overriding constraint and requirements remain modest | A large improvement over `LIKE`, but typo tolerance, ranking, synonyms, analytics, and scaling become your responsibility. |

The important pricing trap is that “a few hundred thousand documents” may become several million section records. Algolia also notes that replica indexes used for alternate sorting increase record consumption. Model the bill using the **post-chunking record count**, average record size, monthly searches, replicas, and environments—not the source document count. [Algolia pricing](https://www.algolia.com/pricing)

Before signing, I’d run the same 100–200 real queries against Algolia, Typesense Cloud, and Meilisearch Cloud. Include misspellings, acronyms, exact error codes, multiword queries, and filter combinations. Have someone mark the expected top three results and compare quality plus the projected bill. My likely outcome is **Algolia for lowest implementation and relevance risk; Typesense Cloud as the value alternative**.

One final architectural point: keep your database as the source of truth. Send changes through an idempotent indexing worker or outbox, retain stable section IDs, and rebuild into a new index before atomically switching aliases. If documents have access controls, enforce those in search filters using server-generated scoped credentials—never fetch unauthorized hits and filter them afterward.

I’d use **Algolia Grow**.

It best matches “good search without hiring a search engineer”: typo tolerance is enabled by default, filtering/faceting is straightforward, the Node SDK is mature, and its default ranking already considers typos, matched words, proximity, field priority, and exact matches. You can then break ties using popularity, freshness, or quality signals. [Algolia’s ranking model](https://www.algolia.com/doc/guides/managing-results/relevance-overview/in-depth/ranking-criteria) is unusually understandable and generally needs less tuning than Elasticsearch.

A sensible index record would look like:

```js
{
  objectID: document.id,
  title: document.title,
  body: document.searchableText,
  category: document.category,
  tags: document.tags,
  workspaceId: document.workspaceId,
  visibility: document.visibility,
  popularity: document.viewsLast90Days,
  updatedAt: document.updatedAtUnix
}
```

Configure it roughly as:

```js
await client.setSettings({
  indexName: "documents",
  indexSettings: {
    searchableAttributes: [
      "title",
      "tags",
      "unordered(body)"
    ],
    attributesForFaceting: [
      "filterOnly(workspaceId)",
      "filterOnly(visibility)",
      "category",
      "tags"
    ],
    customRanking: [
      "desc(popularity)",
      "desc(updatedAt)"
    ]
  }
});
```

Field order influences relevance, while custom ranking only resolves otherwise similarly relevant results—so a popular document containing a weak match should not automatically beat a strong title match. [Searchable attributes](https://www.algolia.com/doc/guides/managing-results/must-do/searchable-attributes) and [custom ranking](https://www.algolia.com/doc/guides/managing-results/must-do/custom-ranking) document those mechanics.

Important implementation choices:

- Keep your database as the source of truth; update Algolia asynchronously through a queue/outbox.
- Enforce tenant and permission filters on every query. Don’t rely on UI filters for authorization.
- For long articles, index sections or chunks and group results by document. This improves passage matching, but each chunk counts as a record.
- Log queries, zero-result searches, clicks, and successful destinations from day one.
- Build a small relevance test set—perhaps 50 real queries with expected top results—before adjusting ranking or synonyms.

At current published pricing, Grow includes 100,000 records and 10,000 monthly search requests; overages are listed at **$0.40 per additional 1,000 records** and **$0.50 per 1,000 search requests**. A few hundred thousand one-record-per-document entries should therefore be modest, but chunking and search-as-you-type can substantially increase the bill. Verify using your expected record and keystroke volume. [Algolia pricing](https://www.algolia.com/pricing)

What else I considered:

| Option | Why consider it | Why it isn’t my default here |
|---|---|---|
| **Typesense Cloud** | Excellent typo tolerance, filters, predictable text-ranking controls, open source, easy API | More schema and relevance ownership; dedicated clusters mean a fixed hourly charge even when idle. It is my runner-up if cost/control or avoiding vendor lock-in matters. [Ranking behavior](https://typesense.org/docs/guide/ranking-and-relevance.html), [cloud billing](https://cloud-help.typesense.org/article/billing-process) |
| **Meilisearch Cloud** | Very pleasant developer experience, strong out-of-box typo tolerance, open-source escape hatch | I’d choose it for budget-conscious or self-hosting-friendly teams, but Algolia has the more mature hosted relevance, analytics, and merchandising ecosystem. [Typo tolerance](https://www.meilisearch.com/docs/capabilities/full_text_search/relevancy/typo_tolerance_settings) |
| **Elastic Cloud Serverless** | Maximum control; strong lexical, vector, hybrid, and reranking capabilities | Too much mapping, analyzer, query, scoring, and capacity complexity for the stated “no search engineer” goal. Its advantage becomes relevant when search is unusually specialized. [Elastic Serverless overview](https://www.elastic.co/pricing) |
| **Postgres full-text/`pg_trgm`** | Cheapest incremental step and keeps data in one system | Better than `LIKE`, but you would still own typo behavior, ranking, facets, scaling, analytics, and tuning. It moves you toward becoming the search engineer. |

I would run a two-week bake-off between **Algolia and Typesense Cloud** using your real documents and queries. Unless Algolia’s chunk-adjusted cost or data-hosting constraints are unacceptable, I’d expect it to win on time-to-good-results.

I’d use **Algolia Grow**.

It best matches “good search without hiring a search engineer”: typo tolerance is enabled by default, filtering and faceting are first-class, relevance is sensible out of the box, and the JavaScript/Node tooling is mature. Exact matches naturally outrank typo matches, while field ordering and custom ranking let you make titles and headings more important than body text. [Algolia’s ranking model](https://www.algolia.com/doc/guides/managing-results/relevance-overview/in-depth/ranking-criteria) and [filtering](https://www.algolia.com/doc/guides/managing-results/refine-results/filtering) cover the required behavior directly.

### Recommended design

Don’t index each long document as one giant record. Split it into section-sized records:

```js
{
  objectID: "doc_123#installation",
  documentId: "doc_123",
  title: "Deployment Guide",
  heading: "Installation",
  body: "...",
  url: "/docs/deployment#installation",
  product: "api",
  version: "v3",
  language: "en",
  tenantId: "acme",
  aclRoles: ["engineering"],
  updatedAt: 1786924800,
  popularity: 42
}
```

Configure:

- Searchable fields: `title`, then `heading`, then `body`.
- Filters: product, version, language, document type, tenant, and ACL roles.
- Ranking: textual relevance first; popularity and freshness only as tie-breakers.
- Synonyms: add only vocabulary your users actually employ.
- Highlighting/snippets: return the matching section rather than dumping the entire document.
- Incremental indexing: update Algolia whenever the source document changes; keep your database as the source of truth.

If content is private, enforce authorization inside the search request. Algolia supports server-generated secured keys with immutable tenant/ACL filters, so a user cannot remove the filter in browser dev tools. [Secured filtering documentation](https://www.algolia.com/doc/guides/security/api-keys/how-to/user-restricted-access-to-data).

### Cost caveat

Algolia’s current Grow tier includes 100,000 records and 10,000 monthly search requests, then charges **$0.40 per additional 1,000 records** and **$0.50 per additional 1,000 requests**. [Current pricing](https://www.algolia.com/pricing).

At 300,000 indexed records, storage is roughly $80/month beyond the included allowance. However, 300,000 source documents could become several million section records after chunking, so estimate using the **post-chunking record count**, not the number of source documents. Search-as-you-type also generates several requests per user query.

### What else I considered

| Option | Assessment |
|---|---|
| **Typesense Cloud** | My runner-up. Excellent typo tolerance, filtering, field weights, highlighting, and Node support. Its dedicated-cluster pricing has no record or operation caps, which can be more predictable at high query volume. Ranking is transparent but usually needs slightly more hands-on tuning and operational judgment than Algolia. [Ranking](https://typesense.org/docs/guide/ranking-and-relevance.html), [cloud pricing](https://cloud.typesense.org/pricing/calculator). |
| **Meilisearch Cloud** | Pleasant developer experience, strong default typo handling, filters, and relatively inexpensive managed hosting. I’d shortlist it for a cost-sensitive internal product, but Algolia has the more mature relevance tooling, analytics, and polished hosted-search ecosystem. [Typo behavior](https://www.meilisearch.com/docs/capabilities/full_text_search/relevancy/typo_tolerance_settings), [pricing](https://www.meilisearch.com/pricing). |
| **Elastic Cloud / OpenSearch** | Powerful and flexible, particularly for complex analyzers, aggregations, or logs. But mappings, analyzers, scoring, shard sizing, and upgrades are precisely the work that tends to create a search-engineering role. Too much machinery here. |
| **Postgres full-text search + `pg_trgm`** | A substantial improvement over `LIKE`, but combining typo correction, prefix matching, filters, ranking, snippets, and good latency becomes custom search infrastructure. Reasonable for tens of thousands of records; less attractive for this goal and scale. |
| **Vector database / embeddings alone** | Not a replacement for document search. Semantic retrieval can help conceptual questions, but it is weaker for identifiers, exact terminology, versions, and predictable ranking. Add hybrid semantic search later only if query logs demonstrate a vocabulary-mismatch problem. |

Before committing, I’d run a small bake-off between Algolia and Typesense Cloud using roughly 50 real queries—including misspellings, acronyms, version numbers, and zero-result searches—and have domain experts judge the top five results. My default choice remains **Algolia**, unless the chunked record count or query volume makes its usage-based pricing materially worse than a fixed Typesense cluster.

I’d use **Algolia Grow**.

It is the best fit when the priority is “good search quickly, without becoming search engineers.” Typo tolerance and prefix matching work out of the box, while filters/facets, synonyms, field weighting, custom ranking, analytics, and a mature Node client cover the usual knowledge-base requirements. Its typo tolerance generally handles up to two errors, and filtering/faceting are first-class features. [Algolia typo-tolerance docs](https://www.algolia.com/doc/api-reference/api-parameters/typoTolerance), [Search API](https://www.algolia.com/doc/rest-api/search)

For sensible initial ranking, I would index records with fields such as:

- `title`, `headings`, `body`
- `product`, `category`, `language`
- `audience` or authorization groups
- `updatedAt`, `popularity`, `isCanonical`

Then rank approximately as: exact/low-typo matches → title → headings → body, with modest boosts for canonical, popular, and recently maintained material. Avoid letting freshness overpower textual relevance.

The main qualification is document size. Algolia’s production plans currently specify an average record size of 10 KB and a 100 KB maximum. Long articles should therefore be split into section-level records, with title and document metadata duplicated onto each section. That usually improves result quality anyway, but your “few hundred thousand documents” could become considerably more searchable records. [Algolia pricing and limits](https://www.algolia.com/pricing)

Current Grow pricing includes 100,000 records and 10,000 monthly searches; additional usage is listed at $0.40 per 1,000 records and $0.50 per 1,000 searches. Thus, 300,000 indexed sections would be about $80/month for excess records, before excess queries. Validate this against your post-chunking record count and traffic. [Algolia pricing](https://www.algolia.com/pricing)

What else I considered:

| Option | Verdict |
|---|---|
| **Typesense Cloud** | My runner-up. Excellent typo-tolerant search and filters, simpler and more predictable than Elastic, with dedicated-cluster pricing and no record/operation limits. Choose it if cost sensitivity, open-source portability, or avoiding per-query billing matters more than Algolia’s polish and analytics. [Typesense Cloud pricing](https://cloud.typesense.org/pricing/calculator), [billing model](https://cloud-help.typesense.org/article/billing-process) |
| **Meilisearch Cloud** | Very pleasant developer experience and strong default typo/prefix behavior. A credible alternative, starting at $20/month, but I would put Typesense slightly ahead for a filter-heavy production knowledge base and Algolia ahead for turnkey relevance tooling. [Meilisearch pricing](https://www.meilisearch.com/pricing), [typo-tolerance behavior](https://www.meilisearch.com/docs/resources/internals/typo_tolerance) |
| **Elastic Cloud Serverless** | Most powerful and customizable, including hybrid/vector search, but has far more schema, analyzer, query, and relevance-tuning surface area. It is the wrong default when “no search engineer” is a central requirement. Serverless reduces infrastructure work, not search-design complexity. [Elastic Cloud](https://www.elastic.co/pricing), [serverless pricing](https://www.elastic.co/pricing/serverless-search/) |
| **Postgres full-text search / `pg_trgm`** | Cheap incremental improvement, but you would still own ranking, typo behavior, highlighting, analytics, scaling, and relevance iteration. It risks recreating the problem in a slightly better form. |
| **Hosted OpenSearch** | Similar operational and relevance complexity to Elastic, with less reason to choose it unless you already run deeply on AWS/OpenSearch. |

Regardless of provider, the work you still own is important:

- Build an idempotent indexing pipeline from your database; keep SQL as the source of truth.
- Apply access-control filters in the backend using a search-only key. Never trust client-supplied tenant or permission filters.
- Split documents by semantic section, but group results by parent document to prevent five hits from the same article.
- Log zero-result queries and clicks.
- Create 50–100 representative queries with expected results before tuning.
- Run Algolia and Typesense Cloud against that test set for a week before committing.

My decision rule: **Algolia for the fastest dependable outcome; Typesense Cloud if Algolia’s projected post-chunking cost is uncomfortable.** I would not begin with semantic/vector search—good lexical ranking, synonyms, typo tolerance, and filters will address the stated problem with much less complexity.

I’d use **Algolia**.

It best matches “good search without hiring a search engineer”: typo tolerance works by default, filtering/faceting is mature, the Node SDK is straightforward, and its default ranking already considers typo count, matched words, proximity, field priority, and exactness. You can then use a simple business signal—helpfulness, views, or recency—to break relevance ties. [Algolia ranking criteria](https://www.algolia.com/doc/guides/managing-results/relevance-overview/in-depth/ranking-criteria), [filtering documentation](https://www.algolia.com/doc/guides/managing-results/refine-results/filtering/in-depth/filters-and-facetfilters).

For your knowledge base, I’d index sections rather than whole documents:

```js
{
  objectID: "doc_123#section_4",
  documentId: "doc_123",
  title: "Resetting two-factor authentication",
  heading: "Lost access to your authenticator",
  body: "...",
  product: "billing",
  language: "en",
  tags: ["2fa", "account"],
  tenantId: "acme",
  updatedAt: 1786924800,
  helpfulVotes: 47
}
```

Configure:

- Searchable fields in order: `title`, `heading`, `tags`, `body`.
- Facets/filters: product, language, content type, tenant, permissions, tags.
- Ranking: retain Algolia’s textual defaults; use helpfulness and broadly bucketed recency as late tie-breakers.
- Synonyms only for real domain vocabulary such as “2FA ↔ MFA,” not as a substitute for relevance.
- Collapse multiple section hits into one document in the UI where appropriate.
- Sync changes from your SQL database through a queue/outbox; keep SQL as the source of truth.

Chunking improves passage-level relevance and avoids Algolia’s per-record size limits, which range from 10–100 KB depending on plan. It does, however, increase the billable record count, so estimate pricing using **sections**, not source documents. [Algolia service limits](https://www.algolia.com/doc/guides/scaling/algolia-service-limits), [pricing](https://www.algolia.com/pricing).

If documents have access controls, put the visibility attributes on every indexed section and enforce them through backend-generated secured search keys. Don’t rely on a UI filter for authorization. Algolia supports embedding mandatory filters in those keys. [User-restricted access](https://www.algolia.com/doc/guides/security/api-keys/how-to/user-restricted-access-to-data).

What else I’d consider:

| Service | Verdict | Why |
|---|---|---|
| **Meilisearch Cloud** | Best lower-cost alternative | Excellent out-of-box typo tolerance, simple ranking, filters, Node support, and tenant tokens. Cloud pricing currently starts around $20/month, with an example baseline of $30/month for 100K documents and 50K searches. I’d choose it if an evaluation shows equal relevance and Algolia’s section-count pricing is unattractive. [Typo tolerance](https://www.meilisearch.com/docs/resources/internals/typo_tolerance), [pricing](https://www.meilisearch.com/pricing) |
| **Typesense Cloud** | Strong technical runner-up | Fast, typo tolerant, filterable, and more explicit relevance controls. Its scoring covers token overlap, edit distance, and proximity. It asks you to make somewhat more ranking and cluster-sizing decisions, so it is less aligned with “no search engineer.” [Ranking documentation](https://typesense.org/docs/guide/ranking-and-relevance.html), [cloud billing](https://cloud-help.typesense.org/article/billing-process) |
| **Elastic/OpenSearch** | Would not choose here | Most flexible, but analyzers, mappings, fuzzy-query behavior, relevance tuning, upgrades, and capacity planning create exactly the expertise burden you want to avoid. Appropriate when search becomes a core platform capability with dedicated ownership. |
| **Azure AI Search** | Only if deeply committed to Azure | Good enterprise integration, security, hybrid/vector capabilities, and filtering. Its typo handling is exposed through fuzzy queries rather than being as effortlessly search-as-you-type oriented. [Fuzzy-search documentation](https://learn.microsoft.com/en-us/azure/search/search-query-fuzzy) |
| **Postgres `pg_trgm`/FTS** | Useful interim step, not my destination | Cheap and close to your data, but you will end up assembling typo handling, field weighting, snippets, facets, analytics, and relevance iteration yourself. |

Before signing a contract, run a one-week bake-off between Algolia and Meilisearch Cloud using about 100–200 real queries—including misspellings and permission filters—and have someone judge the top five results. My default decision would remain **Algolia unless its projected chunk-level record cost is materially worse**.

I’d use **Algolia**, assuming the documents are permitted to leave your infrastructure.

It best matches “good search without hiring a search engineer”: typo tolerance is enabled by default, filtering and faceting are first-class, and the default ranking already considers textual relevance, typos, proximity, and field priority. Its Node/TypeScript support and operational experience are mature. [Algolia typo tolerance](https://www.algolia.com/doc/api-reference/api-parameters/typoTolerance), [filtering](https://www.algolia.com/doc/api-reference/api-parameters/filters)

### How I’d structure it

Don’t index each long document as one giant record. Split documents into paragraph- or section-sized chunks, roughly 500–1,500 words, with fields such as:

```ts
{
  objectID: "doc_123#section_7",
  documentId: "doc_123",
  title: "Resetting SSO",
  sectionTitle: "Common errors",
  content: "...",
  tenantId: "acme",
  product: "enterprise",
  language: "en",
  permissions: ["support", "admin"],
  updatedAt: 1788206400,
  popularity: 42
}
```

Configure searchable attributes in this order:

1. `title`
2. `sectionTitle`
3. `content`

Then rank primarily by textual relevance, with popularity or recency only as tie-breakers. Deduplicate results by `documentId`, returning the best matching section and a highlighted excerpt.

Filters should cover tenant, product, language, document type, and permissions. Enforce authorization server-side or through short-lived secured keys containing mandatory filters; never accept an unrestricted ACL expression from the browser. Algolia supports filter-bound secured keys generated by a Node backend. [Secured API keys](https://www.algolia.com/doc/libraries/sdk/methods/search/generate-secured-api-key)

One important cost wrinkle: Algolia counts the resulting chunks as records, not merely the source documents. Long documents may turn “300,000 documents” into several million records. Algolia also recommends splitting long documents and imposes per-record size limits. [Record sizing guidance](https://www.algolia.com/doc/guides/sending-and-managing-data/prepare-your-data/how-to/reducing-object-size), [current pricing](https://www.algolia.com/pricing)

### What else I considered

| Option | Verdict |
|---|---|
| **Typesense Cloud** | My runner-up. Strong typo tolerance, filters, field weighting, and understandable relevance controls. Likely attractive if Algolia’s chunk-based bill is uncomfortable. Its ranking exposes text match plus numeric tie-breakers such as popularity and recency. [Typesense ranking](https://typesense.org/docs/guide/ranking-and-relevance.html) |
| **Meilisearch Cloud** | Pleasant developer experience and excellent out-of-box typo handling. Searchable-field order directly controls field importance. I’d choose it for a smaller, cost-sensitive deployment, but Algolia has the more mature hosted-search product and relevance tooling. [Meilisearch typo handling](https://www.meilisearch.com/docs/resources/internals/typo_tolerance), [field ranking](https://www.meilisearch.com/docs/capabilities/full_text_search/how_to/configure_searchable_attributes) |
| **Elastic Cloud / OpenSearch** | Most powerful and customizable, but this is how you accidentally create a search-engineering job: analyzers, fuzziness, scoring functions, shards, mappings, and relevance tuning. Elastic Cloud Hosted currently starts around $99/month, but engineering effort is the larger cost. [Elastic Cloud](https://www.elastic.co/pricing/cloud-hosted) |
| **PostgreSQL full-text search + `pg_trgm`** | Cheap and keeps data in your database, but you would own relevance, typo thresholds, highlighting, indexing behavior, performance tuning, and search analytics. A substantial improvement over `LIKE`, but contrary to your staffing constraint. |
| **Vector database / embeddings alone** | I wouldn’t start here. Semantic retrieval can help conceptual questions, but it is weaker at exact names, codes, quoted phrases, and predictable filtering. Add hybrid semantic search later only if real failed-query data shows a need. |

Before signing a long contract, I’d run a two-week bake-off between Algolia and Typesense Cloud using 100–200 real queries—including misspellings, acronyms, exact product codes, permission filters, and “no result” searches. Judge top-three usefulness, not just whether the desired document appears somewhere.

My default decision: **Algolia for lowest implementation and relevance risk; Typesense Cloud if the projected post-chunking Algolia cost is materially higher.**

I’d use **Algolia Grow**.

It is the lowest-risk answer when the goal is “good search without hiring a search engineer.” Typo tolerance works out of the box, exact matches naturally beat typo matches, multi-word proximity affects ranking, and filters/facets are first-class features. Its Node/TypeScript SDK and hosted operations make the migration relatively small. [Algolia documents its ranking model](https://www.algolia.com/doc/guides/managing-results/relevance-overview/in-depth/ranking-criteria) and [filter expressions](https://www.algolia.com/doc/api-reference/api-parameters/filters).

For a few hundred thousand records, current Grow pricing is also reasonable: 100,000 records and 10,000 monthly searches are included, then $0.40 per additional 1,000 records and $0.50 per additional 1,000 search requests. For 300,000 indexed records, storage would therefore be roughly $80/month before query charges. Confirm the estimate using your actual chunk count and traffic. [Current Algolia pricing](https://www.algolia.com/pricing).

### How I’d structure it

Do not index an entire long document as one result. Split it into section-sized records:

```ts
{
  objectID: "doc_123#section_4",
  documentId: "doc_123",
  title: "Resetting two-factor authentication",
  heading: "Lost-device recovery",
  content: "...",
  workspaceId: "acme",
  visibilityGroups: ["support", "admins"],
  product: "dashboard",
  locale: "en",
  updatedAt: 1788192000,
  popularity: 37
}
```

Configure:

- Searchable fields in priority order: `title`, `heading`, `content`
- Facets/filters: workspace, product, category, locale, permissions
- Custom ranking only as a tie-breaker: popularity and freshness
- Synonyms for product vocabulary and acronyms
- Analytics for zero-result and low-click queries
- Stable IDs and an idempotent background indexing pipeline

Chunking improves passage-level relevance, but it also determines your bill because every chunk is a record. Algolia imposes plan-dependent record-size limits and explicitly recommends splitting long content, so estimate against chunks—not source-document count. [Record-size guidance](https://www.algolia.com/doc/guides/sending-and-managing-data/prepare-your-data/how-to/reducing-object-size).

For private documents, authorization must be enforced inside search, not by fetching unauthorized hits and filtering them afterward. Algolia supports server-generated secured keys with mandatory filters such as workspace and group membership. [Document-level access guidance](https://www.algolia.com/doc/guides/security/api-keys/how-to/user-restricted-access-to-data).

### What else I considered

| Service | Verdict | Why |
|---|---|---|
| **Typesense Cloud** | Strong runner-up | Excellent typo-tolerant keyword search, filters, predictable dedicated-cluster pricing, and no per-record/query fees. Its ranking is transparent and supports business-field tie-breakers. I’d choose it if cost predictability or portability matters more than Algolia’s polish. [Ranking](https://typesense.org/docs/guide/ranking-and-relevance.html), [Cloud model](https://cloud.typesense.org/) |
| **Meilisearch Cloud** | Good budget-friendly option | Very easy developer experience, sensible default ranking, typo tolerance, complex filters, and tenant tokens. Attractive if you might eventually self-host. I’d run a relevance bake-off against Typesense before choosing it. [Features](https://www.meilisearch.com/docs/getting_started/features), [security model](https://www.meilisearch.com/docs/capabilities/security/overview) |
| **Elastic/OpenSearch** | Would not start here | Most flexible, but mappings, analyzers, shards, relevance tuning, upgrades, and capacity planning recreate the search-engineering work you want to avoid. Worth it only if you already operate the stack or need unusual query behavior. |
| **Azure AI Search** | Situational | Good if you are deeply committed to Azure or expect semantic/vector retrieval and document-ingestion integrations soon. Otherwise it has more concepts, configuration, and capacity planning than this problem requires. |
| **Postgres full-text/trigram search** | Better than `LIKE`, but not my recommendation | Cheap and keeps data local, but you would still own ranking, typo behavior, facets, tuning, scaling, and analytics. It solves the immediate defect without really outsourcing search. |

I would run a two-week bake-off between Algolia and Typesense Cloud using 50–100 real queries with hand-labelled expected results. If Algolia’s relevance is not materially better, Typesense Cloud is the value choice; otherwise, Algolia is the service I’d ship.

I’d use **Algolia Grow** for this.

It best matches “good search without hiring a search engineer”: typo tolerance is enabled by default, filtering and faceting are native, the Node SDK is mature, and its default ranking already considers typo count, matched words, proximity, matching field, and exactness. You can then use custom ranking to favor authoritative, popular, or recently updated documents. [Algolia’s ranking criteria](https://www.algolia.com/doc/guides/managing-results/relevance-overview/in-depth/ranking-criteria) are unusually understandable, which matters when someone asks why a result ranked first.

For a knowledge base, I would:

- Split long documents into section-sized records, retaining `documentId`, heading, URL/anchor, product, language, permissions, and timestamps. Algolia explicitly recommends splitting oversized records; plan limits range from 10–100 KB per record. [Record-size guidance](https://www.algolia.com/doc/guides/sending-and-managing-data/prepare-your-data/how-to/reducing-object-size)
- Weight fields approximately as `title > headings > body > tags`.
- Make product, document type, language, version, and permissions filterable. Algolia supports boolean combinations of facet, numeric, and tag filters. [Filtering documentation](https://www.algolia.com/doc/api-reference/api-parameters/filters)
- Add `authority`, `popularity`, and perhaps a gently decayed freshness value as custom-ranking attributes.
- Keep SQL as the source of truth and synchronize changes through a queue/outbox. Use a second index for zero-downtime rebuilds.
- If documents have access controls, enforce them inside secured API keys generated by Node—not merely in the UI. Algolia documents this exact corporate-document pattern. [User-restricted search](https://www.algolia.com/doc/guides/security/api-keys/how-to/user-restricted-access-to-data)

The main caveat is cost. Current Grow pricing includes 100,000 records and 10,000 monthly searches, then lists $0.40 per additional 1,000 records and $0.50 per additional 1,000 searches. Thus, 300,000 indexed *sections*—not source documents—would add roughly $80/month for record volume before search traffic. [Algolia pricing](https://www.algolia.com/pricing?s=t) Chunking can therefore change the economics substantially.

What else I considered:

| Option | Verdict |
|---|---|
| **Typesense Cloud** | My runner-up, especially if traffic makes Algolia expensive. Excellent typo-tolerant ranking, filters, and predictable dedicated-cluster pricing without per-search or per-record charges. It needs somewhat more benchmarking and relevance ownership from your team. [Ranking model](https://typesense.org/docs/guide/ranking-and-relevance.html), [cloud model](https://cloud.typesense.org/) |
| **Meilisearch Cloud** | Pleasant API, very good defaults, configurable typo tolerance, and starts cheaply. I’d choose it for a cost-conscious internal tool; Algolia has the more mature hosted search product, analytics, security model, and relevance tooling. [Typo tolerance](https://www.meilisearch.com/docs/resources/internals/typo_tolerance), [pricing](https://www.meilisearch.com/pricing) |
| **Elastic Cloud/OpenSearch** | Most flexible, but inconsistent with “without hiring a search engineer.” Fuzziness, analyzers, mappings, shards, scoring, and performance tuning create exactly the ownership burden you’re trying to avoid. Elastic’s own guidance shows how query structure, shard layout, concurrency, and caches affect performance. [Elastic tuning guidance](https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-search-speed.html) |
| **Postgres FTS + `pg_trgm`** | A useful incremental improvement over `LIKE`, but you would still be assembling typo handling, ranking, highlighting, facets, analytics, and operational tuning yourself. |
| **Azure AI Search** | Worth considering if you are deeply committed to Azure or expect RAG/vector requirements. It supports fuzzy search, but is a heavier platform than this problem requires. [Fuzzy-search documentation](https://learn.microsoft.com/en-us/azure/search/search-query-fuzzy) |

Before committing, I’d run Algolia and Typesense Cloud against the same 50–100 real queries—including misspellings, acronyms, permission filters, and “known best result” judgments. If both produce comparable results, choose Typesense when projected Algolia usage cost is materially higher; otherwise choose Algolia for the lower engineering burden.

I’d use **Algolia**.

For a few hundred thousand documents, it’s the safest choice when the priority is “good search without becoming a search company.” Typo tolerance is enabled by default, filtering/faceting is mature, the Node client is straightforward, and its default ranking already accounts for typos, matched words, proximity, field priority, exactness, and custom business signals. You can then use popularity, freshness, or authority as tie-breakers. [Algolia typo tolerance](https://www.algolia.com/doc/guides/managing-results/optimize-search-results/typo-tolerance), [ranking criteria](https://www.algolia.com/doc/guides/managing-results/relevance-overview/in-depth/ranking-criteria), [custom ranking](https://www.algolia.com/doc/guides/managing-results/must-do/custom-ranking)

A sensible document record would resemble:

```js
{
  objectID: "documentId#sectionId",
  documentId: "documentId",
  title: "Reset two-factor authentication",
  heading: "Lost device",
  content: "...",
  category: "account-security",
  product: "admin-console",
  language: "en",
  permissions: ["customer", "enterprise"],
  popularity: 1842,
  updatedAt: 1788192000
}
```

Index sections rather than entire long documents. Weight fields roughly as `title > heading > content`, declare category/product/language/permissions as filterable facets, and use popularity plus freshness as custom ranking signals. Enforce permission filters in the backend or with secured API keys—never trust a filter supplied solely by the browser.

What I’d also consider:

| Service | Assessment |
|---|---|
| **Typesense Cloud** | My runner-up. Excellent typo-tolerant keyword search, filters, explicit field weights, predictable dedicated-capacity pricing, and no per-search/per-record fees. It may be the better value if traffic becomes high and your team is willing to do slightly more relevance tuning. Its ranking considers token overlap, edit distance, proximity, and field weights. [Typesense ranking](https://typesense.org/docs/guide/ranking-and-relevance.html), [cloud model](https://cloud.typesense.org/) |
| **Meilisearch Cloud** | Pleasant API and excellent defaults; automatic typo tolerance and configurable ranking/filterable attributes. A strong choice for a smaller budget or especially simple search requirements. I’d put Typesense slightly ahead where filtering and explicit relevance control matter. Cloud currently starts at $20/month. [Capabilities](https://www.meilisearch.com/products), [ranking settings](https://www.meilisearch.com/docs/reference/api/settings/list-all-settings), [pricing](https://www.meilisearch.com/pricing) |
| **Elastic Cloud / OpenSearch** | Most flexible and powerful, especially for custom analyzers, multilingual morphology, hybrid/vector retrieval, and complex scoring. It also exposes substantially more tuning and operational surface area—the opposite of your “no search engineer” requirement. Elastic Serverless removes cluster operations but not search-model complexity. [Elastic Cloud comparison](https://www.elastic.co/cloud/pricing) |
| **Postgres `pg_trgm` + full-text search** | A worthwhile temporary improvement over `LIKE`, but not my preferred end state. You would own tokenization, typo thresholds, ranking, synonyms, highlighting, analytics, and ongoing tuning. |
| **Vector database / embeddings alone** | Not a replacement for this use case. Semantic retrieval is useful later, but exact names, error codes, acronyms, filters, and permissions still need strong lexical search. If needed, add hybrid search after measuring failed queries. |

The main downside of Algolia is cost and vendor lock-in. Its bill depends on record and request volume, so chunking documents too aggressively can multiply indexed records. Before committing, I’d run the same 50–100 real failed queries through Algolia and Typesense Cloud, judge the top five results, and price both using your actual record sizes and monthly query volume.

My decision rule:

- Choose **Algolia** for the quickest route to reliably good, low-maintenance search.
- Choose **Typesense Cloud** if Algolia’s projected bill is uncomfortable and someone can own a modest amount of ranking configuration.
- Choose **Elastic** only if you already know you need its deeper language, scoring, or hybrid-search controls.

I’d use **Algolia Grow**.

It is the best fit when the priority is “good search quickly, without operating or deeply tuning a search engine.” You get typo tolerance by default, filtering/faceting, synonyms, highlighting, prefix search, ranking controls, analytics, and a maintained JavaScript client. Exact matches naturally rank ahead of typo-corrected matches. [Algolia’s typo-tolerance documentation](https://www.algolia.com/doc/guides/managing-results/optimize-search-results/typo-tolerance) explains that behavior.

For a knowledge base, I would:

- Index one record per document section, not an entire long document.
- Store `documentId`, title, heading, body excerpt, URL, permissions, collection, tags, language, and timestamps.
- Weight title and heading above body.
- Add freshness or popularity only as secondary ranking signals.
- Filter permissions server-side, using restricted search keys or enforced tenant/user-group filters.
- Keep your database authoritative and update Algolia asynchronously through a queue or outbox.
- Create a small relevance test set from real queries before launch—perhaps 50–100 searches with expected top results.

The section-level indexing point matters: Algolia’s Grow plan allows an average of 10 KB per record, with a 100 KB maximum, so large articles should be split anyway. Current Grow pricing includes 100,000 records and 10,000 monthly searches, then charges $0.40 per additional 1,000 records and $0.50 per additional 1,000 searches. A few hundred thousand sections should therefore be quite manageable, though search-as-you-type can multiply request volume. [Algolia pricing and limits](https://www.algolia.com/pricing).

What else I considered:

- **Typesense Cloud:** My runner-up, and probably my choice if predictable high query volume or vendor portability mattered more. It has excellent typo tolerance, exact filters, field weighting, proximity-aware ranking, a Node client, and no per-search or per-record charges on its dedicated clusters. It is open source, so you retain a self-hosting exit path. The tradeoff is somewhat more schema, capacity, and relevance ownership. [Typesense ranking](https://typesense.org/docs/guide/ranking-and-relevance.html), [Typesense Cloud](https://cloud.typesense.org/).

- **Meilisearch Cloud:** Very easy to adopt, pleasant APIs, built-in typo tolerance, filters, and good defaults. It is attractive for a simple KB and starts at $20/month. I would benchmark it alongside Typesense, but I find its bucket-based ranking less flexible when relevance requirements become nuanced. [Meilisearch search behavior](https://www.meilisearch.com/docs/capabilities/full_text_search/getting_started/basic_search), [Meilisearch pricing](https://www.meilisearch.com/pricing).

- **Elastic Cloud / OpenSearch:** The most powerful option, especially for advanced linguistic analysis, hybrid semantic search, complex authorization, or very large scale. It is not my recommendation here: mappings, analyzers, fuzzy-query behavior, ranking, clusters, and operational tuning can effectively recreate the search-engineering role you want to avoid.

- **Postgres full-text search plus `pg_trgm`:** A respectable incremental improvement over `LIKE`, and inexpensive if PostgreSQL already holds the data. But combining typo tolerance, structured filters, autocomplete, highlighting, analytics, and consistently good ranking becomes application/search engineering. It solves the immediate query problem without necessarily solving the product-search problem.

I’d run a one-week bake-off using Algolia and Typesense Cloud against the same real queries. Unless Typesense performs equally well with materially better projected cost, I’d ship Algolia. I would not start with embeddings: typo-tolerant lexical search usually fixes this problem first, and semantic or hybrid retrieval can be added later if users search by concepts rather than vocabulary.

**Rekomendacja: Meilisearch** (opcjonalnie Typesense jako blisko równorzędna alternatywa).

Dlaczego akurat to: typo tolerance i ranking działają sensownie od razu, bez ręcznego strojenia analyzerów czy fuzzy query jak w Elasticsearch/OpenSearch (to jest właśnie ten "musisz mieć search engineera" próg). Filtry (faceting) są wbudowane, oficjalny klient Node jest prosty, a przy kilkuset tysiącach dokumentów to komfortowo mieści się w darmowym/tanim tierze Meilisearch Cloud (zero utrzymania infrastruktury) albo w self-hostingu jako pojedynczy binarny proces/Docker, jeśli wolicie trzymać dane u siebie.

Co jeszcze brałem pod uwagę i dlaczego odpadło:

- **Algolia** - rynkowy standard, świetny DX i wsparcie, ale drożej skaluje się z liczbą rekordów/operacji i to większy vendor lock-in na ich formacie rankingu. Dobra opcja, jeśli budżet nie gra roli i chcecie enterprise-owy support - ale przy "bez hire'owania search engineera" Meilisearch daje niemal to samo za mniej.
- **Elasticsearch / OpenSearch (nawet managed)** - najbardziej elastyczny ranking (BM25 + custom scoring), ale odrzucone: to dokładnie ten scenariusz, w którym potrzebujecie kogoś, kto rozumie analyzery, mapping i fuzzy queries. Managed hosting (Elastic Cloud, AWS OpenSearch) zdejmuje ops, ale nie zdejmuje potrzeby stroje­nia.
- **Postgres full-text (tsvector) + pg_trgm** - kuszące, bo brak nowej usługi, ale słaby typo tolerance i ranking out of the box - w praktyce sami zaczynacie pisać silnik search'a, czyli wracacie do punktu wyjścia z LIKE, tylko bardziej skomplikowanego.
- **Wyszukiwanie wektorowe (pgvector/Pinecone)** - rozwiązuje semantic search, nie typo tolerance/keyword relevance - inny problem, niepotrzebna złożoność (pipeline embeddingów, koszt) na start.

Jeśli chcecie, mogę przygotować krótki plan wdrożenia Meilisearch pod wasz Node backend (indeksowanie dokumentów, konfiguracja filtrów, integracja z API).

Dla paruset tysięcy dokumentów i bez dedykowanego search engineera postawiłbym na **Typesense** (self-hosted obok Node backendu, albo Typesense Cloud jeśli wolisz managed). Ma fuzzy matching/typo tolerance, faceted filtering i sensowny ranking wbudowane od razu, oficjalny klient node, i przy tej skali stawia się na jednym małym kontenerze bez strojenia.

Co jeszcze brałem pod uwagę:

- **Meilisearch** - praktycznie równorzędna alternatywa, ten sam profil (open source, typo tolerance i filtry out of the box, prosty Node SDK). Wybór między nim a Typesense to w zasadzie rzut monetą, oba pasują do zadania.
- **Algolia** - najlepszy relevance/DX na rynku, w pełni managed, ale cena rośnie z liczbą rekordów i zapytań, a dane trzymasz w ich chmurze; jeśli baza wiedzy zawiera coś wewnętrznego/wrażliwego, to dodatkowy czynnik do rozważenia.
- **Elasticsearch / OpenSearch** - odrzuciłem właśnie ze względu na "bez hiringu search engineera": typo tolerance i ranking nie działają sensownie z pudełka, trzeba świadomie configurować analyzery, fuzziness i scoring, plus dochodzi ops klastra (shardy, JVM). To jest dokładnie ta praca, której chcesz uniknąć.
- **Postgres (pg_trgm + full text search)** - kuszące, bo zero nowej infrastruktury, ale typo tolerance i ranking trzeba by ręcznie poskładać z ts_rank i progów podobieństwa trigramów, do tego filtry plus fuzzy plus ranking w surowym SQL to realna robota do utrzymania. Przy paruset tysiącach wierszy się uda, ale odtwarzasz cudzym kosztem to, co Typesense daje gotowe.
- **pgvector / Qdrant (wektorowe)** - dobre pod wyszukiwanie semantyczne, ale nie rozwiązuje prostego problemu literówek taniej, i dokłada pipeline do embeddingów. Sensowne dopiero, jeśli oprócz literówek zależy ci też na wyszukiwaniu "po sensie", a nie tylko po słowach kluczowych.

Jeśli chcesz, mogę przygotować szkic integracji Typesense z waszym Node backendem (schema, indexing, endpoint search).

**Rekomendacja: Typesense** (self-hosted albo Typesense Cloud).

Powód: typo tolerance i sensowny ranking (BM25 + odległość edycyjna + wagi pól) działają out of the box, bez strojenia analyzerów. Filtry i faceting są natywne i szybkie nawet przy kilkuset tysiącach dokumentów. Node ma oficjalne SDK, integracja to dosłownie kilkadziesiąt linii kodu. Do uruchomienia wystarczy jeden kontener Dockera, nie trzeba klastra ani osoby od relevance tuningu.

Co jeszcze brałem pod uwagę:

- **Meilisearch** - bardzo bliski konkurent, może nawet prostszy w onboardingu. Wybrałem Typesense głównie za dojrzalszy system filtrów/facetów przy większej liczbie pól, ale to decyzja blisko 50/50, oba są dobre.
- **Algolia** - najlepszy "zero myślenia o search" (hostowane, świetny typo tolerance i ranking), ale cena rośnie z liczbą rekordów i zapytań, plus lock-in na ich API. Sensowne, jeśli budżet nie gra roli.
- **Elasticsearch/OpenSearch** - odrzucone celowo. Silnik jest potężny, ale żeby dostać sensowny typo tolerance i ranking, trzeba ręcznie układać analyzery i tuningować relevance, czyli właśnie to, czego chcecie uniknąć bez zatrudniania search engineera.
- **Postgres (pg_trgm / tsvector, ewentualnie ParadeDB z BM25)** - opcja "żadnej nowej infrastruktury", filtry trywialne przez SQL. Ale typo tolerance przez trigramy jest słabsze niż w dedykowanym silniku, a ranking trzeba by budować ręcznie. Sensowne tylko jeśli operacyjnie chcecie zostać przy jednej bazie za wszelką cenę.

Przy kilkuset tysiącach dokumentów i braku dedykowanej osoby od search, Typesense/Meilisearch to punkt, w którym dostajecie 90% jakości Algolii za ułamek kosztu i bez ops-owego bagażu Elasticsearcha.

To ma zgłosić się do zatwierdzenia przez Ciebie, więc nie będę tego forsował, to poboczne sprawdzenie, przejdę od razu do odpowiedzi merytorycznej.

**Rekomendacja: Meilisearch.**

Ma typo tolerance, sensowny ranking i filtry działające "z pudełka", bez strojenia. Oficjalny klient Node, self-host jednym kontenerem albo Meilisearch Cloud, indeksowanie kilkuset tysięcy dokumentów to dla niego lekka praca. To dokładnie ten przypadek, na który jest projektowany: zespół bez search engineera dostaje dobre wyniki bez konfiguracji.

Co jeszcze rozważałem:

- **Algolia** - najlepsze relevance i typo tolerance na rynku, zero utrzymania (pełny SaaS), ale płacisz za rekordy i operacje, a przy kilkuset tysiącach dokumentów i częstych reindeksacjach koszt potrafi zaskoczyć; dane też wychodzą poza Waszą infrastrukturę.
- **Typesense** - bardzo zbliżony do Meilisearch (typo tolerance, filtry, prosty Node SDK), trochę lepszy przy geo/sortowaniu numerycznym; realna alternatywa, wybrałbym go, gdyby Meilisearch czegoś konkretnego nie pokrywał (np. potrzebne wektorowe/hybrid search - Typesense ma to bardziej dojrzałe).
- **Elasticsearch/OpenSearch** - odrzucone: silnik potężny, ale fuzziness, boosting i ranking trzeba ręcznie stroić, a do tego dochodzi utrzymanie klastra - to jest dokładnie ten koszt (search engineer), którego chcecie uniknąć.
- **Postgres (tsvector + pg_trgm)** - kuszące, bo nie dokłada nowego serwisu, ale typo tolerance przez trigramy jest słabsza niż w dedykowanym silniku, a sensowny ranking i tak wymaga ręcznego strojenia wag - to w gruncie rzeczy ten sam problem co dziś, tylko lepiej ukryty.

Główny kompromis: Meilisearch/Typesense to dodatkowa usługa do wdrożenia i utrzymania (choć lekka), w zamian za praktycznie zerowy nakład na strojenie relevance. Jeśli wolicie zero nowej infrastruktury i akceptujecie słabszą jakość wyszukiwania, Postgres + pg_trgm jest defensywnym wyborem tymczasowym.

Dla kilkuset tysięcy dokumentów i chęci uniknięcia zatrudniania search engineera postawiłbym na **Meilisearch** (self-hosted, open source, oficjalny klient Node) - typo tolerance i sensowne rankingowanie są wbudowane od razu, bez ręcznego tuningu BM25 czy analyzerów, a operacyjnie to pojedynczy binarny proces, lekki nawet przy tej skali. Główny kompromis: sami odpowiadacie za hosting, backupy i update'y (choć jest też Meilisearch Cloud, jeśli wolicie SaaS).

Co jeszcze brałem pod uwagę:
- **Typesense** - bardzo podobny profil do Meilisearch, też typo-tolerant out of the box; wybór między nimi to w praktyce rzut monetą, warto poredzić ekosystem/community.
- **Algolia** - najlepsze relevance i typo tolerance na rynku, zero utrzymania, ale płatny SaaS z cenami rosnącymi wraz z liczbą rekordów i zapytań, plus vendor lock-in.
- **Elasticsearch / OpenSearch** - najpotężniejszy, ale odrzuciłem: żeby dostać sensowny ranking i fuzzy matching, trzeba faktycznie umieć stroić analyzery i zapytania, czyli dokładnie to, czego chcecie uniknąć.
- **Postgres (pg_trgm / full-text search)** - zostałoby w istniejącej bazie, ale typo tolerance jest słabe, a ranking wymaga ręcznego układania tsvector/rank, więc też wraca problem "musicie to sami wykminić".

Jeśli chcecie, mogę doprecyzować pod wasz stack (self-hosted vs zero ops, budżet) i rozpisać plan integracji z Node backendem.