TL;DR

Full-text search is a database search technique that queries the actual content of text fields - resumes, notes, job descriptions, email bodies - rather than just structured metadata like job titles or dates. In recruitment, it's what separates a system that can find "all candidates who mentioned Kubernetes in their resume" from one that can only filter by the skills tags someone manually entered. For databases with millions of candidate records, full-text search capability is one of the most operationally significant features in an ATS.

How Full-Text Search Works

Traditional database queries match exact values in specific fields. A SQL query WHERE job_title = 'Software Engineer' finds candidates with that exact title. Full-text search indexes the content of documents - entire resume texts, cover letter bodies, interview notes - and builds a data structure (an inverted index) that maps every significant word to the records containing it. A search for "Kubernetes" finds every candidate whose resume text contains that word, regardless of which field it appears in or whether anyone thought to tag it.

The inverted index is what makes full-text search fast at scale. Instead of scanning every resume looking for the word "Kubernetes," the search engine looks up "Kubernetes" in the index and immediately gets a list of document IDs. Building and maintaining this index is the infrastructure challenge. Elasticsearch and Solr are the dominant open-source search engines used to power full-text search in enterprise applications. Bullhorn, Greenhouse, and other major ATS platforms use Elasticsearch (or equivalent) under the hood to power their candidate search.

Relevance scoring separates full-text search from a simple keyword match. When a recruiter searches for "Python developer with machine learning experience," the search engine doesn't just return all documents containing any of those words - it ranks results by how closely and frequently the terms appear in the document, which fields they appear in (a job title match weighs more than a mentions-in-passing in a cover letter), and how rare the terms are across the corpus. This is TF-IDF scoring (Term Frequency-Inverse Document Frequency), and it's why the top results of a good full-text search feel meaningfully more relevant than the bottom results.

Boolean operators and proximity queries extend full-text search for power users. A search for "machine learning" AND Python NOT entry-level returns candidates who mention both machine learning (as a phrase) and Python, excluding anyone who mentions entry-level. Proximity queries like "React" NEAR "5 years" find documents where those terms appear close together. Most ATS platforms expose simplified versions of these operators through their search interface, though the sophistication varies widely.

Why It Matters in Recruitment

A candidate database is only as useful as the search that lets you find what's in it. Staffing agencies with 500,000 candidate records are sitting on a valuable asset that becomes worthless if the search can't surface the right person when a job order lands. The entire business case for maintaining and cleaning a candidate database rests on the assumption that you can actually find relevant candidates quickly. Poor full-text search capability turns that database into a liability that costs money to maintain but doesn't generate placements.

The gap between ATS platforms on search quality is significant and under-discussed. Recruiters often attribute difficulty finding candidates to their database quality when the real problem is the search engine. A recruiter manually tagging skills on every candidate record to compensate for poor full-text search is doing infrastructure work that the tool should handle. When evaluating an ATS, running a set of benchmark searches against a sample database is more revealing than watching a vendor demo on clean data.

For high-volume staffing environments, search speed also matters. A recruiter working 20 active job orders simultaneously runs dozens of candidate searches per day. Each search that takes 10 seconds instead of 1 second adds up to a meaningful portion of the recruiter's day. Bullhorn's high-volume staffing customers, for example, run searches across databases with millions of records and expect sub-second response times. Achieving that at scale requires significant infrastructure investment in search index sharding and caching.

Full-Text Search in Practice

A [staffing agency](/glossary/staffing-agency) specializing in financial technology placements receives a job order for a risk analyst with Basel III regulatory experience and Python scripting skills. Their recruiter opens Bullhorn and types "Basel III" AND Python in the candidate search. Bullhorn's Elasticsearch index returns a ranked list of candidates whose resumes contain both terms, with candidates who mention Basel III in a dedicated compliance section ranked above those with passing references in a job description bullet point.

The recruiter reviews the top 15 results, shortlists 4, and calls them within 20 minutes of receiving the job order. None of these candidates had "Basel III" as a manually entered skill tag - the term appeared only in the raw text of their resumes. Without full-text search, the recruiter would have needed to search for candidates tagged with "Regulatory Compliance" or "Risk Management" and manually reviewed dozens of records to find the relevant experience.

Key Considerations