En 2026, il suffit d’utiliser Postgres

 (tigerdata.com)
5 points par GN⁺ 2026-02-06 | 1 commentaires | Partager sur WhatsApp
  • Postgres est une plateforme unifiée capable de gérer dans une seule base de données des fonctions variées comme la recherche, les vecteurs, les séries temporelles et les files de messages
  • Utiliser plusieurs bases de données spécialisées entraîne des inefficacités et des risques en matière d’administration, de sécurité, de sauvegarde et de gestion des incidents
  • À l’ère de l’IA, il faut pouvoir cloner, tester et supprimer rapidement des bases de données ; une architecture à système unique garantit donc simplicité et agilité
  • Les extensions de Postgres utilisent les mêmes algorithmes qu’Elasticsearch, Pinecone ou InfluxDB, avec des performances déjà démontrées
  • Pour la plupart des entreprises (99 %), un seul Postgres suffit ; les architectures distribuées complexes ne sont nécessaires que pour une infime minorité de très grandes entreprises

La nécessité de consolider les bases de données

  • L’article compare les bases de données à une maison et présente Postgres comme une structure qui réunit plusieurs fonctions sous un même toit
    • Recherche, vecteurs, séries temporelles, files de messages : tous ces usages peuvent être traités dans un seul système
  • À l’inverse, le conseil consistant à « utiliser le bon outil au bon endroit » conduit en pratique à faire fonctionner plusieurs bases de données en parallèle
    • Sept systèmes sont cités en exemple : Elasticsearch, Pinecone, Redis, MongoDB, Kafka, InfluxDB et PostgreSQL
    • Il faut gérer séparément leurs langages de requête, sauvegardes, politiques de sécurité, supervision et réponses aux pannes
  • Cette architecture distribuée complique la mise en place des environnements de test et la résolution des problèmes, avec une complexité maximale lors des incidents en pleine nuit
Publicité

La simplicité à l’ère de l’IA

  • Les agents IA doivent pouvoir créer, valider et supprimer rapidement des bases de données de test
    • Avec une base unique, une seule commande suffit ; avec plusieurs systèmes, il faut synchroniser les snapshots et ajuster les configurations
  • Administrer plusieurs bases de données simultanément exige une complexité de niveau R&D
  • À l’ère de l’IA, la simplicité est présentée comme un élément indispensable

Le mythe de la « supériorité » des bases spécialisées

  • L’idée selon laquelle les bases de données spécialisées sont meilleures sur certaines tâches est décrite comme un effet marketing exagéré
    • En pratique, les extensions Postgres utilisent des algorithmes identiques, voire meilleurs
  • Selon le tableau comparatif, les extensions Postgres correspondent aux bases spécialisées suivantes
    Fonction Base spécialisée Extension Postgres Algorithme identique
    Recherche plein texte Elasticsearch pg_textsearch BM25
    Recherche vectorielle Pinecone pgvector + pgvectorscale HNSW/DiskANN
    Séries temporelles InfluxDB TimescaleDB Partitionnement temporel
    Cache Redis UNLOGGED tables Stockage en mémoire
    Documents MongoDB JSONB Indexation documentaire
    Géospatial GIS PostGIS Standard industriel
  • pgvectorscale affiche une latence 28 fois plus faible et un coût 75 % inférieur à Pinecone
  • TimescaleDB offre des performances équivalentes ou supérieures à InfluxDB, et pg_textsearch utilise le même classement BM25 qu’Elasticsearch

Les coûts cachés de la dispersion des bases de données

  • Exploiter plusieurs systèmes multiplie par 7 tous les coûts de gestion liés aux sauvegardes, à la supervision, aux correctifs de sécurité et à la gestion des incidents
  • Charge cognitive : il faut apprendre SQL, Redis, Elasticsearch DSL, MongoDB, Kafka, InfluxDB et d’autres langages
  • Problèmes de cohérence des données : un échec de synchronisation entre Postgres et Elasticsearch peut provoquer une dérive des données
  • Baisse de disponibilité : les SLA de plusieurs systèmes se multiplient entre eux, ce qui réduit le taux de disponibilité global (ex. : 99,9 % × 3 = 99,7 %)
Publicité

La pile Postgres moderne

  • Les extensions Postgres sont déjà validées en production depuis des années
    • PostGIS (2001), Full-text search (2008), JSONB (2014), TimescaleDB (2017), pgvector (2021)
  • Plus de 48 000 entreprises, dont Netflix, Spotify, Uber, Reddit, Instagram et Discord, utilisent PostgreSQL
  • Extensions pour l’ère de l’IA
    Extension Remplace Caractéristiques
    pgvectorscale Pinecone, Qdrant Algorithme DiskANN, latence 28 fois plus faible, coût réduit de 75 %
    pg_textsearch Elasticsearch Implémente directement le classement BM25 dans Postgres
    pgai Pipelines IA externes Synchronisation automatique des embeddings lors des changements de données
  • Il est possible de construire une application RAG avec un seul Postgres : un seul langage de requête, une seule sauvegarde, un seul environnement de test

Exemples d’extensions majeures

  • pg_textsearch : remplace Elasticsearch, avec une recherche basée sur BM25
  • pgvector + pgvectorscale : remplace Pinecone, avec une recherche vectorielle basée sur DiskANN
  • TimescaleDB : remplace InfluxDB, avec compression des séries temporelles et prise en charge de SQL
  • UNLOGGED tables : remplace Redis, pour implémenter des tables de cache
  • pgmq : remplace Kafka, en fournissant une file de messages
  • JSONB : remplace MongoDB, pour le stockage et l’indexation de données documentaires
  • PostGIS : prend en charge le traitement géospatial
  • pg_cron : automatise les tâches planifiées
  • pg_trgm : prend en charge la recherche tolérante aux fautes de frappe
  • Recursive CTEs : permettent d’implémenter l’exploration de graphes

Conclusion

  • Postgres est une maison avec plusieurs pièces, qui intègre diverses capacités de traitement des données dans un même ensemble
  • Pour la plupart des entreprises (99 %), un seul Postgres suffit ; seule une très petite minorité (1 %) a besoin de systèmes distribués à très grande échelle
  • Le conseil du « bon outil au bon endroit » est présenté comme une logique marketing destinée à vendre des bases de données
  • Le principe proposé est le suivant : commencez avec Postgres et n’ajoutez de la complexité que lorsque c’est réellement nécessaire
  • La conclusion est claire : en 2026, il suffit d’utiliser Postgres

À lire aussi

1 commentaires

 
GN⁺ 2026-02-06
Avis sur Hacker News

  • Il est difficile d’embarquer Postgres dans des apps local-first, et le fait de devoir imposer une configuration Docker est pénible
    PGlite serait parfait s’il prenait en charge plusieurs connexions writer. SQLite est correct aussi, mais je veux les extensions PG et le vrai support parallèle multi-writer

  • En me replongeant dans les bases de données après longtemps, je me suis rendu compte que Postgres est vraiment un système quasi magique
    En mettant des dizaines de millions de lignes dans plusieurs tables et en définissant correctement les index, presque toutes les requêtes répondent en moins de 100 ms
    Quand on analyse le plan d’exécution, on voit tout de suite quels index ajouter, c’est bluffant. Les DB modernes sont de vrais miracles

    • En réalité, ce que tu décris n’est pas tant une caractéristique des DB « modernes » que de Postgres il y a déjà 20 ans
      Bien sûr, c’est bien meilleur aujourd’hui, mais la plupart des progrès concernent surtout les fonctionnalités de requêtage avancé ou les optimisations d’exploitation
    • Les DB relationnelles offrent ce niveau de performance depuis des décennies. Ce n’est pas propre à Postgres

  • Je suis un fan de Postgres, mais je ne suis pas d’accord avec le conseil « utilisez simplement Postgres »
    Construire une stack simplifiée autour de Postgres, c’est bien, mais ce n’est pas efficace pour toutes les charges de travail
    À l’époque de Citus Data, j’ai souvent vu des cas où une équipe d’experts Postgres devait passer son temps à tuner et à l’exploiter
    Avec la montée des cas d’usage liés à l’IA, la tendance est à adopter beaucoup plus tôt des technologies spécialisées
    C’est détaillé sur le blog de ClickHouse
    Je pense qu’une approche consistant à combiner Postgres avec des technologies orientées métier est meilleure

    • Je l’ai compris non pas comme « utilisez toujours Postgres uniquement », mais comme « considérez Postgres par défaut »
    • Moi aussi, je suis plutôt sur la ligne « utilisez Postgres, puis remplacez-le si nécessaire ». Une stack simple favorise une itération rapide
    • En réalité, Postgres intègre déjà beaucoup de fonctionnalités de systèmes spécialisés. Si on lit la doc et qu’on le tune bien, il peut largement suffire
    • Au fond, le point clé, c’est que les cas d’usage diffèrent. Voir comparaison MySQL / Postgres
    • Je pense que le vrai problème, c’est que les développeurs d’aujourd’hui se laissent trop emporter par le hype et vouent une confiance aveugle à certaines technologies
      Quand une technologie devient un standard, les développeurs deviennent des pièces interchangeables. Comme les développeurs React
      L’uniformisation technologique est, du point de vue des entreprises, une stratégie pour faciliter le remplacement des effectifs. Il faut préserver la diversité des outils

  • J’utilise souvent Postgres moi aussi, mais parfois la simplicité compte davantage
    Pour l’exploration de données ou les travaux SIG, Postgres.app est parfait, mais pour un serveur simple, SQLite peut être un meilleur choix

    • Même en commençant simplement avec SQLite, on se heurte vite à des limites gênantes. Postgres en est au niveau du « on l’installe puis on l’oublie »
      Même pour de petites analyses de données, Postgres est bien plus rapide que SQLite. La différence en matière d’indexation et de fonctionnalités est importante
    • SQLite est excellent pour les tests d’intégration. On peut démarrer et arrêter une DB facilement sans conteneur
    • SQLite est aussi utile pour les données temporaires ou les fichiers de stockage local
      Mais dans 99 % des cas, j’utilise Postgres. C’est stable, scalable, et à mon avis meilleur qu’Oracle ou MySQL
    • Ce qui me gêne, c’est qu’il est difficile de configurer des droits d’accès limités à une DB précise dans Postgres
      GRANT ALL PRIVILEGES ne fonctionne pas toujours
    • La discussion « quelle DB utiliser ? » comporte trop de variables complexes
      Postgres est gratuit, rapide et bien adapté aux apps partagées, mais SQLite est optimal pour les développeurs solo

  • Au final, tout dépend du cas d’usage
    Nous aussi, nous utilisions autrefois une recherche basée sur MariaDB, puis nous avons migré vers Elasticsearch, et c’était bien meilleur en vitesse comme en simplicité
    Mais pour une recherche simple, Postgres suffit largement
    Avant de migrer vers un nouvel outil, mieux vaut attendre, et ne changer que lorsque c’est nécessaire est plus efficace

  • Des DB comme Pinecone ou Redis sont bien plus rentables pour certains usages spécifiques
    Mais selon le contexte, résoudre le problème avec Postgres peut être préférable
    Au final, il faut juger selon l’échelle et la présence ou non d’une équipe ops

    • Une fois qu’on a une vraie application et de vraies données, il devient plus facile de choisir la bonne alternative
      Postgres suffit pour la plupart des phases initiales, et on peut envisager d’autres solutions une fois que ça grossit

  • Récemment, je suis plutôt en train de revenir vers MySQL et SQLite au lieu de Postgres
    Le vacuum, la maintenance et les footguns de Postgres sont pénibles

    • MySQL a quasiment zéro coût opérationnel. Postgres demande des ajustements constants, alors que MySQL tourne juste bien tout seul
    • SQLite demande aussi peu de maintenance, mais il faut quand même lancer un VACUUM pour éviter l’accumulation d’espace
    • MySQL est facile à administrer, mais il faut renoncer à des fonctionnalités avancées (BRIN, partial index, etc.)
      En revanche, si l’on conçoit bien les index clusterisés, les range scans sont extrêmement rapides
    • J’ai moi aussi envisagé de migrer vers MySQL. Les upgrades sont simples, mais son rythme d’évolution est plus lent que celui de Postgres
    • Il est dommage que le projet Zheap de Postgres ait été abandonné
      Il faudrait un moteur de stockage sans VACUUM. Voir le wiki Zheap

  • Postgres est excellent, mais il a deux problèmes fondamentaux
    Premièrement, Postgres n’est pas un outil intégré mais une boîte à outils, donc la courbe d’apprentissage est importante
    Deuxièmement, Postgres a une conception basée sur les HDD, ce qui peut être inefficace à l’ère des SSD
    Un SGBDR conçu spécifiquement pour les SSD a de bonnes chances d’être plus simple et plus rapide

    • J’aimerais bien savoir sur quoi se fonde l’affirmation selon laquelle Postgres est conçu pour les HDD. J’aimerais connaître la source

  • La configuration du clustering (HA) de Postgres est trop complexe
    Il existe des outils comme Patroni, Spilo, timescaledb-ha, mais ils sont difficiles à gérer et la documentation est insuffisante
    CloudNativePG est la seule méthode vraiment simple, mais elle implique une dépendance à Kubernetes
    Ce serait bien de pouvoir configurer un replica set aussi simplement qu’avec MongoDB

    • Mais Postgres n’est pas une DB CP, et en cas de partition réseau, il peut y avoir des pertes d’écriture
      Pour réussir les tests Jepsen, il faudrait des changements structurels (comme Yugabyte ou Neon)

  • Il y a aussi des avis sur le fait d’utiliser Postgres comme cache
    Redis est bien plus rapide, mais à petite échelle Postgres peut suffire

    • Si l’on a besoin d’un cache, memcache est simple et stable
      Il peut encaisser des dizaines de milliards de requêtes sans redémarrage
    • Il faut prouver par benchmark que Redis est réellement nécessaire. S’il n’y a pas de différence significative, Postgres suffit
    • Pour comparer avec Redis, il faut utiliser une unlogged table. En désactivant les fonctions de durabilité, c’est beaucoup plus rapide
    • Si les besoins de cache de l’app ne sont pas importants, on peut commencer avec Postgres,
      et dans une architecture de serveurs stateless, Redis peut valoir le coup. Avec un processus long basé sur la JVM, un cache interne est aussi possible
    • Les materialized views de Postgres sont également assez utiles
      Mais si la charge augmente, un cache externe devient nécessaire, et il faut renoncer à la cohérence transactionnelle