DynamoDB PartiQL vs SQL: cosa si rompe

La più grande fonte di confusione con il PartiQL di DynamoDB — per gli esseri umani come per gli assistenti AI — è trattarlo come SQL relazionale. Non lo è. PartiQL è una superficie compatibile con SQL sopra le operazioni che DynamoDB ha già, non un motore di query capace di unire, raggruppare o aggregare. Le parole chiave familiari nascondono una macchina molto diversa.

In cosa il PartiQL di DynamoDB è diverso da SQL?

PartiQL prende in prestito la sintassi di SQL ma non il suo motore. Su DynamoDB ogni istruzione mappa su una singola operazione nativa — GetItem, Query, Scan, PutItem, UpdateItem o DeleteItem — quindi non esistono JOIN, GROUP BY, subquery o aggregazioni. Si legge come SQL ma può fare solo ciò che quelle operazioni chiave-valore già fanno.

Ogni istruzione PartiQL si compila in una delle operazioni native di DynamoDB:

Non c'è alcun planner capace di leggere da due tabelle, costruire un hash join o ripiegare le righe in un COUNT. Se un'operazione non mappa su un singolo Get/Query/Scan/Put/Update/Delete, PartiQL semplicemente non sa esprimerla. È tutta qui la storia: tutto ciò che segue è una conseguenza di questo unico fatto.

La stessa mappatura, come flusso: è la clausola WHERE a decidere se un SELECT è una Query economica o uno Scan dell'intera tabella:

Ogni istruzione si risolve in esattamente un'operazione nativa: quella mappatura uno a uno è il motivo per cui PartiQL non può unire, raggruppare o aggregare.

Cosa cambia, funzionalità per funzionalità

Ovunque la colonna Workbench dica Sì contro un No di PartiQL, quello è un vuoto che il Workbench SQL di DynoTable colma. Il Workbench materializza le tue tabelle attraverso il runtime di query reale di DynamoDB ed esegue vero SQL al di sopra: SQL entro le regole dei pattern di accesso di DynamoDB.

Cosa si rompe, e perché

Questi sono i fallimenti che il validatore PartiQL di DynoTable segnala prima che la query arrivi sul filo — ognuno riconducibile a un vincolo reale di DynamoDB.

• SELECT * senza una chiave di partizione è uno Scan nascosto. PartiQL non dà errore: legge semplicemente ogni item e filtra dopo, il classico autogol di costo Query-vs-Scan dietro una sintassi amichevole.
• UPDATE / DELETE richiedono la chiave primaria completa. Mappano su un UpdateItem/DeleteItem su singolo item, quindi il WHERE deve fissare la chiave di partizione (e la chiave di ordinamento, su una tabella con chiave composita). Non puoi "aggiornare tutte le righe con status = 'open'" in una sola istruzione.
• I doppi apici sono identificatori, non stringhe. Il PartiQL di DynamoDB segue qui lo standard SQL: "name" è il nome di una colonna o di una tabella, 'name' è un valore stringa. Quotare un valore con i doppi apici è l'errore da principiante più comune — il messaggio del validatore è letteralmente "I doppi apici delimitano identificatori nel PartiQL di DynamoDB, non stringhe. Usa gli apici singoli per i valori stringa."
• IN usa le parentesi quadre, non quelle tonde: WHERE pk IN ['a','b'], con un tetto di 50 valori di PK / 100 valori non di chiave.
• Nessun JOIN, nessuna aggregazione. Non c'è un motore per combinare tabelle o ripiegare righe. È il compromesso del single-table-design: modelli in anticipo per i tuoi pattern di accesso perché il livello di query non può rimodellare i dati dopo.

Perché gli assistenti AI sbagliano

Gli LLM sono addestrati su oceani di SQL relazionale, quindi emettono con sicurezza JOIN, GROUP BY, LIKE, LIMIT inline e letterali stringa con doppi apici su DynamoDB — cose che DynamoDB rifiuta tutte. L'autofix delle query del modello di DynoTable esiste proprio perché i modelli economici producono in modo affidabile questi schemi: toglie gli apici con doppio escape, riscrive LIKE '%x%' → contains, IS NULL → attribute_not_exists e sposta il LIMIT inline nel parametro della richiesta. Se la tua AI genera "PartiQL" che si legge come Postgres, quello è l'indizio.

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"

Il Workbench SQL di DynoTable: le query che PartiQL non sa eseguire

Quando ti serve davvero un JOIN o un GROUP BY, la risposta è il Workbench SQL di DynoTable. Valida il lato di destinazione di ogni JOIN rispetto a una chiave di partizione, materializza le righe unite attraverso il runtime Query/Scan reale di DynamoDB e poi esegue al di sopra un singolo SELECT (aggregazioni, GROUP BY, DISTINCT, CASE, CAST): SQL entro le regole dei pattern di accesso di 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

Vincoli onesti (il Workbench impone il modello di accesso di DynamoDB, non finge di essere Postgres):

• Solo INNER JOIN e LEFT JOIN — l'attributo di destinazione dell'ON deve essere una chiave di partizione o una chiave di partizione di un GSI. Niente RIGHT / FULL / CROSS / join con la virgola.
• Niente self-join per ora, niente subquery, niente tabelle derivate, niente funzioni finestra.
• Join e proiezioni operano su attributi scalari.

Se ti serve solo comporre condizioni ed espressioni di chiave per l'API grezza, l'Expression Builder per DynamoDB genera la FilterExpression / KeyConditionExpression corretta senza passare affatto dalla superficie PartiQL. Per PartiQL fatto bene, guarda gli esempi PartiQL svolti; per stimare quanto costerà una query, usa il calcolatore della dimensione degli item. Nota che PartiQL non cambia mai il formato sul filo: i valori viaggiano comunque come DynamoDB JSON. Stai scegliendo un client? Guarda dove si colloca il Workbench rispetto a una normale GUI per DynamoDB o a Dynobase.

FAQ

PartiQL è la stessa cosa di SQL? No. PartiQL è un linguaggio di query compatibile con SQL, ma su DynamoDB espone solo operazioni che mappano su un singolo Get/Query/Scan/Put/Update/Delete. Non ha join, aggregazioni, subquery o GROUP BY.

Il PartiQL di DynamoDB può fare un JOIN? No. Il PartiQL di DynamoDB non può unire tabelle. Il Workbench SQL di DynoTable può eseguire INNER/LEFT JOIN (verso una chiave di partizione o una chiave di partizione di un GSI) materializzando i dati attraverso il runtime di query reale di DynamoDB.

Il PartiQL di DynamoDB supporta GROUP BY o COUNT? No: nel PartiQL di DynamoDB non ci sono aggregazioni né GROUP BY. Usa il Workbench SQL di DynoTable per le query con COUNT/SUM/AVG/GROUP BY/HAVING.

Perché il mio SELECT * costa così tanto? Senza una chiave di partizione nel WHERE, PartiQL esegue uno Scan dell'intera tabella e conteggia ogni item letto prima che il filtro venga applicato. Aggiungi un predicato sulla chiave di partizione per trasformarlo in una Query.

In PartiQL devo usare apici singoli o doppi? Apici singoli per i valori stringa ('CUSTOMER#42'), doppi apici per gli identificatori come i nomi di tabelle e attributi ("AppData"). Quotare un valore con i doppi apici è l'errore PartiQL più comune.

Pronto a eseguire vero SQL su DynamoDB? Scarica DynoTable e apri un tab Workbench.