Algolia or Sendora — pick the trade-off, not the marketing.
Algolia is unmatched on ranking-tuning depth + typo tolerance + synonyms — and is a separate vendor you sync each corpus into. Sendora Search federates across the 4 tables your tenant already holds — `profiles`, `support_tickets`, `kb_articles`, `events` — with one query, no sync code. Implementation is intentionally simple: Postgres `ILIKE '%term%'` per column, no fuzzy match, no ranking tuning, no synonyms. If search IS your product (marketplace, jobs board, commerce), keep Algolia. If you need "find a user / ticket / KB hit fast" from one box that's already in the tenant, this is the right shape and the per-record bill is zero.
Best-in-class search index — typo tolerance, synonyms, Custom Ranking, Personalization. Per-index pricing. Sync your data in.
Federated `ILIKE` substring match across 4 in-tenant indexes — zero sync code, no second bill. Honest about not being Algolia.
Side-by-side
| Capability | Algolia | Sendora |
|---|---|---|
| Typo tolerance + synonyms | ✅ (industry-leading) | ❌ — explicit substring only |
| Ranking tuning UI (Custom Ranking, Personalization) | ✅ best-in-class | ❌ — score=1 hardcoded today |
| Faceted filters | ✅ rich (multi-attribute) | Type-only (`profiles | tickets | articles | events`) |
| A/B index testing | ✅ | ❌ |
| Edge eval latency | <50ms typing-feedback | Postgres roundtrip — 50-200ms in-region |
| Federated across multiple corpora natively | Multi-index queries (still synced) | ✅ 4 tables, zero sync code |
| Indexes profiles / events / KB / tickets | All require sync code per corpus | ✅ built-in — same tenant |
| Pricing model | Per-record + per-search; usage-based | Bundle, no per-record cost |
Why teams switch to Sendora
- If you'd otherwise sync the same 4 tables into Algolia just for an ops command palette, the per-record bill is wasted — substring match on the same tenant is enough.
- New rows are searchable immediately — no sync window, no webhook glue, no eventual consistency.
- Same auth + RBAC as the rest of Sendora — no separate Algolia API key + ACL to manage.
When Algolia is the right call
- Search IS your product (marketplace, jobs board, commerce, docs). Algolia's ranking depth + edge latency are load-bearing.
- You need typo tolerance / synonyms — your users mistype "recieve" and expect "receive" hits. Sendora won't help.
- You need Custom Ranking, Personalization, or A/B index testing — Sendora has none of these.
Common questions
Does Sendora Search match Algolia's ranking depth?
No. Result `score` is hardcoded to 1 today — there's no ranking tuning, no Custom Ranking, no Personalization, no A/B testing. If you need any of that, keep Algolia for that corpus.
Typo tolerance?
No. Implementation is Postgres `ILIKE '%term%'` — case-insensitive substring only. Misspellings won't match. Users have to be explicit.
What CAN I search?
Four columns across four tables: `profiles.email` + `profiles.name`, `support_tickets.subject`, `kb_articles.title`, `events.event_type`. Body / properties / metadata is NOT searched today.
Latency?
Postgres roundtrip — typically 50-200ms in-region. Algolia's edge eval beats this for typing-feedback UX. For ops command palette this is fine; for end-user search box it depends.
Can I index data that doesn't live in Sendora?
Not today. The 4 indexed columns are fixed in code. If you need to index a product catalog or external corpus, you'd either keep Algolia for that or write the rows into `profiles` / `events` so they're searchable here.
Does Sendora replace Algolia DocSearch?
Functionally yes — embed via Sendora KB module. UI polish is closer to a basic Algolia setup than DocSearch's purpose-built UI. Roadmap item to close the gap.
Search
One query box across Customers + Tickets + KB articles + Events — case-insensitive substring match, zero sync code.
Algolia is unmatched on typo tolerance + synonyms + ranking-tuning depth — and is a separate vendor you sync each corpus into. Sendora Search federates across the 4 indexes your tenant already holds — `profiles`, `support_tickets`, `kb_articles`, `events` — with one query, no sync code, no second bill. Implementation is honest: Postgres `ILIKE '%query%'` matching, type-filter facets, no ranking tuning, no typo tolerance, no synonyms. The win is platform federation + zero-sync, not feature parity with Algolia. If you need best-in-class ranking, keep Algolia for that corpus. If you need "find a customer / ticket / KB article fast" from one box, this is the right shape.
Switch from Algolia. Keep your weekend.
Free plan covers real product use, no credit card. Bulk hash import for auth, CSV import for profiles, schema-validated event import for analytics — Data Sync module handles the migration in a day.