SOQL queries one object at a time and gives you exact control over fields, filters, and relationships. SOSL searches across multiple objects at once, using a text index instead of a WHERE clause. Pick SOQL when you know exactly which object and fields you need. Pick SOSL when you have a search term and no idea where it lives.
Developers new to Salesforce treat these as interchangeable. They are not. Using the wrong one does not just cost you elegance, it costs you performance, governor limits, and sometimes correctness. Get the rule straight once and you stop guessing.
SOQL, Salesforce Object Query Language, looks like SQL and behaves like it. You write SELECT, FROM, WHERE, ORDER BY, and you get back records from one object, optionally with related child or parent records through relationship queries. It supports aggregate functions like COUNT and SUM, subqueries, and GROUP BY. It is precise. If you know the object is Account and the filter is Industry = 'Technology', SOQL is the only sane choice.
SOSL, Salesforce Object Search Language, does something structurally different. You write FIND, give it a search term, and tell it which objects and fields to look in, or let it search everything. It runs against Salesforce's search index rather than scanning table rows. It returns a list of lists, one list per object type, not a single flat result set. It is built for one job: find where a term shows up when you do not know where to look.
SOQL wins whenever the shape of your data is known ahead of time. Need every Opportunity closing this quarter above $50,000, grouped by owner? That is an aggregate SOQL query, and SOSL cannot do it at all, it has no GROUP BY, no SUM, no AVG. Need an Account with its related Contacts and Opportunities in a single call? That is a relationship query with subqueries, again SOQL-only territory.
SOQL also respects field-level security and sharing rules the way you would expect from a structured query, and it lets you filter on any indexed or unindexed field. The tradeoff is that filtering on unindexed text fields with LIKE '%term%' forces a full table scan. On a 2 million row object that query will time out or crawl. That is the exact situation where people reach for SOQL out of habit when SOSL was built for it.
SOSL exists for one scenario: you have a search term, phone number, email, name fragment, and you need to find every place it appears, possibly across five different objects, without writing five separate queries. Global search boxes, duplicate-detection screens, and support-console lookups are the textbook use cases. Behind the scenes, Salesforce maintains a search index across designated searchable fields, and SOSL queries that index directly instead of touching the underlying tables row by row.
That indexing is why SOSL beats SOQL on raw text search speed at scale. A FIND query for "acme" across Account, Contact, and Lead in one call returns matches from all three in a single trip to the server. Try to replicate that with SOQL and you are writing three separate queries with LIKE clauses, each one a potential table scan, each one counting separately against your query limit.
Salesforce caps both, and the caps are different enough to change your architecture decisions. A synchronous transaction allows 100 SOQL queries and a single SOQL query can return up to 50,000 rows. SOSL is capped at 20 search queries per transaction, and the total records returned across all objects in a single SOSL call maxes out at 2,000.
| Aspect | SOQL | SOSL |
|---|---|---|
| Searches | One object per query | Multiple objects per query |
| Query limit per transaction | 100 (sync) / 200 (async) | 20 |
| Max rows returned | 50,000 | 2,000 total |
| Aggregate functions | Yes (SUM, COUNT, AVG, GROUP BY) | No |
| Best for | Known object, exact filters, relationships | Unknown location, fuzzy text match |
That 2,000-row ceiling on SOSL matters more than people think. If you are building a search feature expecting thousands of matches, SOSL will silently truncate. SOQL will not, but it will happen to be the wrong tool if what you actually needed was cross-object text search in the first place. Know the ceiling before you design around it.
Picture a support agent typing a customer's phone number into a global search bar. The number could belong to a Contact, a Lead, or a Case comment. Writing this in SOQL means three queries minimum, each scanning a phone field that is rarely indexed for LIKE performance. One SOSL call, FIND against Contact, Lead, and Case, returns everything in one round trip and one governor-limit hit instead of three.
Now flip it. A finance dashboard needs every closed-won Opportunity from Q3, summed by product family, filtered by region. There is no text search here at all, just structured filtering and aggregation. SOSL cannot sum anything. This is pure SOQL, and reaching for SOSL here would be actively wrong, not just suboptimal.
The pattern holds everywhere: if the question is "where does this term appear," think SOSL. If the question is "give me records matching these exact conditions," think SOQL. Most real Salesforce features end up using both, SOSL to find the record, SOQL to pull its full detail once you have the ID.
The most frequent mistake is using SOQL with a leading wildcard, LIKE '%acme%', on a large text field. That pattern cannot use a standard index because the match could start anywhere in the string. On a small object it is invisible. On an object with hundreds of thousands of rows it turns into a full table scan and a slow query, sometimes a timeout. That exact query is what SOSL's search index was designed to replace.
The second mistake runs the other way: using SOSL when you actually needed relationship data or aggregation. SOSL returns lists of sObjects with a limited field set by default, and it does not traverse relationships the way a SOQL subquery does. Teams sometimes bolt a SOSL search onto a report-style feature, hit the wall on aggregation, then rewrite the whole thing in SOQL. Decide up front whether the requirement is search or filter, and the rewrite never happens.
A smaller but real mistake: forgetting that SOSL only searches fields marked as searchable, and standard text fields are searchable by default but some custom field types are not. If a SOSL query is quietly missing results, check the field's searchability before assuming the index is broken.
SOQL is a filter. SOSL is a search. If you already know the object and the exact condition, SOQL every time. If you have a term and multiple possible homes for it, SOSL every time. Anyone who tells you it is more nuanced than that is usually solving a problem that needs both, in sequence, not one language doing the other's job.
No. SOSL cannot perform aggregate functions like SUM or COUNT, cannot use GROUP BY, and returns a maximum of 2,000 records across all objects in a single call. Any feature requiring precise filtering, relationship traversal, or data aggregation needs SOQL, not SOSL.
A LIKE '%term%' pattern with a leading wildcard cannot use a standard database index because the match could start anywhere in the field. On large objects this forces a full table scan, which gets slower as the record count grows. SOSL avoids this because it queries a pre-built search index instead of scanning rows.
A single transaction allows 20 SOSL queries, compared to 100 synchronous SOQL queries. The total number of records returned across all objects in one SOSL search is also capped at 2,000, which matters for high-volume search features.
No, SOSL only searches fields marked as searchable, and you can further scope a query to specific fields using the IN clause. Standard text fields are searchable by default, but some custom field configurations are not, which can cause SOSL results to look incomplete.
A common pattern uses SOSL to locate a record by a fuzzy search term, such as a phone number or partial name, across multiple objects, then uses SOQL to pull that specific record's full detail and related data by ID. This combination gets fast, indexed search plus precise, relationship-aware retrieval.