Les dix principales raisons de migrer d'Oracle vers PostgreSQL

Oracle Relational Database Management System (RDBMS) a été largement utilisé par les grandes organisations et est considéré de loin comme la technologie de base de données la plus avancée disponible sur le marché. C'est généralement le SGBDR le plus souvent comparé à d'autres produits de base de données servant de norme "de facto" de ce qu'un produit devrait offrir. Il est classé par db-engines.com comme le SGBDR n°1 disponible sur le marché aujourd'hui.

PostgreSQL est classé au 4e rang des SGBDR, mais cela ne signifie pas qu'il n'y a aucun avantage à migrer vers PostgreSQL. PostgreSQL existe depuis 1989 et est devenu open source en 1996. PostgreSQL a remporté le SGBD de l'année deux années consécutives de 2017 à 2018. Cela indique simplement qu'il n'y a aucun signe d'arrêt d'attirer un grand nombre d'utilisateurs et de grandes organisations.

L'une des raisons pour lesquelles PostgreSQL a attiré beaucoup d'attention est que les gens recherchent une alternative à Oracle afin de réduire les coûts élevés des organisations et d'échapper à l'enfermement des fournisseurs.

Passer d'une base de données Oracle fonctionnelle et productive peut être une tâche intimidante. Des préoccupations telles que le TCO (coût total de possession) de l'entreprise sont l'une des raisons pour lesquelles les entreprises retardent leur décision d'abandonner ou non Oracle.

Dans ce blog, nous examinerons certaines des principales raisons pour lesquelles les entreprises choisissent de quitter Oracle et de migrer vers PostgreSQL.

Raison 1 :c'est un véritable projet Open Source

PostgreSQL est open-source et est publié sous la licence PostgreSQL, une licence Open Source libérale, similaire aux licences BSD ou MIT. L'acquisition du produit et de l'assistance est gratuite.

Si vous souhaitez tirer parti du logiciel de base de données, cela signifie que vous pouvez obtenir gratuitement toutes les fonctionnalités disponibles de la base de données PostgreSQL. PostgreSQL a plus de 30 ans de maturité dans le monde des bases de données et est basé sur le tactile en tant qu'open source depuis 1996. Il a bénéficié de décennies de développeurs travaillant pour créer des extensions. Cela, en soi, incite les développeurs, les institutions et les organisations à choisir PostgreSQL pour les applications d'entreprise; alimentant les principales applications professionnelles et mobiles.

Une fois de plus, les entreprises prennent conscience que les solutions de bases de données open source telles que Postgres offrent une capacité, une flexibilité et une assistance supérieures qui ne dépendent pas entièrement d'une entreprise ou d'un développeur en particulier. Postgres, comme Linux avant lui, a été (et continue d'être) conçu par des utilisateurs dédiés à la résolution de problèmes commerciaux quotidiens qui choisissent de rendre leurs solutions à la communauté. Contrairement à un grand développeur comme Oracle, qui peut avoir des motivations différentes pour développer des produits rentables ou soutenir un marché étroit mais lucratif, la communauté Postgres s'engage à développer les meilleurs outils possibles pour les utilisateurs quotidiens de bases de données relationnelles.

PostgreSQL exécute souvent ces tâches sans ajouter trop de complexité. Sa conception est strictement axée sur la gestion de la base de données sans avoir à gaspiller des ressources comme la gestion d'environnements informatiques supplémentaires grâce à des fonctionnalités supplémentaires. C'est l'une des choses que les consommateurs de ce logiciel open source aiment lors de la migration d'Oracle vers PostgreSQL. Passer des heures à étudier une technologie complexe sur le fonctionnement d'une base de données Oracle, ou sur la façon d'optimiser et de mettre au point peut se retrouver avec son support coûteux. Cela incite les institutions ou les organisations à trouver une alternative qui peut être moins casse-tête sur le coût et apporter des bénéfices et de la productivité. Veuillez consulter notre blog précédent sur la capacité de PostgreSQL à faire correspondre la présence de la syntaxe SQL avec la syntaxe d'Oracle.

Raison 2 :pas de licence et une grande communauté

Pour les utilisateurs de la plate-forme Oracle RDBMS, il est difficile de trouver un type de support communautaire gratuit ou sans frais élevés. Les institutions, les organisations et les développeurs finissent souvent par trouver une information alternative en ligne qui peut offrir gratuitement des réponses ou des solutions à leurs problèmes.

Lorsque vous utilisez Oracle, il est difficile de décider d'un produit spécifique ou d'opter pour le support produit car (généralement) beaucoup d'argent est impliqué. Vous pourriez essayer un produit spécifique pour le tester, finir par l'acheter, juste pour réaliser qu'il ne peut pas vous aider. Avec PostgreSQL, la communauté est gratuite et regorge d'experts qui ont une vaste expérience et qui sont heureux de vous aider à résoudre vos problèmes actuels.

Vous pouvez vous inscrire à la liste de diffusion ici même sur https://lists.postgresql.org/ pour commencer à contacter la communauté. Les débutants ou les prodiges de PostgreSQL sont basés ici pour communiquer, présenter et partager leurs solutions, leur technologie, leurs bogues, leurs nouvelles découvertes ou même partager leurs logiciels émergents. Vous pouvez même demander de l'aide à partir du chat IRC en utilisant irc.freenode.net et en rejoignant le canal #postgresql. Vous pouvez également contacter la communauté via Slack en vous joignant à https://postgres-slack.herokuapp.com/ ou https://postgresteam.slack.com/. Il y a beaucoup d'options à prendre et beaucoup d'organisations Open Source qui peuvent vous poser des questions

Pour plus de détails et d'informations sur où commencer, rendez-vous ici https://www.postgresql.org/community/.

Si vous souhaitez accéder aux services professionnels dans PostgreSQL, vous avez le choix entre une multitude d'options. Même en consultant leur site Web à https://www.postgresql.org/support/professional_support/northamerica/, vous pouvez y trouver une grande liste d'entreprises et certaines d'entre elles sont à un prix bon marché. Même ici chez Manynines, nous proposons également un support pour Postgres, qui fait partie de la licence ClusterControl ou d'un conseil DBA.

Raison 3 :  Large prise en charge de la conformité SQL

PostgreSQL a toujours été soucieux de s'adapter et de se conformer à SQL en tant que norme de facto pour son langage. Le nom formel de la norme SQL est ISO/IEC 9075 « Database Language SQL ». Toutes les versions révisées successives des versions standard remplacent la précédente, de sorte que les revendications de conformité aux versions antérieures n'ont aucun mérite officiel.

Contrairement à Oracle, certains mots clés ou opérateurs sont toujours présents et ne sont pas conformes à la norme ANSI SQL (Structured Query Language). Par exemple, l'opérateur OUTER JOIN (+) peut attribuer des confusions avec d'autres DBA qui n'ont pas touché ou avec le moins de familiarité avec Oracle. PostgreSQL suit la norme ANSI-SQL pour la syntaxe JOIN et cela laisse un avantage pour sauter facilement et simplement avec d'autres bases de données RDBMS open source telles que les bases de données MySQL/Percona/MariaDB.

Une autre syntaxe très courante avec Oracle consiste à utiliser des requêtes hiérarchiques. Oracle utilise la syntaxe non standard START WITH..CONNECT BY, tandis que dans SQL:1999, les requêtes hiérarchiques sont implémentées au moyen d'expressions de table communes récursives. Par exemple, les requêtes ci-dessous diffèrent par leur syntaxe en fonction des requêtes hiérarchiques :

Oracle

SELECT

    restaurant_name, 

    city_name 

FROM

    restaurants rs 

START WITH rs.city_name = 'TOKYO'

CONNECT BY PRIOR rs.restaurant_name = rs.city_name;

PostgreSQL

WITH RECURSIVE tmp AS (SELECT restaurant_name, city_name

                                 FROM restaurants

                                WHERE city_name = 'TOKYO'

                                UNION

                               SELECT m.restaurant_name, m.city_name

                                 FROM restaurants m

                                 JOIN tmp ON tmp.restaurant_name = m.city_name)

                  SELECT restaurant_name, city_name FROM tmp;

PostgreSQL a une approche très similaire à celle des autres principaux SGBDR open source comme MySQL/MariaDB.

Selon le manuel PostgreSQL, le développement de PostgreSQL vise la conformité avec la dernière version officielle de la norme lorsqu'une telle conformité ne contredit pas les fonctionnalités traditionnelles ou le bon sens. De nombreuses fonctionnalités requises par la norme SQL sont prises en charge, bien que parfois avec une syntaxe ou une fonction légèrement différente. C'est, en fait, ce qui est génial avec PostgreSQL car il est également pris en charge et collaboré par les différentes organisations, qu'elles soient petites ou grandes. La beauté reste sur la conformité de son langage SQL à ce qu'a fait passer le standard.

Le développement de PostgreSQL vise la conformité avec la dernière version officielle de la norme lorsqu'une telle conformité ne contredit pas les fonctionnalités traditionnelles ou le bon sens. De nombreuses fonctionnalités requises par la norme SQL sont prises en charge, bien que parfois avec une syntaxe ou une fonction légèrement différente. D'autres mouvements vers la conformité peuvent être attendus au fil du temps.

Quatrième raison :parallélisme des requêtes

Pour être juste, le parallélisme des requêtes de PostgreSQL n'est pas aussi riche que l'exécution parallèle d'Oracle pour les instructions SQL. Parmi les fonctionnalités du parallélisme d'Oracle figurent la mise en file d'attente des instructions avec des conseils, la possibilité de définir le degré de parallélisme (DOP), de définir une politique de degré parallèle ou le parallélisme adaptatif.

PostgreSQL a un simple degré de parallélisme basé sur les plans pris en charge, mais cela ne définit pas qu'Oracle dépasse l'open source PostgreSQL.

Le parallélisme de PostgreSQL a été constamment amélioré et continuellement amélioré par la communauté. Lorsque PostgreSQL 10 a été publié, il a ajouté plus d'attrait pour le public, en particulier les améliorations sur la prise en charge du parallélisme pour la jointure de fusion, l'analyse de tas bitmap, l'analyse d'index et l'analyse d'index uniquement, la fusion de collecte, etc. Les améliorations ajoutent également des statistiques à pg_stat_activity.

Dans les versions de PostgreSQL < 10, le parallélisme est désactivé par défaut et vous devez définir la variable max_parallel_workers_per_gather.

postgres=# \timing

Timing is on.

postgres=# explain analyze select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

                                                   QUERY PLAN                                                   

----------------------------------------------------------------------------------------------------------------

 Seq Scan on movies  (cost=0.00..215677.28 rows=41630 width=68) (actual time=0.013..522.520 rows=84473 loops=1)

   Filter: ((birthyear >= 1980) AND (birthyear <= 2005))

   Rows Removed by Filter: 8241546

 Planning time: 0.039 ms

 Execution time: 525.195 ms

(5 rows)



Time: 525.582 ms

postgres=# \o /dev/null 

postgres=#  select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

Time: 596.947 ms

Le plan de requête révèle que c'est le temps réel qui peut tourner autour de 522,5 ms alors que le temps réel d'exécution de la requête tourne autour de 596,95 ms. Alors que permettre le parallélisme,

postgres=# set max_parallel_workers_per_gather=2;

Time: 0.247 ms

postgres=# explain analyze select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

                                                          QUERY PLAN                                                           

-------------------------------------------------------------------------------------------------------------------------------

 Gather  (cost=1000.00..147987.62 rows=41630 width=68) (actual time=0.172..339.258 rows=84473 loops=1)

   Workers Planned: 2

   Workers Launched: 2

   ->  Parallel Seq Scan on movies  (cost=0.00..142824.62 rows=17346 width=68) (actual time=0.029..264.980 rows=28158 loops=3)

         Filter: ((birthyear >= 1980) AND (birthyear <= 2005))

         Rows Removed by Filter: 2747182

 Planning time: 0.096 ms

 Execution time: 342.735 ms

(8 rows)



Time: 343.142 ms

postgres=# \o /dev/null

postgres=#  select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

Time: 346.020 ms

Le plan de requête détermine que la requête doit utiliser le parallélisme, puis elle utilise un nœud Gather. Il s'agit d'estimations de temps réelles à 339 ms avec 2 travaux et d'estimations à 264 ms avant d'être agrégées par le plan de requête. Maintenant, le temps d'exécution réel de la requête a pris 346 ms, ce qui est très proche du temps réel estimé du plan de requête.

Cela illustre à quel point c'est rapide et avantageux avec PostgreSQL. Bien que PostgreSQL ait ses propres limites lorsque le parallélisme peut se produire ou lorsque le plan de requête détermine qu'il est plus rapide que d'utiliser le parallélisme, cela ne fait pas une énorme différence avec Oracle. Le parallélisme de PostgreSQL est flexible et peut être activé ou utilisé correctement tant que votre requête correspond à la séquence requise pour le parallélisme des requêtes.

Raison 5 :Prise en charge avancée de JSON et amélioration constante

La prise en charge de JSON dans PostgreSQL est toujours comparable à celle des autres SGBDR open source. Jetez un œil à ce blog externe de LiveJournal où le support JSON de PostgreSQL se révèle être toujours plus avancé par rapport aux autres RDBMS. PostgreSQL possède un grand nombre de fonctions et fonctionnalités JSON.

Le type de données JSON a été introduit dans PostgreSQL-9.2. Depuis lors, il a fait l'objet de nombreuses améliorations importantes et parmi les principaux ajouts apportés à PostgreSQL-9.4 avec l'ajout du type de données JSONB. PostgreSQL propose deux types de données pour stocker les données JSON :json et jsonb. Avec jsonb, il s'agit d'une version avancée du type de données JSON qui stocke les données JSON au format binaire. Il s'agit de l'amélioration majeure qui a fait une grande différence dans la façon dont les données JSON ont été recherchées et traitées dans PostgreSQL.

Oracle prend également en charge JSON. En revanche, PostgreSQL dispose d'un support étendu ainsi que de fonctions pouvant être utilisées pour la récupération de données, le formatage des données ou les opérations conditionnelles qui affectent la sortie des données ou même les données stockées dans la base de données. Les données stockées avec le type de données jsonb ont un plus grand avantage avec la possibilité d'utiliser GIN (Index inversé généralisé) qui peut être utilisé pour rechercher efficacement des clés ou des paires clé/valeur se produisant dans un grand nombre de documents jsonb.

PostgreSQL a des extensions supplémentaires qui sont utiles pour implémenter TRANSFORM FOR TYPE pour le type jsonb dans ses langages de procédure pris en charge. Ces extensions sont jsonb_plperl et jsonb_plperlu pour PL/Perl. Alors que pour PL/Python, ce sont jsonb_plpythonu, jsonb_plpython2u et jsonb_plpython3u. Par exemple, en utilisant des valeurs jsonb pour mapper des tableaux Perl, vous pouvez utiliser les extensions jsonb_plperl ou jsonb_plperlu.

ArangoDB a publié un benchmark comparant les performances JSON de PostgreSQL avec d'autres bases de données prenant en charge JSON. Bien qu'il s'agisse d'un ancien blog, il présente toujours les performances de JSON de PostgreSQL par rapport à d'autres bases de données où JSON est la fonctionnalité principale de leur noyau de base de données. Cela fait que PostgreSQL a son propre avantage, même avec sa fonctionnalité secondaire.

Sixième raison :Prise en charge de DBaaS par les principaux fournisseurs de cloud

PostgreSQL a été largement pris en charge en tant que DBaaS. Ces services proviennent d'Amazon, de Microsoft avec sa base de données Azure pour PostgreSQL et de Google Cloud SQL pour PostgreSQL.

En comparaison Oracle, n'est disponible que sur Amazon RDS pour Oracle. Les services offerts par les principaux acteurs commencent à un prix abordable et sont très flexibles à configurer en fonction de vos besoins. Cela aide les institutions et les organisations à s'installer en conséquence et à réduire les coûts importants liés à la plate-forme Oracle.

Septième raison : meilleur traitement d'énormes quantités de données

Les SGBDR PostgreSQL ne sont pas conçus pour gérer les charges de travail d'analyse et d'entreposage de données. PostgreSQL est une base de données orientée lignes, mais elle a la capacité de stocker une grande quantité de données. PostgreSQL a les limites suivantes pour gérer le magasin de données :

Si vous souhaitez utiliser les fonctionnalités de base de PostgreSQL, vous pouvez stocker une grande quantité de données à l'aide de jsonb. Par exemple, une grande quantité de documents (PDF, Word, feuilles de calcul) et stockez-les en utilisant le type de données jsonb. Pour les applications et systèmes de géolocalisation, vous pouvez utiliser PostGIS.

Raison 8 :évolutivité, haute disponibilité, redondance/géo-redondance et solutions tolérantes aux pannes à bas prix

Oracle propose des solutions similaires, mais puissantes, telles qu'Oracle Grid, Oracle Real Application Clusters (RAC), Oracle Clusterware et Oracle Data Guard, pour n'en nommer que quelques-unes. Ces technologies peuvent augmenter vos coûts croissants et coûtent cher à déployer et à stabiliser. Il est difficile d'abandonner ces solutions. La formation et les compétences doivent être renforcées et développer les personnes impliquées dans le processus de déploiement et de mise en œuvre.

PostgreSQL bénéficie d'un support massif et propose de nombreuses options. PostgreSQL inclut le streaming et la réplication logique intégrés au package principal du logiciel. Vous pouvez également configurer une réplication synchrone pour PostgreSQL afin d'avoir un cluster plus haute disponibilité, tout en faisant en sorte qu'un nœud de secours traite vos requêtes de lecture. Pour une haute disponibilité, nous vous suggérons de lire notre blog Top PG Clustering High Availability (HA) Solutions for PostgreSQL et qui couvre de nombreux outils et technologies parmi lesquels choisir.

Il existe également des fonctionnalités d'entreprise qui offrent des solutions de haute disponibilité, de surveillance et de sauvegarde. ClusterControl est l'une de ces technologies et offre à un prix abordable par rapport aux solutions Oracle.

Raison 9 :  Prise en charge de plusieurs langages procéduraux :PL/pgSQL, PL/Tcl, PL/Perl et PL/Python.

Depuis la version 9.4, PostgreSQL a une grande fonctionnalité où vous pouvez définir un nouveau langage procédural selon votre choix. Bien que tous les langages de programmation ne soient pas pris en charge, un certain nombre de langages sont pris en charge. Actuellement, avec la distribution de base, il inclut PL/pgSQL, PL/Tcl, PL/Perl et PL/Python. Les langues externes sont :

Ce qui est formidable, c'est que, contrairement à Oracle, les développeurs qui se sont récemment lancés dans PostgreSQL peuvent rapidement fournir une logique métier à leurs systèmes d'application sans prendre davantage de temps pour se familiariser avec PL/SQL. PostgreSQL rend l'environnement des développeurs plus simple et efficace. Cette nature de PostgreSQL contribue à la raison pour laquelle les développeurs aiment PostgreSQL et commencent à s'éloigner des solutions de plate-forme d'entreprise vers l'environnement open source.

Raison 10  :  index flexibles pour les données volumineuses et textuelles (GIN, GiST, SP-GiST et BRIN)

PostgreSQL a un énorme avantage lorsqu'il s'agit de la prise en charge d'index qui sont bénéfiques pour la gestion de données volumineuses. Oracle propose de nombreux types d'index qui sont également utiles pour gérer de grands ensembles de données, en particulier pour l'indexation de texte intégral. Mais pour PostgreSQL, ces types d'index sont conçus pour être flexibles en fonction de votre objectif. Par exemple, ces types d'index sont applicables pour les données volumineuses :

GIN - (Index inversés généralisés) 

Ce type d'index s'applique aux colonnes de type de données jsonb, hstore, range et arrays. Il est utile lorsque vous avez des types de données qui contiennent plusieurs valeurs dans une seule colonne. Selon la documentation PostgreSQL, "GIN est conçu pour gérer les cas où les éléments à indexer sont des valeurs composites, et les requêtes à gérer par l'index doivent rechercher des valeurs d'éléments qui apparaissent dans les éléments composites. Par exemple, les éléments peuvent être des documents et les requêtes peuvent être des recherches de documents contenant des mots spécifiques. »

GiST - (Arbre de recherche généralisé)

Un arbre de recherche équilibré en hauteur qui se compose de pages de nœuds. Les nœuds sont constitués de lignes d'index. Chaque ligne d'un nœud feuille (ligne feuille), en général, contient un prédicat (expression booléenne) et une référence à une ligne de table (TID). Les index GiST sont meilleurs si vous les utilisez pour un type de données géométriques comme, vous voulez voir si deux polygones contiennent un point. Dans un cas, un point spécifique peut être contenu dans une boîte, tandis qu'un autre point n'existe que dans un polygone. Les types de données les plus courants pour lesquels vous souhaitez exploiter les index GiST sont les types de géométrie et le texte lors de la recherche en texte intégral

Lors du choix du type d'index à utiliser, GiST ou GIN, tenez compte de ces différences de performances :

• Les recherches d'index GIN sont environ trois fois plus rapides que GiST
• Les index GIN prennent environ trois fois plus de temps à construire que GiST
• Les index GIN sont modérément plus lents à mettre à jour que les index GiST, mais environ 10 fois plus lents si la prise en charge de la mise à jour rapide a été désactivée
• Les index GIN sont deux à trois fois plus grands que les index GiST

En règle générale, les index GIN sont les meilleurs pour les données statiques car les recherches sont plus rapides. Pour les données dynamiques, les index GiST sont plus rapides à mettre à jour.

SP-GiST - (GiST partitionné par espace) 

Pour des ensembles de données plus volumineux avec un regroupement naturel mais inégal. Ce type d'index tire parti des arborescences de partitionnement d'espace. Les index SP-GiST sont plus utiles lorsque vos données comportent un élément de regroupement naturel et ne constituent pas non plus un arbre équilibré. Les numéros de téléphone en sont un bon exemple. Par exemple, aux États-Unis, ils utilisent le format suivant :

• 3 chiffres pour l'indicatif régional
• 3 chiffres pour le préfixe (historiquement lié au commutateur d'un opérateur téléphonique)
• 4 chiffres pour le numéro de ligne

Cela signifie que vous avez un regroupement naturel autour du premier ensemble de 3 chiffres, autour du deuxième ensemble de 3 chiffres, puis les nombres peuvent se répartir dans une distribution plus uniforme. Mais, avec les numéros de téléphone, certains indicatifs régionaux ont une saturation beaucoup plus élevée que d'autres. Le résultat peut être que l'arbre est très déséquilibré. En raison de ce regroupement naturel à l'avant et de la distribution inégale des données, des données telles que les numéros de téléphone pourraient constituer un bon argument pour SP-GiST.

BRIN - (Index de plage de blocs) 

Pour les ensembles de données très volumineux qui s'alignent séquentiellement. Une plage de blocs est un groupe de pages adjacentes les unes aux autres, où des informations récapitulatives sur toutes ces pages sont stockées dans Index. Les index de plage de blocs peuvent se concentrer sur certains cas d'utilisation similaires à SP-GiST en ce sens qu'ils sont meilleurs lorsqu'il existe un ordre naturel des données et que les données ont tendance à être très volumineuses. Vous avez un tableau d'un milliard d'enregistrements, surtout s'il s'agit de données de séries chronologiques ? BRIN peut être en mesure de vous aider. Si vous interrogez un grand ensemble de données qui sont naturellement regroupées, telles que des données pour plusieurs codes postaux (qui s'étendent ensuite à une ville), BRIN aide à garantir que des codes postaux similaires sont situés les uns à côté des autres sur le disque.

Lorsque vous avez de très grands ensembles de données ordonnés tels que des dates ou des codes postaux, les index BRIN vous permettent d'ignorer ou d'exclure très rapidement de nombreuses données inutiles. Les BRIN sont en outre maintenus sous forme d'index plus petits par rapport à la taille globale des données, ce qui en fait un avantage considérable lorsque vous disposez d'un grand ensemble de données.

Conclusion

PostgreSQL présente des avantages majeurs lorsqu'il est en concurrence avec la plate-forme d'entreprise et les solutions commerciales d'Oracle. Il est certainement facile de saluer PostgreSQL comme votre choix de RDBMS open source car il est presque aussi puissant qu'Oracle.

Oracle est difficile à battre (et c'est une vérité difficile à accepter) et il n'est pas non plus facile d'abandonner la plate-forme d'entreprise du géant de la technologie. Lorsque les systèmes vous fournissent de la puissance et des résultats productifs, cela peut être un dilemme.

Parfois, bien qu'il y ait des situations où une décision doit être prise, car le surinvestissement continu dans le coût de votre plate-forme peut l'emporter sur le coût de vos autres couches et priorités commerciales qui peuvent affecter les progrès.

PostgreSQL et ses solutions de plate-forme sous-jacentes peuvent être de choix pour vous aider à réduire les coûts, soulager vos problèmes budgétaires ; le tout avec des changements modérés à petits.