Do I need a separate index for search and filtering?

Not always.

Short answer:
You need a separate index for search and filtering if your current index can’t satisfy both efficiently. In many systems, one index can handle both if it’s designed well enough.

Usually:

• Search needs a full-text index (e.g., inverted index) for matching words, phrases, relevance scoring.
• Filtering often needs structured/field indexes (e.g., on status, category, date, price) for exact matches and range queries.

Common approaches

1. Single index / one system

   • Use one search engine index that stores:
     • text fields for full-text search
     • keyword/numeric/date fields for filtering
   • Good when search + filters are used together often.

2. Separate indexes

   • One optimized for full-text search
   • Another optimized for analytics/filtering or relational queries
   • Useful when requirements are very different, or scale/performance needs differ.

Rule of thumb

• If users do search + filter together on the same dataset, a single well-designed index is often enough.
• If filtering is mostly complex reporting/aggregation or search is heavy relevance-based text search, separate systems/indexes can be better.

Practical example

For a product catalog:

• title, description → search index
• brand, price, in_stock, category → filterable fields in the same index

So you don’t usually need a completely separate index for each — but you may need different field mappings/index strategies depending on the query patterns.

If you want, I can help you decide for your specific database or search stack (Postgres, Elasticsearch, Meilisearch, OpenSearch, MongoDB, etc.).