Why SQL?

The query interface is the most visible design choice in the library. We considered three options.

Approach	Example	Trade-offs
SQL	SELECT * FROM products WHERE price > 100	Universal, well understood, tooling exists
Pandas-like	df[df.price > 100]	Pythonic but Python-only, no standard
Builder pattern	query.select("*").where(price__gt=100)	Type-safe but verbose, with a learning curve

We chose SQL because:

1. Universality. SQL is the lingua franca of data. Developers, analysts, and tools all speak it.
2. No new DSL to learn. Users already know SQL. A pandas-like API requires learning our specific dialect.
3. Tooling compatibility. SQL strings can be generated by ORMs, query builders, or AI assistants.
4. Clear mapping. SQL semantics map reasonably well to RediSearch operations: SELECT to LOAD, WHERE to filter, GROUP BY to GROUPBY.

The downside is losing Python type checking and IDE support, but for a query interface, the universality trade-off is worth it.