Frequently Asked Questions

  1. 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, Amazon DynamoDB, Amazon Glue Elastic Views, Amazon IoT TwinMaker) with more AWS services and third party database engines to follow.

  2. 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.

  3. How do you pronounce PartiQL?

    It is pronounced like the English word 'particle'.

  4. 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.

  5. 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.

  6. 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.

  7. 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 partiql-lang-kotlin Github issues and partiql-lang-rust GitHub Issues for details or add anything you find missing to help out.

  8. 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.

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

    The LET clause (following the FROM clause) was introduced in PartiQL Kotlin v0.2.3. More information on its syntax and usage can be found in this GitHub issue. We will add this to the formal specification in the near future.

  10. 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).