DynamoDB PartiQL vs SQL: Apa yang Rusak

Sumber kebingungan terbesar dengan DynamoDB PartiQL — bagi manusia maupun asisten AI — adalah memperlakukannya sebagai SQL relasional. Ia bukan itu. PartiQL adalah permukaan kompatibel-SQL di atas operasi DynamoDB yang sudah ada, bukan mesin query yang bisa join, group, atau agregat. Kata kunci yang familiar menyembunyikan mesin yang sangat berbeda di baliknya.

Bagaimana DynamoDB PartiQL berbeda dari SQL?

PartiQL meminjam sintaks SQL tetapi bukan mesinnya. Di DynamoDB setiap pernyataan memetakan ke satu operasi native — GetItem, Query, Scan, PutItem, UpdateItem, atau DeleteItem — jadi tidak ada JOIN, GROUP BY, subquery, atau agregat. Ia terbaca seperti SQL tetapi hanya bisa melakukan apa yang sudah bisa dilakukan operasi key-value itu.

Setiap pernyataan PartiQL dikompilasi turun menjadi salah satu operasi native DynamoDB:

Tidak ada planner yang bisa membaca dari dua tabel, membangun hash join, atau melipat baris menjadi sebuah COUNT. Jika sebuah operasi tak memetakan ke satu Get/Query/Scan/Put/Update/Delete, PartiQL cukup tak bisa mengekspresikannya. Itulah seluruh ceritanya — semua di bawah ini adalah konsekuensi dari satu fakta ini.

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

Setiap pernyataan diselesaikan menjadi tepat satu operasi native — pemetaan satu-ke-satu itulah alasan PartiQL tak bisa join, group, atau agregat.

Apa yang berbeda — fitur demi fitur

Di mana pun kolom Workbench berkata Ya melawan Tidak PartiQL, itulah celah yang ditutup SQL Workbench DynoTable. Workbench memmaterialisasi tabel-tabel Anda lewat runtime query nyata DynamoDB lalu menjalankan SQL nyata di atasnya — SQL di dalam aturan pola akses DynamoDB.

Apa yang rusak, dan kenapa

Ini adalah kegagalan yang ditandai validator PartiQL DynoTable sebelum query pernah mencapai kabel — masing-masing berpangkal pada kendala DynamoDB yang nyata.

• SELECT * tanpa partition key adalah Scan tersembunyi. PartiQL tak akan error; ia hanya membaca setiap Item dan memfilter sesudahnya, yang merupakan footgun biaya Query-vs-Scan klasik di balik sintaks yang ramah.
• UPDATE / DELETE butuh primary key lengkap. Mereka memetakan ke sebuah UpdateItem/DeleteItem satu-Item, jadi WHERE harus mengunci partition key (dan sort key, pada tabel composite-key). Anda tak bisa "update 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. Menge-quote sebuah nilai dengan tanda kutip ganda adalah kesalahan pemula paling umum — pesan validator secara harfiah "Double quotes delimit identifiers in DynamoDB PartiQL, not strings. Use single quotes for string values."
• IN memakai kurung siku, bukan kurung biasa: WHERE pk IN ['a','b'], dibatasi 50 nilai PK / 100 nilai non-key.
• Tanpa JOIN, tanpa agregat. Tak ada mesin untuk menggabungkan tabel atau melipat baris. Ini tradeoff single-table-design: Anda memodelkan untuk pola akses Anda di muka karena lapisan query tak bisa membentuk ulang data setelah fakta.

Kenapa asisten AI salah soal ini

LLM dilatih atas lautan SQL relasional, jadi mereka dengan percaya diri memancarkan JOIN, GROUP BY, LIKE, LIMIT inline, dan literal string berkutip-ganda terhadap DynamoDB — yang semuanya ditolak DynamoDB. Autofix model-query DynoTable sendiri ada justru karena model murah secara andal menghasilkan pola-pola ini: ia menghapus tanda kutip yang double-escaped, 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, itu tandanya.

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 tak bisa dijalankan PartiQL

Saat Anda benar-benar butuh sebuah JOIN atau GROUP BY, SQL Workbench DynoTable adalah jawabannya. Ia memvalidasi sisi-tujuan setiap JOIN terhadap sebuah partition key, memmaterialisasi baris-baris yang di-join lewat runtime Query/Scan nyata DynamoDB, lalu menjalankan satu SELECT (agregat, GROUP BY, DISTINCT, CASE, CAST) di atasnya — SQL di 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

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

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

Jika Anda hanya perlu menyusun kondisi 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 terpandu; untuk mengukur berapa biaya sebuah query, gunakan kalkulator ukuran Item. Perhatikan bahwa PartiQL tak pernah mengubah format kabel — nilai tetap melintas sebagai DynamoDB-JSON. Memilih klien? Lihat di mana Workbench berdiri melawan GUI DynamoDB biasa atau Dynobase.

FAQ

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

Bisakah DynamoDB PartiQL melakukan JOIN? Tidak. DynamoDB PartiQL tak bisa join tabel. SQL Workbench DynoTable bisa menjalankan INNER/LEFT JOIN (ke sebuah partition key atau GSI partition key) dengan memmaterialisasi data lewat runtime query nyata DynamoDB.

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

Kenapa SELECT * saya berbiaya mahal? Tanpa partition key di WHERE, PartiQL menjalankan full-table Scan dan memetering setiap pembacaan Item sebelum filter berlaku. Tambahkan predikat partition-key untuk mengubahnya menjadi sebuah Query.

Haruskah saya pakai 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"). Menge-quote sebuah nilai secara ganda adalah kesalahan PartiQL paling umum.

Siap menjalankan SQL nyata terhadap DynamoDB? Unduh DynoTable dan buka sebuah tab Workbench.