Ottobre 2026 è stato un mese intenso per i motori di dati. DuckDB 2.0 è uscito il 21 ottobre come versione a supporto lungo, Polars 2.1 il 25 ottobre e Apache Spark 4.3 il 30 ottobre. Sono tutti e tre gratuiti e open source, leggono tutti Parquet e Apache Iceberg e ormai parlano tutti SQL. Quale usare, allora? Abbiamo installato le nuove versioni, eseguito le stesse query sugli stessi 20 milioni di righe e annotato cosa abbiamo imparato.
Tre motori, tre progetti diversi
DuckDB 2.0
Database SQL in un file- Licenza
- MIT
- Stile
- prima di tutto SQL, con client Python, R, Java e Node
- Dove gira
- nel tuo processo, ora anche come piccolo server (Quack)
- SQL eccellente: join ASOF e NEAREST, trigger, MERGE, un tipo VARIANT veloce per il JSON
- Legge Parquet, CSV, JSON, Iceberg, Delta e DuckLake, in locale o dal cloud storage
- Supporto a lungo termine almeno fino a ottobre 2027
- Una sola macchina; shuffle molto grandi richiedono ancora attenzione
Ideale per chi usa SQL, notebook, backend di dashboard e analisi in locale.
Polars 2.1
Libreria DataFrame- Licenza
- MIT
- Stile
- espressioni Python, più un'interfaccia SQL in crescita
- Dove gira
- nel tuo processo, con motore streaming di default
- Veloce, rigoroso e prevedibile: tipi ed errori sono espliciti
- I group-by possono scrivere su disco quando la memoria finisce
- Scrive e gestisce tabelle Iceberg
- Richiede Python 3.11 o successivo; alcune API nuove sono instabili
Ideale per chi sviluppa in Python e vuole sostituire pandas.
Spark 4.3
Motore distribuito- Licenza
- Apache 2.0
- Stile
- SQL, DataFrame PySpark, Scala e Java
- Dove gira
- su cluster, da Databricks, Fabric, EMR, Dataproc o in proprio
- Scala su molte macchine, fino a centinaia di terabyte
- Streaming in tempo reale con stato, ora intorno a 150 ms P99
- Lo standard su Databricks e Microsoft Fabric
- Secondi di avvio e costo fisso per ogni query sui dati piccoli
Ideale quando una macchina non basta.
Il benchmark
Abbiamo generato un file Parquet con 20 milioni di righe di vendite (236 MB, quattro colonne) e una piccola tabella di 1.000 negozi, poi abbiamo eseguito due query in ogni motore, rileggendo ogni volta i file Parquet. Riportiamo la migliore di tre esecuzioni. La macchina era una VM cloud modesta con 2 core e 7 GB di memoria, quindi sulla tua i numeri assoluti saranno diversi: conta la classifica.
Migliore di 3 esecuzioni. DuckDB 2.0.0, Polars 2.1.0, pandas 3.1.0, PySpark 4.3.0 in modalità locale con 2 core. Ogni esecuzione legge il file Parquet.
Stessa macchina e stesso metodo. Il join aggiunge 1.000 righe di negozi a 20 milioni di righe di vendite.
Il quadro è chiaro. Su una sola macchina DuckDB e Polars giocano in un'altra categoria, e quale sia più veloce dipende dalla query: Polars è stato un po' più rapido nell'aggregazione con molti gruppi, DuckDB più del doppio più veloce nel join. pandas, che carica tutto in memoria prima, è stato da 2,5 a 8 volte più lento. Spark è risultato il più lento, ma è normale: è fatto per distribuire il lavoro su molte macchine, e con due core si misura soprattutto il suo costo di coordinamento.
Query piccole: dove si vede il costo fisso
La nuova impostazione Project Feather di Spark 4.3 ha ridotto la query minima da 85 a 53 ms saltando lo shuffle, un miglioramento reale per provare il codice su campioni. Ma DuckDB e Polars rispondono in circa un millisecondo, e avviare una sessione Spark locale ha richiesto 5,3 secondi prima di qualsiasi query. Se i tuoi dati stanno su un portatile, questa differenza si somma per tutto il giorno.
Oltre la velocità
| DuckDB 2.0 | Polars 2.1 | Spark 4.3 | |
|---|---|---|---|
| Interfaccia principale | SQL | Espressioni Python | SQL e PySpark |
| Più grande della memoria | Sì, scrive su disco | Sì, motore streaming e group-by su disco | Sì, su un cluster |
| Più grande di una macchina | No | No (open source) | Sì |
| Streaming | No | Streaming a lotti di file grandi | Sì, anche in tempo reale con stato |
| Formati di tabella aperti | Iceberg, Delta, DuckLake | Iceberg in lettura e scrittura, Delta | Iceberg e Delta, il motore di riferimento |
| Accesso condiviso | Nuova modalità server Quack | Solo nel processo | Spark Connect, cluster multiutente |
| Agenti AI per il codice | Modalità agente nella CLI che riduce i token in uscita | Errori chiari, tipi rigorosi | Feather velocizza il ciclo prova e correggi |
Come scegliere
- 1
Stima la tabella più grande
Sotto i 100 GB circa di Parquet basta di solito una sola macchina con DuckDB o Polars. Se arrivi ai terabyte, o cresci in fretta, pianifica Spark o un data warehouse in cloud.
- 2
Scegli in base alla lingua del team
Chi pensa in SQL è produttivo con DuckDB in un'ora. Chi sviluppa in Python preferirà le espressioni di Polars.
- 3
Guarda dove gira il lavoro
Se l'azienda usa Databricks o Microsoft Fabric, Spark c'è già ed è gestito, e i lavori piccoli possono comunque usare DuckDB o Polars negli stessi notebook.
- 4
Ti serve il tempo reale? Usa Spark
Né DuckDB né Polars elaborano flussi di eventi con stato. Spark 4.3 ora lo fa con una latenza intorno a un decimo di secondo.
- 5
Tieni i dati in formati aperti
Salva le tabelle in Parquet o Iceberg, così potrai cambiare motore senza migrare i dati.
Verifica cosa hai capito
1/3Nel nostro test di join e group-by su 20 milioni di righe, quale motore è stato il più veloce?
DuckDB ha impiegato 0,20 secondi, Polars 0,48, pandas 1,62 e Spark 1,83.
2/3Quando Spark è la scelta giusta rispetto a DuckDB o Polars?
La forza di Spark sono la scala e lo streaming; sui dati piccoli prevale il suo costo fisso.
3/3Cosa fa Project Feather in Spark 4.3?
Nel nostro test ha ridotto una query minima da 85 a 53 ms.
Hai risposto correttamente a 0 domande su 3.
Approfondisci: DuckDB 2.0, Polars 2.1, Spark 4.3, la guida rapida a Polars e come scegliere un database.
Fonti: annuncio di DuckDB 2.0.0 (21 ottobre 2026), note di rilascio di Polars 2.1 (25 ottobre 2026) e di Apache Spark 4.3.0 (30 ottobre 2026). I benchmark sono nostri, eseguiti il 9 novembre 2026 su una VM cloud con 2 core e 7 GB e dati sintetici; sono indicativi e non sostituiscono un test sul tuo carico di lavoro.
Alessandro Ecclesie AgazziScritto da Alessandro Ecclesie Agazzi, analytics engineer a Londra. Aggiornato il 9 novembre 2026. Chi sono