DynamoDB PartiQL vs SQL: Apa yang Berbeda (dan Apa yang Rusak)

Sumber kebingungan terbesar dengan DynamoDB PartiQL — baik bagi manusia maupun asisten AI — adalah memperlakukannya sebagai SQL relasional. Padahal bukan. PartiQL adalah permukaan yang kompatibel dengan SQL di atas operasi DynamoDB yang sudah ada, bukan mesin query yang dapat melakukan join, group, atau agregasi. Kata kunci yang familier menyembunyikan mesin yang sangat berbeda di baliknya.

Model mental

Setiap pernyataan PartiQL dikompilasi menjadi salah satu operasi native DynamoDB:

Tidak ada planner yang dapat membaca dari dua tabel, membangun hash join, atau melipat baris menjadi sebuah COUNT. Jika sebuah operasi tidak dipetakan ke satu Get/Query/Scan/Put/Update/Delete tunggal, PartiQL sama sekali tidak dapat menyatakannya. Itulah keseluruhan ceritanya — semua yang ada di bawah adalah konsekuensi dari satu fakta ini.

Pemetaan yang sama, sebagai alur — klausa WHERE menentukan apakah sebuah SELECT adalah Query yang murah atau Scan seluruh tabel:

Setiap pernyataan terselesaikan menjadi tepat satu operasi native — pemetaan satu-ke-satu itulah mengapa PartiQL tidak dapat melakukan join, group, atau agregasi.

Apa yang berbeda — fitur demi fitur

Setiap yang dapat dijalankan oleh SQL Workbench DynoTable ditandai. Workbench memmaterialisasi tabel Anda melalui runtime query DynamoDB yang sebenarnya dan menjalankan SQL sungguhan di atasnya — SQL dalam aturan pola akses DynamoDB.

Apa yang rusak, dan mengapa

Inilah kegagalan yang ditandai validator PartiQL DynoTable sebelum query pernah mencapai jaringan — masing-masing berakar pada batasan DynamoDB yang sesungguhnya.

• SELECT * tanpa partition key adalah Scan tersembunyi. PartiQL tidak akan error; ia hanya membaca setiap Item dan memfilter setelahnya, yang merupakan footgun biaya Query-vs-Scan klasik di balik sintaks yang ramah.
• UPDATE / DELETE membutuhkan primary key lengkap. Keduanya dipetakan ke UpdateItem/DeleteItem satu-Item, jadi WHERE harus menyematkan partition key (dan sort key, pada tabel dengan composite key). Anda tidak dapat "memperbarui semua baris di mana status = 'open'" dalam satu pernyataan.
• Tanda kutip ganda adalah identifier, bukan string. DynamoDB PartiQL mengikuti standar SQL di sini: "name" adalah nama kolom/tabel, 'name' adalah nilai string. Mengutip sebuah nilai dengan tanda kutip ganda adalah kesalahan pemula yang paling umum — pesan validatornya secara harfiah berbunyi "Double quotes delimit identifiers in DynamoDB PartiQL, not strings. Use single quotes for string values."
• IN menggunakan tanda kurung siku, bukan tanda kurung biasa: WHERE pk IN ['a','b'], dibatasi hingga 50 nilai PK / 100 nilai non-key.
• Tanpa JOIN, tanpa agregat. Tidak ada mesin untuk menggabungkan tabel atau melipat baris. Inilah tradeoff single-table-design: Anda memodelkan untuk pola akses Anda di awal karena lapisan query tidak dapat membentuk ulang data setelahnya.

Mengapa asisten AI salah memahami ini

LLM dilatih pada lautan SQL relasional, sehingga mereka dengan percaya diri mengeluarkan JOIN, GROUP BY, LIKE, LIMIT inline, dan literal string berkutip ganda terhadap DynamoDB — yang semuanya ditolak DynamoDB. Autofix query-model milik DynoTable sendiri ada justru karena model murah secara andal menghasilkan pola-pola ini: ia melepas tanda kutip yang di-escape ganda, menulis ulang LIKE '%x%' → contains, IS NULL → attribute_not_exists, dan mengangkat LIMIT inline ke parameter request. Jika AI Anda menghasilkan "PartiQL" yang terbaca seperti Postgres, itulah pertandanya.

SELECT o.id, c.name
FROM orders o
JOIN customers c ON o.customerId = c.PK

SELECT country, COUNT(*) AS orders, SUM(total) AS revenue
FROM orders
GROUP BY country

SELECT * FROM orders
WHERE customerId IN (SELECT PK FROM customers WHERE country = 'ES')

SELECT PK FROM orders
UNION
SELECT PK FROM archived_orders

SELECT * FROM orders

UPDATE orders SET status = 'shipped'
WHERE status = 'open'

SELECT * FROM users WHERE "name" = "Alice"

SQL Workbench DynoTable: query yang tidak bisa dijalankan PartiQL

Ketika Anda benar-benar membutuhkan sebuah JOIN atau GROUP BY, SQL Workbench DynoTable-lah jawabannya. Ia memvalidasi sisi-tujuan setiap JOIN terhadap sebuah partition key, memmaterialisasi baris yang di-join melalui runtime Query/Scan DynamoDB yang sebenarnya, lalu menjalankan SQL Anda sepenuhnya (agregat, GROUP BY, DISTINCT, CASE, CAST) di atasnya — SQL dalam aturan pola akses DynamoDB.

-- Runs in the DynoTable Workbench (NOT in PartiQL):
SELECT c.country, COUNT(*) AS orders, SUM(o.total) AS revenue
FROM orders o
INNER JOIN customers c ON o.customerId = c.PK
GROUP BY c.country
ORDER BY revenue DESC

Batasan yang jujur (Workbench menegakkan model akses DynamoDB, ia tidak berpura-pura menjadi Postgres):

• Hanya INNER JOIN dan LEFT JOIN — atribut-tujuan ON harus berupa partition key atau partition key GSI. Tanpa RIGHT / FULL / CROSS / comma-join.
• Belum ada self-join, tanpa subquery, tanpa derived table, tanpa window function.
• Join dan proyeksi beroperasi pada atribut skalar.

Jika Anda hanya perlu menyusun condition dan key expression untuk API mentah, DynamoDB Expression Builder menghasilkan FilterExpression / KeyConditionExpression yang benar tanpa permukaan PartiQL sama sekali. Untuk PartiQL yang dilakukan dengan benar, lihat contoh PartiQL yang sudah dikerjakan; untuk mengukur biaya query mana pun, gunakan kalkulator ukuran Item. Perhatikan bahwa PartiQL tidak pernah mengubah format wire — nilai tetap berjalan sebagai DynamoDB-JSON. Memilih klien? Lihat di mana posisi Workbench dibandingkan dengan GUI DynamoDB biasa atau Dynobase.

FAQ

Apakah PartiQL sama dengan SQL? Tidak. PartiQL adalah bahasa query yang kompatibel dengan SQL, tetapi pada DynamoDB ia hanya mengekspos operasi yang dipetakan ke satu Get/Query/Scan/Put/Update/Delete. Ia tidak memiliki join, agregat, subquery, atau GROUP BY.

Bisakah DynamoDB PartiQL melakukan JOIN? Tidak. DynamoDB PartiQL tidak dapat melakukan join tabel. SQL Workbench DynoTable dapat menjalankan INNER/LEFT JOIN (ke partition key atau partition key GSI) dengan memmaterialisasi data melalui runtime query DynamoDB yang sebenarnya.

Apakah DynamoDB PartiQL mendukung GROUP BY atau COUNT? Tidak — tidak ada agregat atau GROUP BY di DynamoDB PartiQL. Gunakan SQL Workbench DynoTable untuk query COUNT/SUM/AVG/GROUP BY/HAVING.

Mengapa SELECT * saya begitu mahal? Tanpa partition key di WHERE, PartiQL menjalankan Scan seluruh tabel dan mengukur setiap Item yang dibaca sebelum filter diterapkan. Tambahkan predikat partition-key untuk mengubahnya menjadi sebuah Query.

Haruskah saya menggunakan tanda kutip tunggal atau ganda di PartiQL? Tanda kutip tunggal untuk nilai string ('CUSTOMER#42'), tanda kutip ganda untuk identifier seperti nama tabel dan atribut ("AppData"). Mengutip nilai dengan tanda kutip ganda adalah kesalahan PartiQL yang paling umum.

Siap menjalankan SQL sungguhan terhadap DynamoDB? Unduh DynoTable dan buka sebuah Tab Workbench.