FAQs

What is PartiQL?

PartiQL is a query language that provides SQL-compatible query access across multiple data stores containing structured data, semi-structured data, and nested data. It is widely used within Amazon and now available as part of many AWS services (Amazon S3 Select, Amazon Glacier Select, Amazon Redshift Spectrum, Amazon Quantum Ledger Database) with more AWS services and third party database engines to follow.

When should I use PartiQL?

You should use PartiQL when the SQL language is cumbersome to support nested or semi-structured data. You should also use PartiQL when you think you may change how your data is formatted or where it resides. Finally, you should use PartiQL when you have schema-less data or your schema evolves over time.

How do you pronounce PartiQL?

It is pronounced like the English word ‘particle’.

Why develop another query language instead of supporting an existing language extension?

We developed PartiQL in response to our own needs at Amazon, querying and transforming vast amounts of data. We looked at many existing languages but none met all of our needs for SQL compatibility, minimal extensions, optional schema and query stability, format independence, and data store independence. See our Open Source Charter for more details.

What data formats & data models can I use with PartiQL?

Essentially any tabular or hierarchical format, with or without schema, can be mapped into PartiQL using an appropriate serializer/deserializer. Relational data is also modeled since PartiQL is backward compatible with standard SQL.

What does it mean that PartiQL is backward-compatible with SQL?

PartiQL extends the SQL-92 specification. SQL-92 provides a good common base across databases and data processing engines as it is a well-understood and well-supported version of the SQL standard.

What parts of the specification are not implemented by the reference implementation?

The goal is to implement all of it, but of course, this is a work in progress. Please refer to the Github issues for details or add anything you find missing to help out.

What about other SQL data types that are either in later standards or common extensions (e.g. map)?

We will be evaluating how to add them in, common ones should be added.

What about a LET clause for introducing non-ranging variables outside of FROM?

We will be adding this to both the specification and the reference implementation.

Why do you choose Ion to extend SQL’s type system over?

Amazon Ion has a strong type system and covers most nested data format types (e.g. JSON). PartiQL is not tied to the Ion format per se, it just incorporates its type system, which has strong numeric types (that line up nicely to SQL).

Will you add Ion’s s-expression type to PartiQL?

This is basically a list/array with a distinct type. Ion has this type to allow for expression data to be distinct from lists. From a PartiQL perspective, this type operates like an array. In future revisions we will fold this into the specification formally.