Via Indipendenza
La vera domanda non è quale software scegliere. È quanto vi costerà uscirne
Ogni volta che un'azienda sceglie un software — un gestionale, una piattaforma di analytics, un CMS, un data warehouse — sta anche scegliendo quanto sarà difficile e costoso cambiarlo in futuro. Questa seconda scelta viene quasi sempre ignorata, perché avviene implicitamente, nei dettagli del contratto e nei formati dei dati, non nell'interfaccia che si vede durante la demo.
Abbiamo scritto molto di AI nelle ultime settimane: modelli che si aggiornano ogni mese, prezzi che cambiano, fornitori americani spenti per decreto e poi riaccesi. Quella volatilità è il segnale più chiaro di un principio che vale per tutta l'architettura software di un'azienda: la resilienza non sta nel scegliere lo strumento giusto oggi. Sta nel costruire sistemi che permettano di cambiare strumento domani senza perdere i dati, senza riscrivere tutto, senza dipendere dalla buona volontà del fornitore attuale.
Questo numero è dedicato interamente agli strumenti e alle architetture che costruiscono quella resilienza: il paradigma del dato come prodotto, i formati aperti per lo storage analitico, gli strumenti di trasformazione dati open source per team piccoli, e la filosofia headless per i contenuti. Nessuna di queste è una moda tecnica. Tutte rispondono alla stessa domanda: come costruire infrastruttura che dura — e che lascia liberi.
Un numero diverso, dedicato alle fondamenta. In cinque minuti.
📐 Architettura del datoIl problema che Gartner chiama "data mesh" — e che in realtà riguarda chi è responsabile dei dati in azienda
Il 75% delle organizzazioni adotterà approcci di tipo data mesh entro il 2026 a causa dei limiti di scalabilità delle piattaforme centralizzate. Il dato è di Gartner. Ma la previsione — formata prima che le aziende iniziassero davvero a sperimentarlo — può essere fuorviante, perché "data mesh" suona come una tecnologia da comprare. Non lo è.
Il dato come prodotto è un paradigma organizzativo prima ancora che tecnologico. L'idea di base: i dati di vendita sono capiti meglio dal team vendite che da un team di data engineering centrale. I dati di produzione sono capiti meglio dal reparto produzione. Se la responsabilità della qualità, della documentazione e della manutenzione di quei dati viene lasciata a un team centrale — spesso distante dai processi che li generano — si creano inevitabilmente silos, dati inconsistenti, pipeline fragili e dataset che nessuno sa davvero interpretare.
La risposta del data mesh è spostare quella responsabilità verso i domain team — chi produce i dati diventa anche chi garantisce la loro qualità, accessibilità e documentazione. Il team vendite non aspetta che un ingegnere del dato trasformi i suoi dati in un formato usabile: li espone come un prodotto con un contratto — un SLA, una struttura stabile, una semantica chiara.
I quattro principi del data mesh — in parole concrete:
1. Ownership per dominio. Chi produce i dati è responsabile della loro qualità e accessibilità. Il team logistica possiede e gestisce i dati logistici — non li cede a un team centrale che li trasforma.
2. Il dato come prodotto. Ogni dataset deve avere documentazione, SLA (aggiornamento entro X ore), schema stabile e un responsabile raggiungibile. Non un file CSV su una condivisione di rete: un prodotto con un contratto.
3. Piattaforma self-service. I team di dominio devono poter pubblicare e consumare dati senza attendere la disponibilità di un ingegnere centrale. L'infrastruttura deve essere abbastanza semplice da usare in autonomia.
4. Governance federata. Regole globali (privacy, sicurezza, compliance) applicate centralmente — ma implementazione e manutenzione rimangono nei domain team. Non anarchia: standard condivisi con autonomia locale.
Per le PMI italiane il messaggio pratico è più semplice del modello teorico: prima di costruire qualsiasi architettura dati, chiedete chi è responsabile della qualità di ogni dato critico per il business. Se la risposta è "il team IT" o "il consulente", avete già il problema che il data mesh cerca di risolvere.
Fonti: ZeroUnoWeb, Gartner, Alation, Medium/CodeX — 2026
🔧 Open Source e ComposableApache Iceberg: il formato aperto che separa i vostri dati dal vendor che li elabora
Immaginate di avere anni di dati analitici — vendite, produzione, magazzino, clienti — in un data warehouse di un grande fornitore. Un giorno il fornitore cambia i prezzi, viene acquisito, o semplicemente smette di essere la scelta giusta per voi. Quanto vi costa uscire? Se i dati sono in formato proprietario, la risposta è: moltissimo. Bisogna esportare tutto, trasformarlo, reimportarlo altrove. Mesi di lavoro, rischio di perdita o corruzione dei dati, costi di migrazione che rendono il cambiamento praticamente impossibile.
Apache Iceberg è la risposta tecnica a questo problema. È un formato di tabella aperto — non è uno storage, non è un database, non è un motore di calcolo. È uno strato di metadati che si posiziona sopra i vostri file di dati, archiviabili dove volete (S3, Azure Blob, Google Cloud Storage, un NAS aziendale), e li rende leggibili da qualsiasi motore di calcolo: Spark, DuckDB, Trino, BigQuery, Snowflake, ClickHouse. Se domani cambiate motore, i dati rimangono dov'erano, nel formato in cui erano. Cambiate solo il motore che li legge.
La versione 1.11 di Apache Iceberg, rilasciata a maggio 2026 con 1.000 commit da oltre 200 contributori, ha portato alla maturità di produzione feature che erano in sviluppo da anni: deletion vectors basati su Roaring bitmap (aggiornamenti ed eliminazioni molto più efficienti), un tipo nativo Variant per i dati semi-strutturati come JSON senza la penalità delle stringhe, cifratura nativa delle tabelle con supporto KMS, e LIMIT pushdown — quando la query chiede i primi 100 risultati, Iceberg smette di leggere dopo averli trovati, invece di scansionare l'intera tabella. Per query esplorative su grandi dataset, questo può ridurre i dati letti da terabyte a megabyte.
Quando Iceberg è la scelta giusta — e quando non lo è:
Giusto per: aziende che hanno dati analitici su scala (decine di GB o più), che usano o prevedono di usare più strumenti diversi sugli stessi dati, che vogliono non essere vincolate a un singolo vendor per l'analisi. Particolarmente rilevante per chi usa oggi Snowflake, BigQuery o Databricks e vuole mantenere la possibilità di uscirne senza perdere i dati.
Non necessario per: aziende con dati operativi di dimensioni ridotte (poche decine di GB) che usano un solo strumento per tutto, o che hanno bisogno principalmente di un database transazionale (gestionale, CRM) piuttosto che analitico. Iceberg è uno strumento analitico, non operativo.
Fonti: Apache Iceberg, Snowflake Engineering Blog, Dremio, LakeOps — maggio/luglio 2026
☁️ Software per team piccolidbt + DuckDB: come un team di 5 persone può avere un'infrastruttura dati da grande impresa, a costo quasi zero
Esiste un problema molto comune nelle PMI in crescita: si paga un data warehouse cloud (Snowflake, BigQuery, Redshift) a 7.000-12.000 euro al mese, lo si usa al 10-15% della capacità, e i job di trasformazione dati impiegano 40 minuti quando potrebbero impiegarne 2. La risposta più diffusa è "sono i costi dell'infrastruttura dati". Non è vero — è il costo di una scelta fatta senza valutare le alternative.
dbt (data build tool) è lo strumento open source diventato lo standard de facto per trasformare i dati: permette di scrivere le trasformazioni in SQL standard, gestirle come codice con version control, e documentarle automaticamente. Funziona su qualsiasi database — dai grandi cloud warehouse a DuckDB.
DuckDB è un motore analitico open source che gira direttamente sul vostro computer o server senza installazione di infrastruttura. Processa file Parquet, CSV e tabelle Iceberg da storage object (S3-compatibile) in memoria, con velocità che supera spesso quella dei grandi warehouse cloud su dataset di dimensioni medie. Un laptop moderno con DuckDB può analizzare decine di GB in secondi. Un server con 32GB di RAM gestisce centinaia di GB agevolmente.
La combinazione dbt + DuckDB + Apache Iceberg su object storage economico (Cloudflare R2, Wasabi, o anche MinIO self-hosted) costruisce un lakehouse analitico completo — con ACID transactions, time travel, schema evolution — per team da 5 a 50 persone, a una frazione del costo dei data warehouse proprietari. I dati rimangono in formato aperto (Iceberg/Parquet), quindi se domani il team cresce e serve scalare a Spark o Databricks, si cambia il motore senza toccare i dati.
Il confronto di costo che nessun vendor vi fa:
Soluzione proprietaria tipica per una PMI con 200GB di dati analitici: Snowflake o BigQuery in configurazione base — 800-2.000 €/mese in compute, più storage. Pipeline ETL mensile da un fornitore esterno: 500-1.500 €. Totale annuo: 15.000-40.000 €.
Stack open source equivalente: DuckDB (gratuito) + dbt Community Edition (gratuito) + object storage su Cloudflare R2 (0,015 $/GB/mese, quindi circa 3 $/mese per 200GB) + un piccolo server VPS da 16 GB RAM (30-50 €/mese). Un tecnico interno che configura il sistema: 2-5 giorni di lavoro. Totale annuo: 400-700 €, più il costo una tantum di setup.
Fonti: Medium/Aasir Waseer, MotherDuck Blog, dbt Labs, LakeOps — maggio/giugno 2026
🌍 Contenuti e piattaformeHeadless CMS: perché separare il contenuto dalla piattaforma che lo mostra è la scelta più scalabile che possiate fare oggi
Il 2026 ha consolidato un cambiamento che era in corso da anni: le aziende che gestiscono contenuti digitali — siti, app, e-commerce, documentazione, portali clienti — stanno abbandonando i CMS tradizionali (WordPress, Drupal, Joomla) in favore di architetture headless. Il motivo non è tecnico-ideologico. È pragmatico: un CMS tradizionale lega il contenuto al suo sistema di presentazione. Se volete pubblicare lo stesso contenuto su un sito web, una app mobile, un totem in negozio e una newsletter, con un CMS tradizionale dovete duplicarlo in quattro posti diversi. Con un headless CMS, lo create una volta e lo distribuite ovunque tramite API.
Le tre opzioni più rilevanti per le PMI italiane nel 2026 hanno caratteristiche molto diverse, ed è utile capirle prima di scegliere:
Directus — L'unico che si mette sopra un database SQL esistente (MySQL, PostgreSQL, anche SQLite). Se avete già un database con dati strutturati e volete esporlo come API REST/GraphQL con un pannello di amministrazione, Directus è la scelta più rapida. Non richiede di migrare i dati: si connette al vostro database e lo rende immediatamente gestibile. Self-hosted: gratuito. Cloud managed: da 99 €/mese.
Strapi — L'opzione più diffusa per progetti nuovi che partono da zero. Approccio code-first: si definiscono i tipi di contenuto in codice (TypeScript), e Strapi genera automaticamente le API e il pannello di amministrazione. Molto flessibile, community italiana attiva, documentazione estesa. Self-hosted: gratuito. Cloud: 99-499 €/mese.
Payload CMS — Il più recente dei tre, nativo TypeScript, pensato per essere integrato direttamente dentro un'applicazione Next.js. Se sviluppate con lo stack moderno React/Next.js, Payload è la scelta più coerente. Completamente self-hostable, licenza MIT. Ottimo per team che preferiscono gestire tutto in un unico codebase.
La domanda che aiuta a scegliere:
Avete già un database con dati strutturati che volete esporre? → Directus.
State costruendo un sistema di contenuti da zero e volete massima flessibilità? → Strapi.
State costruendo un'app Next.js e volete CMS integrato nel codebase? → Payload.
In tutti e tre i casi, il dato rimane vostro, in un database che controllate, esportabile in qualsiasi momento. Non si paga per il dato, si paga (o non si paga, nel caso self-hosted) per la piattaforma che lo gestisce. Questo è il principio che distingue un headless CMS da una soluzione SaaS chiusa come Contentful o Webflow: nessun vendor lock-in sui contenuti.
Fonti: Luca Sammarco, State of Digital Publishing, Capterra, FreelanceDEV.it — 2026
🔬 Dal laboratorioData Fabric vs Data Mesh: non sono alternative, sono strati diversi dello stesso problema
Nel dibattito tecnico del 2026 emergono spesso due termini che sembrano in competizione: data mesh e data fabric. Vengono presentati come scelte opposte, ma descrivono cose diverse che operano a livelli diversi dello stesso problema.
Il data mesh è un modello organizzativo: chi possiede i dati, chi ne risponde, come si governano. Risponde alla domanda "chi fa cosa". Il data fabric è un'architettura tecnologica: uno strato di metadati, automazione e intelligenza che connette sorgenti di dati diverse, applica policy in modo automatico, e rende i dati accessibili in modo coerente indipendentemente da dove si trovano. Risponde alla domanda "come si fa tecnicamente".
Come ha scritto Gartner in modo preciso: un data fabric non è un singolo prodotto — è un'architettura composable composta da tecnologie interoperabili connesse da raccolta, analisi e attivazione continua di metadati. In parole semplici: il data fabric è il sistema che sa dove sono i dati, in che formato, chi può accedervi, e come cambiano nel tempo — e usa quella conoscenza per automatizzare ciò che altrimenti richiederebbe lavoro manuale continuo.
Per le PMI, la conclusione pratica è: non servono entrambi dall'inizio. Serve prima risolvere il problema organizzativo (chi è responsabile dei dati) e poi costruire progressivamente l'automazione tecnologica. Il contrario — comprare una piattaforma data fabric senza aver risolto la governance — produce sistemi costosi che nessuno usa perché nessuno sa chi deve mantenerli.
Fonti: Alation, Techment, Gartner — 2026
🎯 Strumento della settimanaDirectus — Il CMS headless che trasforma qualsiasi database SQL in un'API con pannello di amministrazione
Cos'è: Directus è un Data Platform open source che si installa sopra qualsiasi database SQL esistente — PostgreSQL, MySQL, SQLite, MS SQL — e lo espone come un'API REST e GraphQL completamente documentata, con un pannello di amministrazione visuale per la gestione dei contenuti. Non migra i dati, non li copia, non li trasforma: legge la struttura del vostro database esistente e costruisce automaticamente interfacce e API attorno a essa. Supporta permessi granulari per utente e per ruolo, webhook, flussi di automazione visuale, e si integra con qualsiasi frontend.
Perché è rilevante questo numero: Directus è la risposta più immediata per le PMI che hanno già dati in un database ma non hanno un modo semplice per gestirli, esporli o integrarli con altri sistemi. Un gestionale con un database MySQL sottostante, un sistema di produzione con dati in PostgreSQL, un catalogo prodotti in SQLite — tutti diventano API self-documented e pannello di amministrazione in meno di un'ora. Senza toccare i dati, senza migrazioni, senza rischi.
→ directus.io — open source, BSL license (self-hosted gratuito per uso commerciale). Repository GitHub con 30.000+ stelle.
Installazione: Docker Compose in cinque minuti. La documentazione ufficiale ha un tutorial completo per connettere un database PostgreSQL esistente e avere API funzionanti in meno di un'ora.
Alternativa da valutare: se non avete un database esistente ma state costruendo qualcosa di nuovo, Strapi (con code-first approach) o Payload CMS (se usate Next.js) sono le alternative più mature e altrettanto open source.
Via Indipendenza
La newsletter settimanale per chi guida un'azienda e vuole capire la tecnologia, non subirla. Via Indipendenza utilizza strumenti di intelligenza artificiale generativa, ma la selezione delle fonti e il controllo dei testi generati è fatto dal nostro team di esperti del settore (avviso ai sensi delle disposizioni dell'A.I. ACT, il Regolamento UE/2024/1689).
Un progetto promosso da airpim srl