What Is SQL and What Is It Used For?

SQL (Structured Query Language) is the standard language for asking a relational database questions and for changing what it stores. You describe what you want — the customers in London, the orders over 500 dollars — and the database engine figures out how to produce those rows, using indexes, statistics and a query planner that a hand-written loop would never have.

That declarative split is the whole point. A procedural loop over a customer list must decide for itself which index to use and when to stop scanning; a query optimizer with accurate table statistics makes that decision from the data. SQL also gives you a transaction boundary, so a transfer can move money between two rows or change nothing at all.

CREATE TABLE customers (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  city TEXT NOT NULL
);

INSERT INTO customers (id, name, city) VALUES
  (1, 'Ada Lovelace', 'London'),
  (2, 'Grace Hopper', 'New York'),
  (3, 'Alan Turing', 'London');

SELECT city, COUNT(*) AS customer_count
FROM customers
GROUP BY city
ORDER BY customer_count DESC, city;

The result is two rows: London with 2 customers, New York with 1. The same statement shape answers payroll questions, inventory questions and reporting questions, which is why the language survives every change in storage engine. The trade-off is that SQL only reaches what the database exposes: you cannot ask it to hold a row lock while you make a third-party HTTP call, and a badly written query can move far more rows than you intended. Interviewers want to see that you understand the split between declaring intent and letting the engine plan the work.

Filter on a bounded range of dates rather than on a year function, and let an index on the date column do the work. A range can use an index range scan; wrapping the column in strftime('%Y', signup_date) forces the engine to read every row and then discard most of them.

CREATE TABLE signups (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  signup_date TEXT NOT NULL
);

INSERT INTO signups (id, name, signup_date) VALUES
  (1, 'Ada Lovelace', '2024-03-02'),
  (2, 'Grace Hopper', '2024-11-17'),
  (3, 'Alan Turing', '2023-12-31'),
  (4, 'Katherine Johnson', '2024-07-04');

SELECT name, signup_date
FROM signups
WHERE signup_date >= '2024-01-01'
  AND signup_date < '2025-01-01'
ORDER BY signup_date DESC;

Three rows come back: Grace Hopper on 2024-11-17, Katherine Johnson on 2024-07-04 and Ada Lovelace on 2024-03-02. Alan Turing is excluded because 2023-12-31 sits outside the half-open interval. Note the upper bound is deliberately '2025-01-01' and not '2024-12-31' — with a timestamp column, a midnight boundary would quietly drop rows recorded at exactly midnight on the final day.

Two details matter under review. The column stores ISO-8601 text, so lexicographic comparison matches chronological comparison and an index stays usable. And the sort is not fully deterministic: if two customers share a signup_date, add a tiebreaker such as id so repeated runs return a stable order for pagination.

SQL survives because the relational model is still the best answer to a specific question: how do I keep several tables consistent when many users read and write them at once? Referential integrity, unique constraints, multi-row transactions and a cost-based optimizer are decades of solved problems. A document store gives up the first three to gain a simpler write path and horizontal scaling that does not need a sharding plan.

Pick SQL when the data has real relationships. Orders, customers, payments and inventory have foreign keys and join conditions, and an analytics query over them almost always ends up joining anyway. Pick SQL when you need transactions: transferring money between two accounts must be atomic, and only a mature relational engine gives you that guarantee without hand-rolling a saga or an outbox table.

Pick the document store when the access pattern is genuinely one-document-at-a-time, the working set is enormous, and you can live with eventual consistency. A product catalogue read by key on every page view, written by a separate catalogue service, is a good fit. A ledger where a balance must never drift is not.

The honest interview answer is that most teams need both. The mistake to avoid is picking on vibes: choose relational semantics when the invariants matter, choose scale and access-pattern fit when they do not. In practice you can also get most of the way with a relational engine plus read replicas, partitioning and caching, so a document store is often a second step rather than a first one.