7 bases de données à découvrir pour 2025

xguru · 2024-12-09T09:56:01+09:00

Présentation de 7 bases de données qui méritent l’attention pour résoudre des problèmes variés Il ne s’agit pas d’une liste des « meilleures bases de données », mais d’outils qui apportent des perspectives nouvelles et utiles En 2025, l’idée est d’investir une semaine sur chacune d’elles (7 DBs in 7 Weeks) 1. PostgreSQL : la base de données par défaut PostgreSQL est une technologie stable utilisée par défaut L’expression « Just use Postgres » est un mème largement connu et une formule qui symbolise sa fiabilité Il respecte les principes ACID et offre des fonctionnalités robustes, notamment la réplication physique et logique C’est une base de données stable, largement prise en charge par les grands fournisseurs Le plus grand atout de PostgreSQL : son extensibilité Les extensions permettent d’ajouter des fonctionnalités originales Exemples d’extensions majeures : AGE : prise en charge des structures de données graphe et du langage de requête Cypher TimescaleDB : prise en charge des charges de travail sur des données de séries temporelles Hydra Columnar : moteur de stockage en colonnes Les extensions sont un élément clé qui distingue PostgreSQL des autres bases de données Utilité et extensibilité de PostgreSQL Il dispose d’un vaste écosystème, avec des réglages par défaut raisonnables et conviviaux Même des services non PostgreSQL utilisent le protocole filaire Postgres pour assurer la compatibilité client Il est suffisamment léger pour pouvoir être installé dans un environnement WebAssembly (Wasm) Pourquoi apprendre PostgreSQL Il vaut la peine d’y consacrer du temps pour comprendre ses possibilités et ses limites Exemple : comprendre la complexité du MVCC (Multi-Version Concurrency Control) Il est recommandé de développer une simple application CRUD et même d’écrire des extensions PostgreSQL 2. SQLite : la base de données local-first SQLite est une base de données « local-first » qui peut fonctionner de manière autonome Elle s’éloigne du modèle client-serveur et s’exécute dans le même environnement que l’application Exemple : WhatsApp et Signal utilisent SQLite sur l’appareil pour stocker les données de chat Cas d’usage avancés de SQLite Elle permet des usages créatifs qui vont au-delà d’une simple base de données ACID Nouveaux outils et extensions : Litestream : sauvegarde en streaming pour SQLite LiteFS : accès distribué pour mettre en place des topologies plus souples CR-SQLite : utilise les CRDT (Conflict-free Replicated Data Types) pour supprimer la nécessité de résoudre les conflits lors de la fusion des jeux de changements Le regain d’intérêt pour SQLite Elle revient sur le devant de la scène grâce à Ruby on Rails 8.0 37signals développe des modules Rails basés sur SQLite, comme Solid Queue Rails prend en charge la gestion de plusieurs bases SQLite (database.yml) Bluesky utilise une base SQLite distincte par utilisateur comme Personal Data Server Pourquoi expérimenter avec SQLite Tester des architectures centrées sur le local avec SQLite Vérifier s’il est possible de remplacer un modèle client-serveur classique fondé sur PostgreSQL par SQLite 3. DuckDB : la base de données qui peut tout interroger DuckDB est une base de données embarquée spécialisée dans l’OLAP Comme SQLite, elle fonctionne aux côtés de l’application, mais se concentre sur l’OLAP plutôt que l’OLTP C’est un système conçu pour l’analyse de données et les requêtes Le caractère « Query-Anything » de DuckDB Elle permet d’interroger directement via SQL des sources de données variées : formats de fichiers courants comme CSV, TSV et JSON prise en charge de formats plus avancés comme Parquet Cette capacité offre une grande flexibilité, par exemple pour analyser les flux de données de Bluesky Extensibilité et écosystème DuckDB dispose aussi d’extensions, mais l’écosystème est moins riche que celui de Postgres, car le projet est plus jeune Il existe de nombreuses extensions issues de la communauté, et gsheets (intégration Google Sheets) est particulièrement notable Pourquoi apprendre DuckDB Expérimenter l’analyse et le traitement de données via des notebooks Python ou Evidence La combiner avec SQLite : déléguer à DuckDB les requêtes analytiques sur une base SQLite pour améliorer les performances 4. ClickHouse : la base de données en colonnes ClickHouse est une base de données spécialisée dans les charges OLAP La combinaison idéale serait PostgreSQL pour l’OLTP et ClickHouse pour l’OLAP Elle traite de lourdes charges analytiques et prend en charge des vitesses d’insertion élevées grâce au scale-out et au sharding Principales caractéristiques de ClickHouse Prise en charge du stockage hiérarchisé : possibilité de séparer et stocker les « données chaudes » et les « données froides » exemple : la documentation de GitLab détaille un cas d’usage fondé sur cette approche Traitement de jeux de données massifs et analyse en temps réel : adaptée à des volumes de données trop importants pour DuckDB offre de solides performances lorsqu’une analyse en temps réel est nécessaire Facilité d’exploitation La documentation sur le déploiement, la montée en charge et les sauvegardes est structurée et détaillée Exemple : elle va jusqu’à expliquer comment configurer correctement le CPU Pourquoi apprendre ClickHouse Expérimenter sur de grands jeux de données analytiques, ou migrer vers ClickHouse une analyse effectuée avec DuckDB Utiliser la version embarquée de ClickHouse, chDB, pour la comparer plus directement à SQLite 5. FoundationDB : la base de données en couches FoundationDB est un système unique qui sert de « fondation » pour les bases de données Conçue comme un magasin clé-valeur, elle fonctionne moins comme une simple base de données que comme une « base » sur laquelle construire des bases de données Elle est utilisée par de grandes entreprises comme Apple, Snowflake et Tigris Data Principales caractéristiques et limites Contraintes : les données d’une transaction ne peuvent pas dépasser 10MB une transaction ne peut pas durer plus de 5 secondes après la première lecture Ces limites permettent de prendre en charge des transactions ACID complètes même à grande échelle exemple : des clusters de plus de 100TiB en exploitation Conception et tests de FoundationDB Elle a été conçue pour être optimale sur certaines charges de travail Sa stabilité et sa capacité à monter en charge ont été démontrées via des tests en simulation : Antithesis et d’autres bases de données utilisent la même méthodologie de test références associées : documents de Tyler Neely et Phil Eaton FoundationDB comme base de données « en couches » Le couplage entre moteur de stockage et modèle de données est faible : il est possible de remapper le moteur de stockage à différentes couches exemples : couche Record, couche Document (fournies par l’organisation FoundationDB) Les exemples de conception de couches publiés par Tigris Data méritent le détour Pourquoi apprendre FoundationDB Suivre les tutoriels et explorer sa capacité à remplacer des systèmes comme RocksDB Lire les méthodes de conception (Design Recipes) et les articles associés Comprendre les limites d’usage et les problèmes qu’elle peut résoudre grâce aux documents Anti-Features et Features 6. TigerBeetle : une base de données obsédée par l’exactitude TigerBeetle est une base de données à usage unique spécialisée dans les transactions financières Contrairement aux bases généralistes, elle se concentre sur un objectif précis, en particulier les transactions financières Elle est proposée en open source et conçue pour atteindre un très haut niveau de fiabilité et d’exactitude Une philosophie de conception tournée vers l’exactitude absolue Mise en œuvre des Power of Ten Rules de la NASA et de la Protocol-Aware Recovery Utilisation de la strict serialisability et du Direct I/O pour éviter les problèmes liés au page cache du noyau On perçoit cette rigueur dans la documentation de sécurité (Safety doc) et dans le style de programmation singulier appelé « Tiger Style » Une approche innovante mise en œuvre en Zig Zig est un langage de programmation système relativement récent, mais particulièrement adapté aux objectifs de TigerBeetle Le projet exploite les atouts de Zig pour maximiser simplicité et performance Suggestions d’apprentissage et d’usage de TigerBeetle Expérimenter la modélisation de comptes financiers dans un environnement déployé en local : suivre le Quick Start pour l’installation et la prise en main Consulter la documentation d’architecture système (System Architecture docs) pour étudier son association possible avec une base généraliste Exemple : l’intégrer avec PostgreSQL ou FoundationDB pour élargir les cas d’usage 7. CockroachDB : la base de données globale CockroachDB est une base de données distribuée globale Compatible avec le protocole filaire PostgreSQL, elle prend en charge le scale-out et la cohérence forte Inspirée de Google Spanner, sa conception permet d’étendre une base sur plusieurs régions Principales caractéristiques techniques de CockroachDB Technologies de synchronisation du temps : Google Spanner utilise des horloges atomiques et GPS, tandis que CockroachDB est conçue pour fonctionner sur du matériel standard compensation de la latence de synchronisation basée sur NTP, comparaison de la dérive d’horloge entre nœuds et exclusion d’un membre en cas de dépassement du décalage maximal Configuration multi-région : la fonctionnalité Table Localities permet d’optimiser les compromis entre lecture et écriture les données sont réparties en fonction de la localisation géographique des utilisateurs afin d’améliorer performances et latence Suggestions d’apprentissage pour CockroachDB Réimplémenter l’exemple MovR : implémenter MovR (exemple d’application distribuée) dans le langage et le framework de votre choix Expérimenter la conception d’applications globales en tirant parti des stratégies multi-région et de montée en charge de CockroachDB Pourquoi choisir CockroachDB Contrairement à d’autres bases de données distribuées comme DynamoDB, elle peut s’exécuter gratuitement en local Elle offre une combinaison différenciante de cohérence forte et de distribution globale Pour conclure Les bases de données présentées ont été conçues pour résoudre des problèmes et répondre à des besoins très différents En 2025, prenez le temps d’étudier ces bases de données et d’explorer des façons plus intéressantes et créatives de résoudre les problèmes !

(matt.blwt.io)

53 points par xguru 2024-12-09 | 14 commentaires | Partager sur WhatsApp

Présentation de 7 bases de données qui méritent l’attention pour résoudre des problèmes variés
Il ne s’agit pas d’une liste des « meilleures bases de données », mais d’outils qui apportent des perspectives nouvelles et utiles
En 2025, l’idée est d’investir une semaine sur chacune d’elles (7 DBs in 7 Weeks)

1. PostgreSQL : la base de données par défaut

PostgreSQL est une technologie stable utilisée par défaut
- L’expression « Just use Postgres » est un mème largement connu et une formule qui symbolise sa fiabilité
- Il respecte les principes ACID et offre des fonctionnalités robustes, notamment la réplication physique et logique
- C’est une base de données stable, largement prise en charge par les grands fournisseurs
Le plus grand atout de PostgreSQL : son extensibilité
- Les extensions permettent d’ajouter des fonctionnalités originales
- Exemples d’extensions majeures :
  - AGE : prise en charge des structures de données graphe et du langage de requête Cypher
  - TimescaleDB : prise en charge des charges de travail sur des données de séries temporelles
  - Hydra Columnar : moteur de stockage en colonnes
- Les extensions sont un élément clé qui distingue PostgreSQL des autres bases de données
Utilité et extensibilité de PostgreSQL
- Il dispose d’un vaste écosystème, avec des réglages par défaut raisonnables et conviviaux
- Même des services non PostgreSQL utilisent le protocole filaire Postgres pour assurer la compatibilité client
- Il est suffisamment léger pour pouvoir être installé dans un environnement WebAssembly (Wasm)
Pourquoi apprendre PostgreSQL
- Il vaut la peine d’y consacrer du temps pour comprendre ses possibilités et ses limites
- Exemple : comprendre la complexité du MVCC (Multi-Version Concurrency Control)
- Il est recommandé de développer une simple application CRUD et même d’écrire des extensions PostgreSQL

2. SQLite : la base de données local-first

SQLite est une base de données « local-first » qui peut fonctionner de manière autonome
- Elle s’éloigne du modèle client-serveur et s’exécute dans le même environnement que l’application
- Exemple : WhatsApp et Signal utilisent SQLite sur l’appareil pour stocker les données de chat
Cas d’usage avancés de SQLite
- Elle permet des usages créatifs qui vont au-delà d’une simple base de données ACID
- Nouveaux outils et extensions :
  - Litestream : sauvegarde en streaming pour SQLite
  - LiteFS : accès distribué pour mettre en place des topologies plus souples
  - CR-SQLite : utilise les CRDT (Conflict-free Replicated Data Types) pour supprimer la nécessité de résoudre les conflits lors de la fusion des jeux de changements
Le regain d’intérêt pour SQLite
- Elle revient sur le devant de la scène grâce à Ruby on Rails 8.0
- 37signals développe des modules Rails basés sur SQLite, comme Solid Queue
  - Rails prend en charge la gestion de plusieurs bases SQLite (database.yml)
- Bluesky utilise une base SQLite distincte par utilisateur comme Personal Data Server
Pourquoi expérimenter avec SQLite
- Tester des architectures centrées sur le local avec SQLite
- Vérifier s’il est possible de remplacer un modèle client-serveur classique fondé sur PostgreSQL par SQLite

3. DuckDB : la base de données qui peut tout interroger

DuckDB est une base de données embarquée spécialisée dans l’OLAP
- Comme SQLite, elle fonctionne aux côtés de l’application, mais se concentre sur l’OLAP plutôt que l’OLTP
- C’est un système conçu pour l’analyse de données et les requêtes
Le caractère « Query-Anything » de DuckDB
- Elle permet d’interroger directement via SQL des sources de données variées :
  - formats de fichiers courants comme CSV, TSV et JSON
  - prise en charge de formats plus avancés comme Parquet
- Cette capacité offre une grande flexibilité, par exemple pour analyser les flux de données de Bluesky
Extensibilité et écosystème
- DuckDB dispose aussi d’extensions, mais l’écosystème est moins riche que celui de Postgres, car le projet est plus jeune
- Il existe de nombreuses extensions issues de la communauté, et gsheets (intégration Google Sheets) est particulièrement notable
Pourquoi apprendre DuckDB
- Expérimenter l’analyse et le traitement de données via des notebooks Python ou Evidence
- La combiner avec SQLite : déléguer à DuckDB les requêtes analytiques sur une base SQLite pour améliorer les performances

4. ClickHouse : la base de données en colonnes

ClickHouse est une base de données spécialisée dans les charges OLAP
- La combinaison idéale serait PostgreSQL pour l’OLTP et ClickHouse pour l’OLAP
- Elle traite de lourdes charges analytiques et prend en charge des vitesses d’insertion élevées grâce au scale-out et au sharding
Principales caractéristiques de ClickHouse
- Prise en charge du stockage hiérarchisé :
  - possibilité de séparer et stocker les « données chaudes » et les « données froides »
  - exemple : la documentation de GitLab détaille un cas d’usage fondé sur cette approche
- Traitement de jeux de données massifs et analyse en temps réel :
  - adaptée à des volumes de données trop importants pour DuckDB
  - offre de solides performances lorsqu’une analyse en temps réel est nécessaire
Facilité d’exploitation
- La documentation sur le déploiement, la montée en charge et les sauvegardes est structurée et détaillée
- Exemple : elle va jusqu’à expliquer comment configurer correctement le CPU
Pourquoi apprendre ClickHouse
- Expérimenter sur de grands jeux de données analytiques, ou migrer vers ClickHouse une analyse effectuée avec DuckDB
- Utiliser la version embarquée de ClickHouse, chDB, pour la comparer plus directement à SQLite

5. FoundationDB : la base de données en couches

FoundationDB est un système unique qui sert de « fondation » pour les bases de données
- Conçue comme un magasin clé-valeur, elle fonctionne moins comme une simple base de données que comme une « base » sur laquelle construire des bases de données
- Elle est utilisée par de grandes entreprises comme Apple, Snowflake et Tigris Data
Principales caractéristiques et limites
- Contraintes :
  - les données d’une transaction ne peuvent pas dépasser 10MB
  - une transaction ne peut pas durer plus de 5 secondes après la première lecture
- Ces limites permettent de prendre en charge des transactions ACID complètes même à grande échelle
  - exemple : des clusters de plus de 100TiB en exploitation
Conception et tests de FoundationDB
- Elle a été conçue pour être optimale sur certaines charges de travail
- Sa stabilité et sa capacité à monter en charge ont été démontrées via des tests en simulation :
  - Antithesis et d’autres bases de données utilisent la même méthodologie de test
  - références associées : documents de Tyler Neely et Phil Eaton
FoundationDB comme base de données « en couches »
- Le couplage entre moteur de stockage et modèle de données est faible :
  - il est possible de remapper le moteur de stockage à différentes couches
  - exemples : couche Record, couche Document (fournies par l’organisation FoundationDB)
- Les exemples de conception de couches publiés par Tigris Data méritent le détour
Pourquoi apprendre FoundationDB
- Suivre les tutoriels et explorer sa capacité à remplacer des systèmes comme RocksDB
- Lire les méthodes de conception (Design Recipes) et les articles associés
- Comprendre les limites d’usage et les problèmes qu’elle peut résoudre grâce aux documents Anti-Features et Features

6. TigerBeetle : une base de données obsédée par l’exactitude

TigerBeetle est une base de données à usage unique spécialisée dans les transactions financières
- Contrairement aux bases généralistes, elle se concentre sur un objectif précis, en particulier les transactions financières
- Elle est proposée en open source et conçue pour atteindre un très haut niveau de fiabilité et d’exactitude
Une philosophie de conception tournée vers l’exactitude absolue
- Mise en œuvre des Power of Ten Rules de la NASA et de la Protocol-Aware Recovery
- Utilisation de la strict serialisability et du Direct I/O pour éviter les problèmes liés au page cache du noyau
- On perçoit cette rigueur dans la documentation de sécurité (Safety doc) et dans le style de programmation singulier appelé « Tiger Style »
Une approche innovante mise en œuvre en Zig
- Zig est un langage de programmation système relativement récent, mais particulièrement adapté aux objectifs de TigerBeetle
- Le projet exploite les atouts de Zig pour maximiser simplicité et performance
Suggestions d’apprentissage et d’usage de TigerBeetle
- Expérimenter la modélisation de comptes financiers dans un environnement déployé en local :
  - suivre le Quick Start pour l’installation et la prise en main
- Consulter la documentation d’architecture système (System Architecture docs) pour étudier son association possible avec une base généraliste
- Exemple : l’intégrer avec PostgreSQL ou FoundationDB pour élargir les cas d’usage

7. CockroachDB : la base de données globale

CockroachDB est une base de données distribuée globale
- Compatible avec le protocole filaire PostgreSQL, elle prend en charge le scale-out et la cohérence forte
- Inspirée de Google Spanner, sa conception permet d’étendre une base sur plusieurs régions
Principales caractéristiques techniques de CockroachDB
- Technologies de synchronisation du temps :
  - Google Spanner utilise des horloges atomiques et GPS, tandis que CockroachDB est conçue pour fonctionner sur du matériel standard
  - compensation de la latence de synchronisation basée sur NTP, comparaison de la dérive d’horloge entre nœuds et exclusion d’un membre en cas de dépassement du décalage maximal
- Configuration multi-région :
  - la fonctionnalité Table Localities permet d’optimiser les compromis entre lecture et écriture
  - les données sont réparties en fonction de la localisation géographique des utilisateurs afin d’améliorer performances et latence
Suggestions d’apprentissage pour CockroachDB
- Réimplémenter l’exemple MovR :
  - implémenter MovR (exemple d’application distribuée) dans le langage et le framework de votre choix
- Expérimenter la conception d’applications globales en tirant parti des stratégies multi-région et de montée en charge de CockroachDB
Pourquoi choisir CockroachDB
- Contrairement à d’autres bases de données distribuées comme DynamoDB, elle peut s’exécuter gratuitement en local
- Elle offre une combinaison différenciante de cohérence forte et de distribution globale

Pour conclure

Les bases de données présentées ont été conçues pour résoudre des problèmes et répondre à des besoins très différents
En 2025, prenez le temps d’étudier ces bases de données et d’explorer des façons plus intéressantes et créatives de résoudre les problèmes !

14 commentaires

wfedev 2025-11-28

Interrogez n’importe quoi ! 😆🐤

budaestew 2024-12-16

J’ai été surpris de voir que DuckDB est bien plus performant que prévu pour l’analyse.

halfenif 2024-12-09

Depuis quelques mois, j’utilise sqlite. Par date. J’effectue un travail qui traite environ 2 millions d’enregistrements, soit un volume de données d’environ 5 Go.

La vitesse de traitement est satisfaisante, mais... cela prend beaucoup trop de temps de retraiter ces données puis de les retransformer en fichier Excel pour les fournir aux parties prenantes.

Je pense qu’il va falloir que j’étudie davantage la manière d’utiliser OpenPyXl.

kimjj81 2024-12-18

Je ne sais pas quelle magie il y a derrière, mais apparemment ils utilisent une combinaison de duckDB + sqlite.

channprj 2024-12-09

Étonnamment, MongoDB n’a pas été mentionné.

felizgeek 2024-12-09

Si vous êtes dans un environnement où la courbe d’apprentissage des développeurs vous inquiète, je recommande SQLite. Comme il est basé sur des fichiers, c’est simple.

savvykang 2024-12-09

Si l'absence de besoin d'accès à distance est certaine, c'est vraiment une solution très satisfaisante. Il n'y a plus de point de gestion de la base de données, et l'édition des données ainsi que la sauvegarde/restauration sont simples, ce qui est appréciable.

aer0700 2024-12-09

Quand on dit qu’on va utiliser SQLite, c’est facile de se faire tomber dessus, mais avant de dire qu’on a utilisé SQLite, personne ne le remarque non plus... SQLite est meilleur qu’on ne le pense.

jpumpkin94 2024-12-09

Cela fait des décennies (??) que je n’utilise que MySQL, J’aimerais beaucoup lire les commentaires de personnes qui utilisent PostgreSQL en production dans leur travail pour savoir ce qu’il en est.

zuppiy 2024-12-09

« Les éléphants sont supérieurs aux phoques »
C'est vrai dans la plupart des cas

roxie 2024-12-11

mdr

kibae 2024-12-09

En 2001, je suis passé de mysql, bourré de bugs à l’époque (v3.x), à pgsql.
Je pense qu’il lui est supérieur sur bien des points, mais... dans la pratique, je considère que l’existence des index partiels est sa fonctionnalité la plus puissante.

chanhee 2024-12-09

Au travail, je n’utilisais qu’Oracle et SQL Server, puis quand j’ai voulu passer à MySQL, il y avait vraiment trop de moments où je me disais : « Pourquoi ça ne marche pas ? » Je ne me souviens plus exactement des détails. Au final, je suis passé à Postgres.

bbulbum 2024-12-09

En passant d’un environnement où j’utilisais Postgres à un autre où l’on utilise MySQL, il y a pas mal de choses pour lesquelles je me suis dit : pourquoi ça ne marche pas ? pourquoi je n’obtiens pas ces performances ?
Je ne me souviens pas exactement de quoi il s’agissait (ça pouvait être anodin, ou pas).