PostgreSQL suffit

 (gist.github.com/cpursley)
44 points par GN⁺ 2024-02-07 | 2 commentaires | Partager sur WhatsApp
  • Une page qui rassemble des liens sur les façons d’utiliser PostgreSQL dans différents domaines
    • tâches en arrière-plan, files de messages, SIG, journaux d’audit, contrôle d’accès, gestion des autorisations, recherche, séries temporelles, données graphe, données externes, HTTP, API, événements/réplication/CDC, tests unitaires, migrations, tableaux de bord/UI, visualisation de données, HTML et applications, LSP (Language Server Protocol)

PostgreSQL is Enough

Tâches en arrière-plan

  • pg_cron permet de gérer des tâches planifiées dans PostgreSQL.

File de messages

  • Présente des informations sur la manière de choisir PostgreSQL comme technologie de file de messages.
  • pgmq est un système de file de messages basé sur PostgreSQL.

SIG / Cartographie

  • PostGIS ajoute des fonctionnalités de base de données géospatiale à PostgreSQL.

Journaux d’audit

  • pgMemento et pgaudit permettent de suivre les changements et de gérer les journaux d’audit dans PostgreSQL.

Contrôle d’accès

  • acl est utilisé pour gérer des listes de contrôle d’accès dans PostgreSQL.

Authentification

  • Le module pgcrypto de PostgreSQL et pgjwt gèrent l’authentification dans la base de données.

Recherche

  • Fournit des liens utiles liés à la recherche en texte intégral de PostgreSQL.
  • paradedb, pg_embedding, pgvector améliorent les capacités de recherche dans PostgreSQL.

Données de séries temporelles

  • timescaledb étend PostgreSQL pour gérer des données de séries temporelles.

Données graphe

  • Apache AGE étend PostgreSQL pour offrir des fonctionnalités de base de données graphe.

Données externes

  • wrappers intègre des sources de données externes dans PostgreSQL.

HTTP

  • pgsql-http et pg_net traitent des requêtes HTTP dans PostgreSQL.

API

  • PostgREST, graphql-engine, postgraphile, pg_graphql permettent de construire des serveurs API basés sur PostgreSQL.

Événements, réplication, CDC

  • La commande NOTIFY de PostgreSQL ainsi que walex, peerdb, debezium, pglogical permettent de suivre les changements de données et fournissent des fonctions de réplication.

Tests unitaires

  • pgtap est un outil de tests unitaires pour les bases de données PostgreSQL.

Migrations

  • postgresql-migrations et bytebase gèrent les migrations de bases de données PostgreSQL.

Tableaux de bord / UI

  • Baserow, NocoDB, AppSmith fournissent des interfaces utilisateur et des tableaux de bord.

Visualisation de données

  • Evidence et Metabase sont des outils de visualisation de données.

HTML et applications

  • SQLpage, Omnigres, pg_render, plmustache intègrent les données PostgreSQL dans des applications web.

Serveur de langage

  • postgres_lsp fournit une prise en charge du protocole Language Server pour PostgreSQL.

Qu’est-ce qui manque ?

  • Merci de partager dans les commentaires ce qui aurait été oublié

L’avis de GN⁺

  • PostgreSQL montre, grâce à ses nombreuses extensions et à ses outils, qu’il est une plateforme polyvalente qui va bien au-delà d’un simple système de gestion de base de données.
  • Cet article propose aux développeurs une ressource utile en montrant comment PostgreSQL peut répondre à divers besoins applicatifs.
  • Il souligne en particulier le potentiel de simplification de l’architecture système et d’optimisation des performances grâce aux fonctionnalités pouvant être traitées directement dans la base de données.

À lire aussi

2 commentaires

 
eususu 2024-02-07

Parmi ceux-ci, j'utilise personnellement postgREST et j'en suis satisfait.
 
GN⁺ 2024-02-07
Avis Hacker News

  • Partage d’expérience sur les tentatives de simplification de la stack applicative

    Un utilisateur explique qu’il essaie souvent de simplifier la stack applicative, mais qu’à mesure que la complexité de l’application augmente, il finit par reconnaître la nécessité de recourir à plusieurs technologies. Vouloir tout regrouper dans une seule technologie comme Postgres peut devenir inconfortable. Malgré cela, étendre une technologie existante peut être préférable à l’ajout d’une nouvelle couche. Par exemple, utiliser Postgres comme file de messages est bien plus simple que de maintenir une file de messages séparée. Postgres est particulièrement extensible parmi les bases de données, et construire des outils dessus est très amusant.

  • Avis d’un créateur de ParadeDB sur l’extensibilité de Postgres

    En tant que l’un des créateurs de ParadeDB, il explique que Postgres peut fournir des fonctions de recherche et d’analyse rapides via des extensions. Pour de petites charges de travail, comme dans une startup, il est logique de rester dans Postgres aussi longtemps que possible. Mais à plus grande échelle, Postgres seul ne peut pas tout résoudre. Pour gérer différents types de charges dans Postgres, il faut séparer le système selon les besoins spécifiques et garantir une scalabilité et une résilience indépendantes. À ce stade, une stack de solutions spécialisées devient nécessaire. Il existe un mouvement visant à construire des composants de stack en version Postgres, mais chaque solution finit par aller au-delà de Postgres, et il ne pense pas qu’il existera une solution basée sur Postgres pour chaque composant d’une stack.

  • Avis sur le choix de commencer un nouveau projet avec sqlite

    Un utilisateur dit qu’il a décidé de démarrer chaque nouveau projet avec sqlite, sans migrer avant que ce soit absolument nécessaire. Si Postgres convient dans 90 % des cas, sqlite convient dans 80 % des cas, tout en étant facile à démarrer et performant. Si la montée en charge verticale finit par échouer, cela voudra dire qu’il sera déjà satisfait de ce qu’il a construit.

  • Interrogations d’un expert C++ sur les bases de données

    Un expert C++ peu familier avec les bases de données remet en question leur utilité. Il vient d’un secteur où l’on utilise beaucoup de formats de fichiers binaires sur mesure, et a l’impression que les bases de données semblent résoudre de nombreux problèmes en apparence, sans que ce soit réellement le cas. Les restrictions sur les types de données, les difficultés de mise à jour et les problèmes de compatibilité entre moteurs SQL donnent l’impression qu’utiliser une base de données est une mauvaise idée. Il comprend l’intérêt en matière d’interopérabilité pour de très gros volumes de données, mais en dehors de cela, il s’interroge sérieusement sur leur nécessité.

  • Avis sur les fonctionnalités additionnelles de PostgreSQL

    Un utilisateur souligne que la plupart des fonctionnalités additionnelles sont déjà intégrées à MariaDB, et cite une partie de la motivation derrière le client HTTP de PostgreSQL. À l’idée qu’il serait bien de pouvoir écrire des triggers qui appellent des services web, il répond qu’il préférerait laisser ce genre de chose à quelqu’un d’autre.

  • Problèmes de combinaison avec les pratiques de gestion de code lors de l’usage de fonctions avancées

    Il explique qu’il utilise largement Postgres, mais qu’à chaque fois qu’il emploie des fonctionnalités avancées, il se heurte au problème de les intégrer avec tous les bons aspects du développement logiciel : gestion de versions, revue de code, typage, tests, analyse statique, etc. Il pose une question sur les migrations.

  • Avantages du prototypage de nouvelles fonctionnalités avec la stack existante

    Un utilisateur partage son expérience : il vaut mieux prototyper une nouvelle fonctionnalité avec la stack existante plutôt que d’introduire quelque chose de nouveau dès le départ. Avec une sélection attentive, le prototype initial peut être transformé en code de production sur la même stack. Mais quand le système atteint ses limites, il peut devenir nécessaire d’utiliser Redis ou d’autres outils spécialisés. L’essentiel est d’écrire un wrapper d’API, de ne modifier ensuite que l’implémentation interne en cas de besoin, et de bien tester la migration. Il ajoute que les gens sont souvent surpris de voir combien de temps il est possible de repousser une décision technique.

  • Partage d’expérience d’un utilisateur utilisant Postgres, Redis et S3

    Un utilisateur indique qu’il utilise la combinaison Postgres, Redis et S3, et que ce trio ne l’a encore jamais déçu. Il a parfois envie d’essayer Pub/Sub avec Postgres, mais comme il a de toute façon besoin de Redis pour le cache et sidekiq, et que Redis est excellent, il ne voit pas l’intérêt d’insister.

  • Limites de Postgres pour l’analyse de données à grande échelle

    Un utilisateur explique qu’il aime beaucoup Postgres, mais qu’il a constaté qu’il ne suffisait plus lorsque le volume de données devient très important. Postgres est parfait pour les charges de type OLTP, mais pour des besoins plus poussés en OLAP, il recommande d’utiliser StarRocks. Son expérience d’ingestion de données depuis Postgres vers StarRocks pour l’analyse a été excellente, et StarRocks prend aussi en charge les requêtes directes sur un data lake.

  • Demande autour de la compression de jsonb dans Postgres

    Un utilisateur dit utiliser à la fois Mongo et PG, mais trouve PG bien plus simple et aimerait abandonner Mongo pour simplifier son architecture. Ce dont il a besoin, c’est simplement d’une colonne jsonb compressée, sur laquelle seules les opérations d’insertion, de sélection et de suppression seraient nécessaires, sans mise à jour ni requête complexe. Il souhaiterait conserver, comme dans Mongo, un taux de compression de 80 à 90 % sur les clés JSON répétitives, sans maintenance.