The first time I needed to find something specific in Salesforce, I clicked through list views, added filters, removed them, scrolled, and gave up. Then a colleague showed me how to just ask the database directly. Within a minute I had exactly the records I wanted. That moment changed how I worked, and SOQL is the tool that made it possible.
SOQL stands for Salesforce Object Query Language. If you have ever heard of SQL, the language used by most databases, SOQL will feel familiar. But there is one important difference, and once you understand it, everything else clicks.
What SOQL actually does
SOQL is how you ask Salesforce a question and get back a precise set of records. Instead of clicking around, you describe what you want in a single sentence: give me these fields, from this object, where this condition is true.
The shape is always the same:
SELECT FirstName, LastName, Email
FROM Contact
WHERE LastName = 'Aksu'Read it out loud and it almost explains itself. Select the first name, last name, and email, from the Contact object, where the last name is Aksu. Salesforce hands you every matching record.
A few things to notice. You always list the specific fields you want after SELECT. There is no SELECT * in SOQL, you name what you need. FROM points at the object you are querying. And WHERE is your filter, the part that narrows thousands of records down to the handful that matter.
The one big difference from SQL
Here is the part that trips people up coming from traditional databases. SOQL does not query tables, it queries the Salesforce object model.
In a normal database you would write joins to connect tables together. In Salesforce, objects are already connected through relationships, and SOQL understands those relationships directly. You do not stitch tables together by hand, you walk the relationships that already exist between objects like Account and Contact.
SOQL is not just SQL with a different name. It is built for the object model, so the relationships between your data are part of the language itself.
If the object model still feels fuzzy, that is worth shoring up first. I wrote a full walkthrough in The Salesforce Object Model, and it pairs naturally with SOQL.
Querying across relationships
Because objects are connected, you can pull in fields from a related object without a join. Every Contact belongs to an Account, so you can reach up to the Account from a Contact query like this:
SELECT FirstName, LastName, Account.Name
FROM Contact
WHERE Account.Industry = 'Technology'That Account.Name is doing something quiet but powerful. From the Contact, you reached up to its parent Account and grabbed the company name. The dot is the relationship. You will use this constantly once it becomes second nature.
You can also go the other direction, from a parent down to its children, but that uses a slightly different shape with a nested query. Do not worry about that yet. Master the upward dot-walk first, it covers most of what beginners need.
Where you actually run a query
Reading about SOQL is one thing, running it is where it sticks. The simplest place to start is the Developer Console.
In any org, click the gear icon in the top right, then Developer Console. A new window opens. At the bottom, find the Query Editor tab. Paste a query there, click Execute, and your results appear in a grid right below. No code, no setup, just you and your data.
Start small. Query five contacts. Add a WHERE clause. Change a field. Break it on purpose and read the error message, because Salesforce error messages are usually telling you exactly what it expected. This is the fastest way I know to build real confidence.
A couple of helpful extras
Two keywords will make your early queries much more useful.
LIMIT caps how many records come back, which matters when an object holds thousands of rows:
SELECT Name, Industry
FROM Account
ORDER BY Name
LIMIT 10ORDER BY sorts the results, ascending by default. Together they let you grab a clean, readable slice instead of an overwhelming wall of records.
Why this matters beyond the console
SOQL is not just a console toy. It is the same language you will write inside Apex when you start building real automation. When your code needs to find related records before acting on them, it runs a SOQL query to get them. So the muscle you build now in the Query Editor carries directly into your first class.
That is the natural next step, and it is a smaller jump than you might expect once SOQL feels comfortable. The pattern is the same, you are just running the query from code instead of a window.
Teaching taught me that fluency comes from small, repeated reps, not from one heroic study session. The same is true here. A few short queries a day, and within a week you will reach for SOQL before you reach for a list view.
Your next step
When you are comfortable asking questions, you are ready to act on the answers in code. Continue with Your First Apex Class, where SOQL starts doing real work, and revisit The Salesforce Object Model if relationships still feel new. You can also browse more starting points in the Foundations category.