Is Redshift a SQL or NoSQL database?

Redshift is a SQL database, not NoSQL: it is a relational, column-oriented data warehouse that runs standard SQL through an engine derived from PostgreSQL. Redshift uses PostgreSQL-compatible JDBC and ODBC drivers, the same connection standard used by other relational databases, not a NoSQL query API.

Where does the SQL vs NoSQL confusion come from?

Part of the confusion comes from Redshift's column-oriented storage, which sounds like the "column-family" model used by NoSQL databases such as Cassandra or HBase. The two are different concepts: Redshift's column store is a physical layout for a relational table with a fixed schema, while column-family NoSQL databases use a different data model without joins or a fixed schema across rows. Redshift also supports a SUPER data type for semi-structured, nested JSON-like data, queried through PartiQL, which looks schemaless but sits inside a SQL warehouse next to ordinary typed columns. And because AWS also runs DynamoDB, its actual NoSQL key-value and document database, the two products get mentioned in the same breath even though they solve different problems.

What does the market data show?

DB-Engines, which tracks database popularity worldwide, lists Amazon Redshift under relational database management systems, in the same category as PostgreSQL and Oracle, not under its document store, key-value store, or wide-column store categories. AWS documentation consistently describes Redshift as a SQL data warehouse, and its query planner, joins, and indexing concepts follow relational database theory rather than NoSQL's typical trade-offs around schema flexibility and horizontal partitioning.

What does this mean for hiring Redshift developers?

Because Redshift is relational, the skills that matter are the same ones needed for other SQL data warehouses: query optimization, schema design choices like distribution and sort keys, and building ETL pipelines that load structured data efficiently. That is a different skill set from NoSQL database work, where the focus shifts to partition key design, eventual consistency, and horizontal scaling patterns.