Pongo - Mongo basé sur Postgres avec une forte cohérence

• Pongo exploite la prise en charge de JSONB pour traiter PostgreSQL comme une base de données documentaire
  • JSONB stocke les données JSON au format binaire afin d’améliorer les performances et l’efficacité du stockage
• Le format binaire JSONB de PostgreSQL permet de pré-analyser les données, ce qui rend les opérations de lecture et d’écriture plus rapides
  • JSONB prend en charge des options d’indexation avancées comme les index GIN et GiST, ce qui améliore la vitesse de recherche
  • JSONB permet de stocker des données semi-structurées tout en utilisant les puissantes capacités de requête de PostgreSQL
• Pongo est-il un ORM ?
  • Non. Il se concentre sur le traitement efficace des caractéristiques propres aux données documentaires
  • Les ORM Node.js peuvent gérer JSONB, mais pour les requêtes avancées, il faut utiliser JSONPath ou les fonctions JSONB
  • Pongo s’en charge à votre place
• Est-ce prêt pour la production ?
  • Son utilisation est actuellement sûre, mais il n’est pas compatible à 100 % avec MongoDB
  • Pongo est un nouveau projet, et certaines fonctionnalités peuvent manquer
  • Il s’agit d’un projet communautaire : si vous trouvez des problèmes, il est recommandé d’élargir la prise en charge ou d’ajouter de la couverture de tests via des issues GitHub ou des Pull Requests

Le résumé de GN⁺

• Pongo est un outil qui utilise PostgreSQL comme base de données documentaire et convertit l’API MongoDB en requêtes PostgreSQL
• Il exploite les avantages de JSONB pour améliorer les performances et l’efficacité du stockage
• Il prend en charge les requêtes avancées et l’indexation afin d’offrir flexibilité et cohérence
• Pongo n’est pas un ORM et se concentre sur le traitement efficace des caractéristiques des données documentaires
• Comme il s’agit d’un nouveau projet, certaines fonctionnalités peuvent manquer, mais il peut être étendu grâce aux contributions de la communauté

[GN⁺]

Avis Hacker News

• Pongo a été ajouté à la section NoSQL
• Un modèle hybride est le meilleur choix. Les champs clés restent des colonnes classiques, tandis que les structures de données dynamiques sont conservées en JSONB
• C’est techniquement impressionnant, mais il manque une section « pourquoi » dans le README. On se demande si c’est pour utiliser l’API Mongo, ou simplement pour copier du code de projets existants
  • S’il s’agit de réutiliser les requêtes d’un autre projet, l’IA s’en sort plutôt bien
• J’ai utilisé une approche similaire en migrant un projet de Mongo vers Postgres. Les performances se sont nettement améliorées
  • Pour les futurs projets, je prévois de supprimer toute ressemblance avec Mongo
• Je me demande si Pongo est compatible avec Mongoose. La plupart des utilisateurs de Mongo utilisent Mongoose, donc le prendre en charge attirerait davantage d’utilisateurs
• En novembre 2023, j’avais fait un tweet en plaisantant sur Pongo. Coïncidence amusante, mais on pourrait croire que je peux prédire l’avenir
• J’utilise beaucoup les colonnes JSONB. C’est adapté à certaines applications, mais cela augmente la complexité des requêtes et fait perdre les gains de performance possibles avec une approche relationnelle
  • JSONB est utile, mais il ne faut pas renoncer aux avantages d’une base de données relationnelle
• Je me demande comment cela se compare à FerretDB
• MongoDB prend en charge depuis plusieurs années une fonctionnalité équivalente à l’isolation sérialisable de Postgres. Je ne vois pas clairement ce que signifient les « avantages d’une forte cohérence »
• La base de données Oracle propose une API compatible MongoDB depuis plusieurs années