# Dovod demo: choosing search for a support knowledge base
Real documentation research for an illustrative brief. Sources checked 2026-09-06. No engine benchmark has been run.
---
## E1
# The trial must justify adding another service
**Illustrative brief, not customer testimony.** A support agent searches for “change billing email” and misses “Update invoice contact”. The sample knowledge base contains English and German articles and already stores content in PostgreSQL.
## Decision and owner
The illustrative technical lead must decide whether to keep database search or trial Meilisearch and Typesense before introducing another service. The real deliverable is a reviewable website demonstration; no production engine migration is authorized or proposed.
## Criteria fixed before comparison
Hard gates: preserve document access restrictions, support the sample English/German corpus, and demonstrate that edited content can become searchable. Missing evidence means an open gate, not a pass.
Priority order: expected-article relevance first; freshness and recovery next; implementation and operating effort after those gates. No weighted score is assigned without observations. Keep PostgreSQL as the status quo; prefer it if the agreed tests pass and no documented gap justifies another service.
## Unknowns
Actual corpus, traffic, latency budget, operating hours and budget ceiling are unavailable. The sample queries are test fixtures, not production logs. The comparison must not claim a cheapest or fastest engine.
---
## E2
# PostgreSQL remains a viable baseline to test
**Reported by primary project documentation; checked 2026-09-06.** PostgreSQL 18 documents full-text matching, ranking and language configurations. Its `pg_trgm` extension provides similarity matching, and the documentation describes using it alongside full-text search for misspelled words.
Sources: [Full-text introduction](https://www.postgresql.org/docs/18/textsearch-intro.html) and [pg_trgm, Text Search Integration](https://www.postgresql.org/docs/18/pgtrgm.html#PGTRGM-TEXT-SEARCH).
## Implication for this brief
Do not eliminate the existing database merely because typo handling is required. Include a documented PostgreSQL configuration in the trial. This is an inference from available mechanisms, not a measured quality result.
## What the sources do not establish
They do not show that the expected article ranks in the top three for our sample queries, that our German content is handled well, or that the baseline is cheaper to maintain. The sample spelling-suggestion approach also needs its word list maintained.
## What could change the decision
Reject the baseline if a fair configuration fails the agreed relevance or access tests and a candidate passes them with acceptable operating effort. See the criteria in [E1](#e1).
---
## E3
# Meilisearch documents typo tolerance, but relevance remains untested
**Reported by vendor documentation; checked 2026-09-06.** Meilisearch documents configurable typo tolerance enabled by default. Its asynchronous-operation guide describes task states including enqueued, processing, succeeded and failed.
Sources: [Typo tolerance](https://www.meilisearch.com/docs/capabilities/full_text_search/relevancy/typo_tolerance_settings) and [Asynchronous operations](https://www.meilisearch.com/docs/capabilities/indexing/tasks_and_batches/async_operations).
## Implication for the trial
Record the tested version and typo settings. For an article update, track the indexing task to completion and then check the search result; submission alone is not our freshness test.
## Remaining evidence
We have not run this candidate on the sample corpus. Ranking quality, language behavior, authorization integration, update delay and recovery effort remain open. The documented mechanisms are not proof of performance or lower maintenance cost.
## Regret to avoid
Choosing an engine because a misspelled query works in a tiny example, while overlooking irrelevant results or stale restricted content. Evaluate it against the same gates as [E1](#e1) and the baseline in [E2](#e2).
---
## E4
# Typesense exposes typo controls that need an explicit test configuration
**Reported by vendor API documentation, version 29.0; checked 2026-09-06.** Typesense documents `num_typos` per query or field, minimum word lengths for typo correction, and token-dropping behavior.
Source: [Search API — typo-tolerance parameters](https://typesense.org/docs/29.0/api/search.html#typo-tolerance-parameters).
## Implication for the trial
Record the exact server version, schema, queried fields and search parameters. Inspect the returned articles as well as the result count: relaxed matching is not itself evidence that the answer is useful.
## Remaining evidence
No Typesense benchmark has been run here. English/German relevance, freshness, access-control integration and operating effort have not been measured. This source describes API behavior for its named version, not a recommendation to deploy that version or a claim that it is the latest.
## Regret to avoid
Comparing a tuned candidate with an untuned baseline, or reporting a successful request as a successful support search. Use the requirements in [E1](#e1) and document tuning effort for all candidates.
---
## E5
# A lower hosting bill does not establish lower operating cost
**Hypothesis under review:** “A separate search service will be cheaper to operate.” This is an illustrative claim introduced to demonstrate review, not a vendor quote or a measured finding.
## The review question
What does “operate” include: hosting, synchronizing articles, indexing failures, backups, recovery drills, access filters, upgrades and engineering time?
## Revised conclusion
We do not have comparable measurements for those items. The cost claim is unsupported and must not choose the engine. [E3](#e3) identifies an indexing task lifecycle to handle; [E2](#e2) identifies a baseline spelling-suggestion design that also has maintenance work. Neither source quantifies our costs.
## Next evidence
For each tested configuration, record deployment work, update handling, recovery steps and the time spent by the person running them. Keep hosting charges separate from engineering time; do not combine them without an explicit rate and period.
**Decision impact:** retain cost as an open question. The current proposal is a bounded trial, not a claim that one candidate wins.
---
## E6
# Run the same queries and update checks for every candidate
**Proposed trial; not executed.** Use the same permitted sample articles and queries for PostgreSQL, Meilisearch and Typesense. Record versions, hardware, full configuration and tuning time. Seed fixtures are illustrative; add actual permitted queries before making a production decision.
| Query | Expected article | Purpose |
| --- | --- | --- |
| change billing email | Update invoice contact | Different vocabulary |
| reset pasword | Reset your password | Misspelling |
| Rechnung herunterladen | Rechnung herunterladen | German exact-language baseline |
## Acceptance proposal
The expected article should appear among the first three results for each agreed fixture. Inspect irrelevant results too. Change one article, observe when the changed text becomes searchable, then delete it and check removal. Test an unauthorized identity against a restricted article. Record observations as pass, fail or not run with supporting output.
Freshness and latency thresholds require a real team requirement; leave them unset rather than inventing a service-level target. Repeat the tests with a representative corpus before extrapolating.
## Decision gate
If the baseline passes the agreed requirements, keep it unless another evidenced constraint justifies replacement. If it fails, compare passing candidates and operating effort. If all fail, revise the approach. Link all results back to [E1](#e1), [E2](#e2), [E3](#e3) and [E4](#e4).
---
## E7
# ADR 001 — keep the baseline while preparing a search trial
**Status: proposed next step. Engine selection remains open.** Prepared 2026-09-06 for an illustrative support-search scenario using real documentation research.
## Context
The sample team needs better article discovery and already uses PostgreSQL. Its constraints and criteria are in [E1](#e1).
## Options considered
PostgreSQL full-text search with an explicitly documented typo-handling approach [E2](#e2), Meilisearch [E3](#e3), and Typesense [E4](#e4). No candidate has passed the application-specific gates yet.
## Decision
Keep the baseline in place and prepare the common trial in [E6](#e6) before adding a separate search service. This is a research recommendation for the sample scenario, not an approved production change.
## Reasoning
Documentation establishes mechanisms worth testing. It does not establish relevance on our corpus or total operating cost. The cost assertion was challenged in [E5](#e5) and remains unsupported.
## Consequences
A comparison can proceed without a premature migration. The next work is to supply representative content, agree freshness and latency expectations, and collect comparable observations. There is no engine winner or fabricated benchmark table.
## Revisit
The illustrative technical lead reviews this record after the trial results and operating-effort notes are attached. Change the recommendation if the baseline fails an agreed requirement that another candidate meets. No calendar deadline is invented without a real trial owner.
---
## Open tasks
- [ ] Run the representative search trial before choosing an engine
- [ ] Revisit ADR 001 when comparable trial results are attached