Can you use SQL-like querying in NoSQL systems?
Quick Answer
Yes, though the specifics vary widely by product — MongoDB has its own JSON-based query language and a powerful aggregation pipeline (conceptually similar to SQL's `WHERE`/`GROUP BY`/joins, expressed as a pipeline of stages), Cassandra has CQL (Cassandra Query Language, syntactically SQL-like but with important semantic restrictions), and some systems (like AWS's N1QL for Couchbase, or BigQuery/Presto over NoSQL-adjacent stores) support genuinely SQL-compatible querying directly. None of these fully replicate relational SQL's join capabilities or query optimizer sophistication, since the underlying storage model isn't relational.
Detailed Answer
MongoDB's query language and aggregation pipeline
Simple filtering uses a JSON-based query syntax:
db.orders.find({ status: "shipped", total: { $gt: 100 } });
More complex analytical queries use the aggregation pipeline — a sequence of stages, each transforming the data, conceptually similar to chaining SQL's WHERE → GROUP BY → HAVING → SELECT, but expressed as an explicit list of operations rather than a single declarative statement:
db.orders.aggregate([
{ $match: { status: "shipped" } }, // like WHERE
{ $group: { _id: "$customer_id", total: { $sum: "$amount" } } }, // like GROUP BY + SUM
{ $sort: { total: -1 } }, // like ORDER BY
{ $limit: 10 } // like LIMIT
]);
$lookup provides a join-like operation across collections, though it's generally less performant and less flexible than a relational join, and MongoDB's data modeling philosophy (see the embedding/referencing question) generally tries to minimize how often you need it in the first place.
Cassandra's CQL
Deliberately styled to look like SQL, which lowers the learning curve for SQL-familiar developers:
SELECT * FROM orders WHERE customer_id = 42;
But CQL has significant semantic restrictions compared to real SQL — most importantly, it doesn't support arbitrary joins or ad-hoc WHERE filtering on non-key columns efficiently (you generally must query by the partition key, reflecting how the data is actually physically distributed across the cluster) — a query that "looks like SQL" can still fail or perform terribly if it doesn't match Cassandra's underlying partitioning model.
Genuinely SQL-compatible layers over NoSQL-adjacent storage
Some systems provide a real SQL query layer on top of non-relational or semi-structured storage — Presto/Trino, AWS Athena (SQL over data in S3), Google BigQuery, or N1QL for Couchbase — letting analysts use full, familiar SQL (including real joins) against data that isn't stored in a traditional relational engine underneath.
The honest answer is "it depends heavily on the specific product" — no single universal "NoSQL SQL" exists, and syntactic similarity to SQL (as with CQL) doesn't guarantee semantic/performance similarity. A candidate who knows this nuance (and specifically that "SQL-like syntax" isn't the same as "relational query power") demonstrates real, hands-on familiarity rather than surface-level knowledge of product names.