PartiQL di DynamoDB vs SQL: cosa cambia (e cosa si rompe)

La singola fonte di confusione più grande con PartiQL di DynamoDB — per gli umani e gli assistenti AI allo stesso modo — è trattarlo come SQL relazionale. Non lo è. PartiQL è una superficie SQL-compatibile sopra le operazioni esistenti di DynamoDB, non un motore di query capace di fare join, raggruppare o aggregare. Le parole chiave familiari nascondono una macchina molto diversa sotto.

Il modello mentale

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

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

La stessa mappatura, come flusso — la clausola WHERE decide 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ò fare join, raggruppare o aggregare.

Cosa cambia — funzione per funzione

Ogni che il Workbench SQL di DynoTable può eseguire è segnato. Il Workbench materializza le tue tabelle attraverso il vero runtime di query di DynamoDB ed esegue vero SQL sopra — SQL all'interno delle regole di access pattern di DynamoDB.

Cosa si rompe, e perché

Questi sono i fallimenti che il validatore PartiQL di DynoTable segnala prima che la query raggiunga la rete — ognuno riconduce a un vincolo reale di DynamoDB.

• SELECT * senza una partition key è uno Scan nascosto. PartiQL non darà errore; legge semplicemente ogni item e filtra dopo, che è il classico tranello di costo Query-vs-Scan dietro una sintassi amichevole.
• UPDATE / DELETE richiedono la chiave primaria completa. Si mappano su un UpdateItem/DeleteItem su singolo item, quindi il WHERE deve fissare la partition key (e la sort key, su una tabella a chiave composita). Non puoi "aggiornare tutte le righe dove status = 'open'" in una sola istruzione.
• Le virgolette doppie sono identificatori, non stringhe. PartiQL di DynamoDB segue lo standard SQL qui: "name" è un nome di colonna/tabella, 'name' è un valore stringa. Mettere tra virgolette doppie un valore è l'errore da principianti più comune — il messaggio del validatore è letteralmente "Double quotes delimit identifiers in DynamoDB PartiQL, not strings. Use single quotes for string values."
• IN usa le parentesi quadre, non quelle tonde: WHERE pk IN ['a','b'], con un limite di 50 valori PK / 100 valori non-key.
• Niente JOIN, niente aggregati. Non c'è alcun motore per combinare tabelle o ridurre le righe. Questo è il compromesso del single-table-design: modelli per i tuoi access pattern in anticipo perché il livello di query non può rimodellare i dati a posteriori.

Perché gli assistenti AI sbagliano questo

Gli LLM sono addestrati su oceani di SQL relazionale, quindi emettono con sicurezza JOIN, GROUP BY, LIKE, LIMIT inline e letterali stringa tra virgolette doppie contro DynamoDB — tutte cose che DynamoDB rifiuta. L'autofix delle query del modello di DynoTable esiste proprio perché i modelli economici producono in modo affidabile questi pattern: rimuove le virgolette 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 sta generando "PartiQL" che si legge come Postgres, quello è il segnale.

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 può eseguire

Quando ti serve davvero un JOIN o un GROUP BY, il Workbench SQL di DynoTable è la risposta. Valida il lato di destinazione di ogni JOIN contro una partition key, materializza le righe unite attraverso il vero runtime Query/Scan di DynamoDB, poi esegue il tuo SQL completo (aggregati, GROUP BY, DISTINCT, CASE, CAST) sopra — SQL all'interno delle regole di access pattern 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 partition key o una partition key GSI. Niente RIGHT / FULL / CROSS / comma-join.
• Niente self-join per ora, niente subquery, niente derived table, niente window function.
• Join e proiezioni operano su attributi scalari.

Se ti serve solo comporre condizioni ed espressioni di chiave per l'API grezza, il DynamoDB Expression Builder genera le corrette FilterExpression / KeyConditionExpression senza la superficie PartiQL del tutto. Per PartiQL fatto bene, vedi gli esempi PartiQL svolti; per dimensionare quanto costerà una query, usa il calcolatore di dimensione item. Nota che PartiQL non cambia mai il formato di rete — i valori viaggiano comunque come DynamoDB-JSON. Stai scegliendo un client? Vedi come si colloca il Workbench rispetto a una GUI DynamoDB semplice o a Dynobase.

FAQ

PartiQL è uguale a SQL? No. PartiQL è un linguaggio di query SQL-compatibile, ma su DynamoDB espone solo operazioni che si mappano su un singolo Get/Query/Scan/Put/Update/Delete. Non ha join, aggregati, subquery o GROUP BY.

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

PartiQL di DynamoDB supporta GROUP BY o COUNT? No — non ci sono aggregati o GROUP BY in PartiQL di DynamoDB. Usa il Workbench SQL di DynoTable per query COUNT/SUM/AVG/GROUP BY/HAVING.

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

Dovrei usare virgolette singole o doppie in PartiQL? Virgolette singole per i valori stringa ('CUSTOMER#42'), virgolette doppie per gli identificatori come nomi di tabella e attributo ("AppData"). Mettere un valore tra virgolette doppie è l'errore PartiQL più comune.

Pronto a eseguire vero SQL contro DynamoDB? Scarica DynoTable e apri una scheda Workbench.