Search implementation expertise covering full-text search, indexing strategies, relevance scoring, faceted search, autocomplete, fuzzy matching, search analytics, and Elasticsearch/Typesense/Meilisearch patterns.
Use when the user asks about search engineer, search engineer best practices, or needs guidance on search engineer implementation.
Do NOT use when the user needs a different specialized skill or is asking about an unrelated technology domain.
Search implementation expertise covering full-text search, indexing strategies, relevance scoring, faceted search, autocomplete, fuzzy matching, search analytics, and Elasticsearch/Typesense/Meilisearch patterns.
Use when the user asks about search engineer, search engineer best practices, or needs guidance on search engineer implementation.
Do NOT use when the user needs a different specialized skill or is asking about an unrelated technology domain.
Design and implement search systems that deliver fast, relevant results. This skill covers search engine selection, indexing strategies, relevance tuning, autocomplete, faceted search, and operational monitoring.
Search Engine Selection
Decision Matrix
ENGINE BEST FOR COMPLEXITY COST
------------------------------------------------------------
PostgreSQL FTS Simple search, < 1M docs Low Free
Meilisearch Typo-tolerant, instant Low Free/Hosted
Typesense Fast, easy setup Low Free/Hosted
Elasticsearch Complex queries, logs High Resource-heavy
OpenSearch AWS ecosystem High Resource-heavy
Algolia Hosted, instant UX Low Pay per search
DECISION TREE:
Do you need search beyond simple LIKE queries?
NO -> PostgreSQL LIKE with trigram index
YES -> How many documents?
< 100K -> Meilisearch or Typesense
100K - 10M -> Any engine (based on feature needs)
> 10M -> Elasticsearch / OpenSearch
Do you need:
Log aggregation + search? -> Elasticsearch
Instant autocomplete? -> Meilisearch or Typesense
Complex aggregations? -> Elasticsearch
Simple full-text? -> PostgreSQL FTS
Hosted with zero ops? -> Algolia
PostgreSQL Full-Text Search
Basic Setup
-- Add tsvector column for searchALTER TABLE products ADDCOLUMN search_vector tsvector;
-- Populate search vector with weighted fieldsUPDATE products SET search_vector =
setweight(to_tsvector('english', coalesce(name, '')), 'A') ||
setweight(to_tsvector('english', coalesce(description, '')), 'B') ||
setweight(to_tsvector('english', coalesce(category, '')), 'C');
-- Create GIN index for fast searchCREATE INDEX idx_products_search ON products USING gin(search_vector);
-- Auto-update triggerCREATEOR REPLACE FUNCTION products_search_trigger() RETURNStriggerAS $$
BEGIN
NEW.search_vector :=
setweight(to_tsvector('english', coalesce(NEW.name, '')), 'A') ||
setweight(to_tsvector('english', coalesce(NEW.description, '')), 'B') ||
# ... (condensed) ...
ts_headline('english', description, query,
'StartSel=<mark>, StopSel=</mark>, MaxWords=35, MinWords=15'
) AS highlighted_description
products, plainto_tsquery(, ) query
search_vector @@ query
rank
LIMIT ;
Trigram Search (Fuzzy Matching)
-- Enable extensionCREATE EXTENSION IF NOTEXISTS pg_trgm;
-- Create trigram indexCREATE INDEX idx_products_name_trgm ON products USING gin(name gin_trgm_ops);
-- Fuzzy search with similarity scoreSELECT name, similarity(name, 'blutooth hedphones') AS sim
FROM products
WHERE name %'blutooth hedphones'ORDERBY sim DESC
LIMIT 10;
-- Combine FTS with trigram for best resultsSELECT id, name,
ts_rank(search_vector, tsquery) *2+ similarity(name, :query) AS combined_score
FROM products, plainto_tsquery('english', :query) AS tsquery
WHERE search_vector @@ tsquery OR name % :query
ORDERBY combined_score DESC
LIMIT 20;
FIELD BOOSTING:
Title/Name: 3x boost (most relevant)
Tags/Keywords: 2x boost
Description: 1x boost (default)
Comments/Notes: 0.5x boost
FRESHNESS BOOST:
Items < 7 days: 1.5x boost
Items < 30 days: 1.2x boost
Older items: 1x (no boost)
POPULARITY BOOST:
Based on view count, sales, ratings
Logarithmic scale to prevent runaway popular items
PERSONALIZATION:
Boost items in user's preferred categories
Boost items from followed brands/authors
Demote previously viewed items (freshness)
Search Quality Metrics
KEY METRICS TO MONITOR:
Click-Through Rate (CTR):
Percentage of searches resulting in at least one click.
Target: > 60%
Mean Reciprocal Rank (MRR):
1 / position_of_first_clicked_result, averaged.
Target: > 0.5 (users typically click top 2 results)
Zero Result Rate:
Percentage of searches returning no results.
Target: < 5%
Refinement Rate:
Percentage of searches followed by another search (indicates poor results).
Target: < 30%
Time to First Click:
How quickly users find and click a relevant result.
Target: < 5 seconds
Indexing Strategy
Keeping Index in Sync
STRATEGY 1: Real-time sync (event-driven)
Database change -> Event -> Update search index
Latency: < 1 second
Best for: User-facing search requiring freshness
STRATEGY 2: Batch sync (scheduled)
Cron job -> Query changed records -> Update search index
Latency: Minutes to hours
Best for: Catalog search, analytics
STRATEGY 3: Change Data Capture (CDC)
Database WAL -> Debezium -> Search index
Latency: < 5 seconds
Best for: High-volume, reliable sync without application changes
Query suggestions from popular and recent searches
Index sync strategy defined (real-time, batch, or CDC)
Highlighting configured for search result previews
Pagination implemented (offset or search-after)
Search analytics tracking (CTR, zero results, refinements)
Rate limiting on search endpoints
Zero-downtime reindex strategy documented
Monitoring covers query latency, index size, sync lag
When to Use
Use this skill when:
Designing or implementing search engineer solutions
Reviewing or improving existing search engineer approaches
Making architectural or implementation decisions about search engineer
Learning search engineer patterns and best practices
Troubleshooting search engineer-related issues
Do NOT use this skill when:
The question is about a fundamentally different technology domain
A more specific sibling skill covers the exact topic needed
The user needs a complete hands-on tutorial rather than expert guidance
Output Format
# Search Engineer Analysis## Context Assessment
[Situation summary and constraints]
## Recommended Approach
[Primary recommendation with rationale]
## Implementation Steps1. [Step with specific details]
2. [Step with specific details]
3. [Step with specific details]
## Trade-offs and Considerations- [Key trade-off 1]
- [Key trade-off 2]
## Next Steps- [Immediate action item]
- [Follow-up action item]
Example
Input: "Help me implement search engineer for a medium-scale production application"
Output: A structured analysis covering current state assessment, recommended search engineer approach with specific patterns, implementation roadmap with milestones, and risk mitigation strategies tailored to the application scale and constraints.
Edge Cases
Legacy system integration: When search engineer must coexist with legacy approaches, provide a gradual migration path rather than a complete rewrite
Scale mismatch: When the solution complexity exceeds the project scale, recommend a simpler approach and note when to revisit
Team skill gaps: When the team lacks experience with the recommended approach, include learning resources and simpler alternatives
Conflicting requirements: When constraints conflict (e.g., performance vs. maintainability), explicitly state the trade-off and recommend based on stated priorities