Il modello di costo di DynamoDB: perché SQL può nascondere la bolletta

Eseguire vero SQL su DynamoDB è potente — ottieni JOIN, GROUP BY e clausole WHERE arbitrarie su un database che nativamente non ne offre nessuna. Ma SQL è stato progettato per un motore con un query planner e indici secondari su ogni colonna, e DynamoDB non ha né l'uno né gli altri. Un SELECT perfettamente lecito può compilarsi in uno Scan dell'intera tabella che legge — e ti fattura — ogni item della tabella.

Questo è il doppio taglio dell'astrazione SQL: fa sembrare gratuiti i pattern di accesso costosi. Questa guida spiega il modello di costo sottostante, così la comodità non si trasforma mai in una bolletta a sorpresa, e mostra come DynoTable rende visibile il costo prima che tu esegua la query.

Perché SQL su DynamoDB costa più di quanto sembri?

Un database relazionale può rispondere a WHERE status = 'active' in modo efficiente perché costruisce un indice per qualsiasi colonna tu chieda. DynamoDB no. Risponde in modo efficiente su esattamente una cosa: la partition key (facoltativamente ristretta da una sort key o da un indice secondario globale). Qualsiasi altra cosa è uno Scan.

• Un'uguaglianza sulla partition key è una Query. DynamoDB salta dritto agli item sotto quella chiave e legge solo quelli. Limitata ed economica.
• Qualsiasi altra cosa è uno Scan + Filter. DynamoDB legge ogni item della tabella, poi applica il tuo WHERE come FilterExpression — dopo la lettura. Ti viene fatturato tutto ciò che ha scansionato, non la manciata di righe restituite.

Quest'ultimo punto è la trappola. Una clausola WHERE sembra restringere il lavoro. Su un attributo non chiave, restringe solo l'output — il costo di lettura è già stato speso.

Query vs Scan: la matematica delle RCU

DynamoDB fattura le letture in read capacity unit (RCU):

• 1 RCU = una lettura a coerenza forte di un item fino a 4 KB. Le letture a coerenza eventuale costano metà unità. Le letture vengono arrotondate per eccesso per ogni 4 KB.
• Una Query legge solo gli item sotto un'unica partition key — il costo scala con gli item corrispondenti, non con la tabella.
• Uno Scan legge l'intera tabella, 4 KB alla volta. Una tabella da 1 GB è all'incirca 262.000 RCU a coerenza eventuale per una singola passata completa — a ogni passata, ogni volta.

Una FilterExpression non riduce quel numero. Il filtraggio avviene dopo la lettura, quindi uno Scan filtrato costa esattamente quanto uno non filtrato. Calcola i numeri reali per i tuoi dati con il calcolatore della dimensione degli item e il calcolatore dei prezzi.

Quali costrutti SQL si trasformano silenziosamente in Scan?

• WHERE senza uguaglianza sulla partition key → uno Scan completo con un filtro post-lettura.
• JOIN → in DynamoDB non esiste alcun join lato server. Ogni tabella unita viene recuperata separatamente e ricucita lato client — un pattern di accesso N+1, una richiesta per ogni riga unita.
• COUNT, SUM, GROUP BY, aggregazioni → non esiste aggregazione lato server, quindi ogni item corrispondente viene letto. Su uno Scan, significa leggere l'intera tabella.
• ORDER BY o DISTINCT su un attributo non chiave → ordinamento e deduplicazione avvengono lato client su qualsiasi cosa sia stata scansionata.

Nessuno di questi è sbagliato da eseguire — a volte uno Scan è esattamente ciò che vuoi. Il punto è sapere quando ne stai eseguendo uno.

Come mantengo SQL onesto sui costi?

• Progetta le chiavi attorno ai tuoi pattern di accesso. La query più economica è quella a cui il tuo schema delle chiavi risponde già. Pianificala con lo strumento di single-table design e la guida Query vs Scan.
• Metti un'uguaglianza sulla partition key nella WHERE per ottenere una Query invece di uno Scan.
• Aggiungi una GSI per un secondo pattern di accesso invece di scansionare-e-filtrare.
• Leggi il costo prima di eseguire. Il Workbench di DynoTable compila il tuo SQL nell'operazione DynamoDB effettiva e mostra il piano — Scan vs Query, quale indice usa, la condizione sulla chiave rispetto al filtro post-Scan e un costo RCU stimato — poi segnala inline gli Scan completi e i join N+1. È l'EXPLAIN che DynamoDB non ha mai rilasciato. Vedi anche perché gli Scan sono lenti e costosi e capacità On-Demand vs Provisioned.

L'SQL di DynoTable peggiora il problema dei costi?

No — perché rende il costo visibile. La critica a SQL-su-DynamoDB è giusta: un'astrazione che nasconde gli Scan ti permette di spararti sui piedi. La risposta di DynoTable non è rimuovere l'SQL, ma metterci dietro una radiografia dei costi. Ogni query nel Workbench mostra in anteprima la sua reale forma DynamoDB prima di essere eseguita, così mantieni l'ergonomia di SQL e l'onestà su RCU e progettazione delle chiavi che ti dà il modello nativo.

Ho bisogno dell'agente AI per tutto questo?

No — il visualizzatore di tabelle, il Workbench SQL e l'anteprima del costo funzionano tutti pienamente senza di esso. L'agente AI è una delle funzionalità di punta di DynoTable — un agente di coding nativo per DynamoDB che scrive query consapevoli dello schema, trasforma i dati e altro ancora — ed è lì ogni volta che lo vuoi. Gira sul tuo AWS Bedrock, quindi paghi AWS direttamente al costo effettivo (nessun ricarico) e i tuoi dati non lasciano mai il tuo account. Attivalo quando serve; il client di base è completo in entrambi i casi.

Il mio lavoro è portabile?

Sì. DynoTable parla standard, non un giardino recintato: SQL standard, credenziali AWS e SSO standard, esportazione CSV/JSON, esportazione dello schema inferito in TypeScript, JSON-Schema o Zod, e un server MCP così che i tuoi strumenti e agenti possano connettersi. Le tue query, configurazioni e schemi si esportano in modo pulito — nulla resta bloccato.

Provalo

Scarica DynoTable e apri il Workbench SQL sulla tua tabella — l'anteprima del costo ti mostra quanto costa davvero ogni query prima che tu la esegua.