No single database holds the whole market
Every people database is compiled in its own way, from its own sources. Each one misses a share of any market, and they do not miss the same share. Most recruiters assume the big databases are near copies of one another. Run one search across three of them and the overlap turns out smaller than that assumption. The people found by only one source are a real part of the pool, and if you search a single database you never learn they exist.
This play is the plain version of coverage: one title set, one location and one set of must-haves, run across the databases and merged into one list. It does not look for people who describe the job in other words, and it does not map competitors. Map a whole talent pool does that. This one asks a narrower question: has everyone who carries this title in this place been seen?
Most of the work is translation, because the databases do not read a query the same way. One matches a word stem anywhere in a title. The others need the full words and return nothing on a stem. Two match a location as an exact string. One takes a single area value that covers a metro. Get that wrong and a database reports zero, which looks like an empty market and is a query fault.
What you get back
One CSV, one row per person, de-duplicated on the LinkedIn profile. Each row keeps a source column naming every database that returned the person, the dated work history used for scoring, the tier and the reason, and a personal email where one was found for the people who passed.
Beside it, the count per database and how far they overlapped, which tells you which database carries your niche. Nothing is sent and nothing is written to your ATS.
Variations worth knowing
Bring your own accounts. The lemlist people database and Apollo join the search only on your own connected accounts, billed by those vendors. Apollo's search rows hide the surname and the profile link until they are revealed, so they merge on less.
Stop at the pool. Skip contact details, and later load the shortlist into your ATS or a sequence.
Where this goes wrong
Reading a zero as an empty market. A zero from one database beside hundreds from another is a title or location format fault. The agent checks the query before it believes the count.
A narrow location list. Most people list the metro, not their suburb. A towns-only list drops the bulk of them. Wide beats narrow.
A radius that measures the employer. One database's radius filter runs from the employer's head office, not from where the person lives, so it is not used.
Strict keyword scoring. A missing skill keyword is not a missing skill. Plenty of thin profiles are real fits, so they are marked unknown and kept.
