How would this work with single table designs? Because "Where" maps to a table, in a single-table pattern, would the syntax be less useful?
Using single table patterns, where you can read an item collection of multiple related (joined) items in a single read. With PartiQL, you seem to lose this ability.
So it seems to me that PartiQL would be slower for more demanding cases. Perhaps it is best for smaller, simpler apps?
Actually, I think partiQL will work quite well for single table patterns mainly because the WHERE is mapped to a partition key (whether its a primary partition key or a global secondary index). I don't know how complex your queries are normally, but for example, if I have a table I can easily write a simple query as follows:
SELECT * FROM "myTable"."mySecondaryIndex" WHERE "myParitionKey"='sth sth' and "mySortKey" = 'sth else'
In fact, it is the multi-table design that is not easy to implement in a single query bcz I don't think PartiQL implementation in dynamodb supports sub-queries at the moment, however, multi-table operations can be faciliated using dynamodb transactions.
In terms of performance, PartiQL performance is the same as current dynamoDB methods. There was a twitch session (DynamoDB office hours by Rick Houlihan) that was done around the 10th of December 2020, where Rick actually compared the performance of partiQL and dynamoDB API on a java app and he was running thousands of batch records, and the performance was the same.
I wanted to link to that twitch session but it seems it's currently archived, I already pinged Rick last week to see if they can put it back online.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
How would this work with single table designs? Because "Where" maps to a table, in a single-table pattern, would the syntax be less useful?
Using single table patterns, where you can read an item collection of multiple related (joined) items in a single read. With PartiQL, you seem to lose this ability.
So it seems to me that PartiQL would be slower for more demanding cases. Perhaps it is best for smaller, simpler apps?
Thanks for your comment Michael.
Actually, I think partiQL will work quite well for single table patterns mainly because the WHERE is mapped to a partition key (whether its a primary partition key or a global secondary index). I don't know how complex your queries are normally, but for example, if I have a table I can easily write a simple query as follows:
In fact, it is the multi-table design that is not easy to implement in a single query bcz I don't think PartiQL implementation in dynamodb supports sub-queries at the moment, however, multi-table operations can be faciliated using dynamodb transactions.
In terms of performance, PartiQL performance is the same as current dynamoDB methods. There was a twitch session (DynamoDB office hours by Rick Houlihan) that was done around the 10th of December 2020, where Rick actually compared the performance of partiQL and dynamoDB API on a java app and he was running thousands of batch records, and the performance was the same.
I wanted to link to that twitch session but it seems it's currently archived, I already pinged Rick last week to see if they can put it back online.