SQLite, CSV, Parquet : quel format choisir pour stocker des données

Ces trois formats stockent tous des données structurées, mais aucun n’est un vrai substitut aux deux autres : le choix dépend surtout de ce qu’on va faire des données une fois stockées.

Format	Organisation	Requêtable en SQL	Meilleur usage
CSV	Texte, ligne par ligne	Non	Échange simple, petits volumes
SQLite	Base relationnelle en un seul fichier	Oui, nativement	Base embarquée dans une application
Parquet	Colonne par colonne	Non (nécessite un moteur, ex. Spark)	Analyse de gros volumes de données

Le CSV représente des données tabulaires en texte brut, une ligne par enregistrement, des valeurs séparées par une virgule ou un point-virgule. Normalisé a posteriori par la RFC 4180 en 2005 après des décennies d’usage informel, il n’a aucune signature binaire ni structure d’en-tête : rien ne le distingue d’un fichier texte brut ordinaire. Sa simplicité en fait le format d’échange le plus universellement accepté, au prix d’incompatibilités classiques liées au séparateur, à l’encodage ou au format des nombres décimaux selon la locale.

Le SQLite est une base de données relationnelle complète tenant dans un seul fichier, sans serveur ni processus séparé à administrer. Sa signature textuelle “SQLite format 3” est directement lisible en tête de fichier. C’est le bon choix quand l’application a besoin de requêtes SQL, d’index ou de contraintes d’intégrité sur des données qui évoluent — pas seulement de les transporter d’un point A à un point B.

Le Parquet stocke les données non pas ligne par ligne comme un CSV, mais colonne par colonne, une organisation particulièrement efficace pour les requêtes analytiques qui ne portent que sur certaines colonnes d’un très gros jeu de données. Sa chaîne de signature “PAR1”, présente à la fois en début et en fin de fichier, permet de vérifier qu’un fichier n’a pas été tronqué lors d’un transfert. C’est le format de référence du traitement de données à grande échelle (Apache Spark, Hadoop, entrepôts cloud), mais il nécessite un outil dédié pour être exploité, contrairement au CSV lisible par n’importe qui.

En résumé : CSV pour l’échange simple et universel de petits jeux de données, SQLite pour une base de données embarquée dans une application avec des requêtes SQL, Parquet pour l’analyse de gros volumes de données tabulaires où la compression et la performance de lecture priment.