Pourquoi PostgreSQL est le fondement de l'avenir des données

L’une des plus grandes tendances actuelles en matière de développement de logiciels est l’émergence de PostgreSQL comme standard de facto en matière de bases de données. Il y a eu quelques articles de blog sur la façon d'utiliser PostgreSQL pour tout, mais aucun pour l'instant sur la raison pour laquelle cela se produit (et plus important encore, pourquoi cela est important).

Jusqu'à maintenant!

Table des matières

01 PostgreSQL devient le standard de base de données de facto

02 Tout devient un ordinateur

03 Le retour de PostgreSQL

04 Libérez-vous, construisez l'avenir, adoptez PostgreSQL

05 Échelle de temps démarrée en tant que « PostgreSQL pour les séries temporelles »

06 Échelle de temps étendue au-delà des séries chronologiques

07 L'échelle de temps est désormais « PostgreSQL rendu puissant »

08 Coda : Yoda ?

PostgreSQL devient le standard de base de données de facto

Au cours des derniers mois, « PostgreSQL for Everything » est devenu un cri de guerre croissant parmi les développeurs :

« PostgreSQL n'est pas qu'une simple base de données relationnelle ; il s'agit d'un cadre de gestion de données susceptible d'engloutir l'ensemble du domaine des bases de données. La tendance « Utiliser Postgres pour tout » ne se limite plus à quelques équipes d'élite, mais devient une bonne pratique courante. »

( source )

« Une façon de simplifier votre pile et de réduire les pièces mobiles, d'accélérer le développement, de réduire les risques et d'offrir plus de fonctionnalités dans votre startup est d'utiliser Postgres pour tout. » Postgres peut remplacer (jusqu'à des millions d'utilisateurs) de nombreuses technologies backend, parmi lesquelles Kafka, RabbitMQ, Mongo et Redis.

( source )

( Source )

"Quand j'ai entendu parler de Postgres pour la première fois (à une époque où MySQL dominait absolument), on m'a décrit comme "cette base de données créée par ces nerds en mathématiques", puis je me suis dit : oui, ce sont exactement les personnes que vous voulez créer. votre base de données.

( Source )

« Il a fait un retour remarqué. Maintenant que NoSQL est mort et qu'Oracle possède MySQL, qu'y a-t-il d'autre ?

( Source )

« Postgres n'est pas seulement une base de données relationnelle. C'est une manière de vivre."

( Source )

Grâce à sa base solide et à sa polyvalence grâce à des fonctionnalités et des extensions natives, les développeurs peuvent désormais utiliser PostgreSQL for Everything, remplaçant les architectures de données complexes et fragiles par une simplicité simple :

Cela pourrait aider à expliquer pourquoi PostgreSQL a pris l'année dernière la première place devant MySQL dans le classement de la base de données la plus populaire parmi les développeurs professionnels (60 369 répondants) :

Dans quels environnements de bases de données avez-vous effectué un travail de développement approfondi au cours de l'année écoulée et dans lesquels souhaitez-vous travailler au cours de l'année prochaine ? Plus de 49 % des personnes interrogées ont répondu PostgreSQL. ( Source )

Ces résultats proviennent de l’enquête 2023 auprès des développeurs Stack Overflow. Si vous regardez au fil du temps, vous pouvez constater l’augmentation constante de l’adoption de PostgreSQL au cours des dernières années :

Bien que PostgreSQL soit la deuxième base de données préférée des répondants à l'enquête auprès des développeurs de Stack Overflow entre 2020 et 2022, son utilisation a constamment augmenté. Source: 2020 , 2021 , 2022

Ce n’est pas seulement une tendance parmi les petites startups et les amateurs. En fait, l’utilisation de PostgreSQL augmente dans les organisations de toutes tailles :

Le pourcentage d'utilisation de PostgreSQL par taille d'entreprise. ( Source )

Chez Timescale, cette tendance n’est pas nouvelle pour nous. Nous croyons à PostgreSQL depuis près d’une décennie. C'est pourquoi nous avons bâti notre activité sur PostgreSQL, pourquoi nous sommes l'un des principaux contributeurs à PostgreSQL , pourquoi nous organisons l'année Enquête sur l'état de PostgreSQL (référencé ci-dessus) et pourquoi nous prenons en charge les rencontres et conférences PostgreSQL. Personnellement, j'utilise PostgreSQL depuis plus de 13 ans (lorsque j'ai quitté MySQL).

Il y a eu quelques articles de blog sur la façon d'utiliser PostgreSQL pour tout, mais aucun pour l'instant sur la raison pour laquelle cela se produit (et, plus important encore, pourquoi cela est important).

Jusqu'à maintenant.

Mais pour comprendre pourquoi cela se produit, nous devons comprendre une tendance encore plus fondamentale et comment cette tendance change la nature fondamentale de la réalité humaine.

Tout devient un ordinateur

Tout – nos voitures, nos maisons, nos villes, nos fermes, nos usines, nos monnaies, nos objets – devient un ordinateur. Nous aussi, nous devenons numériques. Chaque année, nous numérisons davantage notre identité et nos actions : comment nous achetons des choses, comment nous nous divertissons, comment nous collectionnons des œuvres d'art, comment nous trouvons des réponses à nos questions, comment nous communiquons et nous connectons, comment nous exprimons qui nous sommes.

Il y a vingt-deux ans, cette idée d’« informatique ubiquitaire » paraissait audacieuse. À l’époque, j’étais étudiant diplômé au MIT AI Lab et je travaillais sur mon thèse sur les environnements intelligents. Mes recherches ont été soutenues par Projet Oxygène du MIT , qui avait un objectif noble et audacieux : rendre l’informatique aussi omniprésente que l’air que nous respirons. Pour mettre cette époque en perspective : nous avions notre rack de serveur dans un placard.

Beaucoup de choses ont changé depuis. L'informatique est désormais omniprésente : sur nos bureaux, dans nos poches, dans nos affaires et dans notre « cloud ». C’est ce que nous avions prédit.

Mais les effets secondaires de ces changements n’étaient pas ceux auxquels la plupart d’entre nous s’attendaient :

• L'informatique omniprésente a conduit à des données omniprésentes . Avec chaque nouvel appareil informatique, nous collectons davantage d’informations sur notre réalité : données humaines, données machines, données commerciales, données environnementales et données synthétiques. Ces données inondent notre monde.

  
  

• Le flot de données a conduit à une explosion cambrienne des bases de données . Toutes ces nouvelles sources de données ont nécessité de nouveaux lieux de stockage. Il y a vingt ans, il existait peut-être cinq options de bases de données viables. Il en existe aujourd’hui plusieurs centaines, la plupart spécialisées dans des cas d’usage ou des données spécifiques, et de nouvelles apparaissent chaque mois.

  
  

• Plus de données et plus de bases de données ont conduit à une complexité logicielle accrue . Choisir la bonne base de données pour votre charge de travail logicielle n'est plus facile. Au lieu de cela, les développeurs sont obligés de bricoler des architectures complexes qui peuvent inclure : une base de données relationnelle (pour sa fiabilité), une base de données non relationnelle (pour son évolutivité), un entrepôt de données (pour sa capacité à servir l'analyse), un magasin d'objets (pour sa capacité à servir l'analyse). pour sa capacité à archiver des données anciennes à moindre coût). Cette architecture peut même comporter des composants plus spécialisés, comme une base de données de séries chronologiques ou vectorielles.

  
  

• Plus de complexité signifie moins de temps de construction. Les architectures complexes sont plus fragiles, nécessitent une logique d'application plus complexe, offrent moins de temps de développement et ralentissent le développement. La complexité n'est pas un avantage mais un coût réel.

À mesure que l’informatique est devenue omniprésente, notre réalité est devenue de plus en plus liée à l’informatique. Nous avons introduit l'informatique dans notre monde et nous-mêmes dans son monde. Nous ne sommes plus seulement nos identités hors ligne, mais un hybride de ce que nous faisons hors ligne et en ligne.

Les développeurs de logiciels sont l’avant-garde de l’humanité dans cette nouvelle réalité. C'est nous qui construisons le logiciel qui façonne cette nouvelle réalité.

Mais les développeurs sont désormais inondés de données et noyés dans la complexité des bases de données.

Cela signifie que les promoteurs, au lieu de façonner l’avenir, consacrent de plus en plus de temps à gérer la plomberie.

Comment est-ce qu'on est arrivés ici?

Partie 1 : Ondes de calcul en cascade

L’informatique omniprésente a conduit à des données omniprésentes. Cela ne s’est pas produit du jour au lendemain mais par vagues en cascade sur plusieurs décennies :

• Ordinateurs centraux (années 1950 et plus)
• Ordinateurs personnels (années 1970 et plus)
• Internet (années 1990 et plus)
• Mobile (années 2000 et plus)
• Informatique en nuage (années 2000 et plus)
• Internet des objets (années 2010 et plus)

À chaque vague, les ordinateurs sont devenus plus petits, plus puissants et plus omniprésents. Chaque vague s'appuie également sur la précédente : les ordinateurs personnels sont des ordinateurs centraux plus petits ; Internet est un réseau d'ordinateurs connectés ; les smartphones sont des ordinateurs encore plus petits connectés à Internet ; le cloud computing a démocratisé l'accès aux ressources informatiques ; l'Internet des objets est constitué de composants de smartphone reconstruits dans le cadre d'autres objets physiques connectés au Cloud.

Mais au cours des deux dernières décennies, les progrès informatiques ne se sont pas produits uniquement dans le monde physique mais également dans le monde numérique, reflétant notre réalité hybride :

• Réseaux sociaux (2000+)
• Blockchains (années 2010 et plus)
• IA générative (années 2020+)

À chaque nouvelle vague informatique, nous obtenons de nouvelles sources d’informations sur notre réalité hybride : l’épuisement numérique humain, les données des machines, les données commerciales et les données synthétiques. Les vagues futures créeront encore plus de données. Toutes ces données alimentent de nouvelles vagues, dont la dernière en date est l’IA générative, qui à son tour façonne davantage notre réalité.

Les vagues de calcul ne sont pas cloisonnées mais cascadent comme des dominos. Ce qui a commencé comme une fuite de données s’est rapidement transformé en un flot de données. Et puis le flot de données a conduit à la création de plus en plus de bases de données.

Partie 2 : Croissance incrémentielle de la base de données

Toutes ces nouvelles sources de données ont nécessité de nouveaux emplacements pour les stocker, ou bases de données.

Les ordinateurs centraux ont démarré avec le Magasin de données intégré (1964) et plus tard Système R (1974), la première base de données SQL. Les ordinateurs personnels ont favorisé l’essor des premières bases de données commerciales : Oracle (1977), inspiré du Système R ; DB2 (1983); et serveur SQL (1989), la réponse de Microsoft à Oracle.

La puissance collaborative d'Internet a permis l'essor des logiciels open source, notamment les premières bases de données open source : MySQL (1995), PostgreSQL (1996). Les smartphones ont conduit à la prolifération de SQLite (initialement créé en 2000).

Internet a également créé une quantité massive de données, qui a conduit aux premières bases de données non relationnelles, ou NoSQL : Hadoop (2006); Cassandre (2008); MongoDB (2009). Certains ont appelé cela l’ère du « Big Data ».

Partie 3 : Croissance explosive des bases de données

Vers 2010, nous avons commencé à atteindre un point de rupture. Jusque-là, les applications logicielles reposaient principalement sur une seule base de données (par exemple, Oracle, MySQL, PostgreSQL) et le choix était relativement simple.

Mais le « Big Data » n’a cessé de prendre de l’ampleur : l’Internet des objets a entraîné l’essor des données machine ; l'utilisation des smartphones a commencé à croître de façon exponentielle grâce à l'iPhone et à Android, conduisant à un épuisement numérique encore plus humain ; Le cloud computing a démocratisé l'accès au calcul et au stockage, amplifiant ces tendances. L’IA générative a très récemment aggravé ce problème avec la création de données vectorielles.

À mesure que le volume de données collectées augmentait, nous avons assisté à l’essor des bases de données spécialisées : Néo4j pour les données graphiques (2007), Rédis pour un magasin clé-valeur de base (2009), InfluxDB pour les données de séries chronologiques (2013), Cliquez sur Maison pour l'analyse à grande échelle (2016), Pinecone pour les données vectorielles (2019) et bien d'autres encore.

Il y a vingt ans, il existait peut-être cinq options de bases de données viables. Aujourd'hui, il y a plusieurs centaines , la plupart d’entre eux sont spécialisés dans des cas d’utilisation spécifiques, et de nouveaux apparaissent chaque mois. Alors que les bases de données précédentes promettent une polyvalence générale, ces bases de données spécialisées proposent des compromis spécifiques, qui peuvent ou non avoir du sens selon votre cas d'utilisation.

Partie 4 : Plus de bases de données, plus de problèmes

Face à ce flot et à des bases de données spécialisées avec de nombreux compromis, les développeurs n'ont eu d'autre choix que de bricoler des architectures complexes.

Ces architectures incluent généralement une base de données relationnelle (pour la fiabilité), une base de données non relationnelle (pour l'évolutivité), un entrepôt de données (pour l'analyse des données), un magasin d'objets (pour un archivage bon marché) et des composants encore plus spécialisés comme une série chronologique. ou une base de données vectorielle pour ces cas d'utilisation.

Mais plus de complexité signifie moins de temps de construction. Les architectures complexes sont plus fragiles, nécessitent une logique d'application plus complexe, offrent moins de temps de développement et ralentissent le développement.

Cela signifie qu’au lieu de construire l’avenir, les développeurs de logiciels se retrouvent à consacrer beaucoup trop de temps à l’entretien de la plomberie. C'est là que nous sommes aujourd'hui.

Il y a un meilleur moyen.

Le retour de PostgreSQL

C'est là que notre histoire prend un tournant. Notre héros, au lieu d'être une toute nouvelle base de données, est un vieux pilier, avec un nom que seul un développeur principal pourrait aimer : PostgreSQL.

Au début, PostgreSQL était loin derrière MySQL. MySQL était plus facile à utiliser, avait une entreprise derrière lui et un nom que tout le monde pouvait facilement prononcer. Mais MySQL a ensuite été racheté par Sun Microsystems (2008), qui a ensuite été racheté par Oracle (2009). Et les développeurs de logiciels, qui considéraient MySQL comme le sauveur gratuit de la coûteuse dictature d'Oracle, ont commencé à reconsidérer ce qu'il fallait utiliser.

Au même moment, une communauté distribuée de développeurs, parrainée par une poignée de petites entreprises indépendantes, améliorait progressivement PostgreSQL. Ils ont discrètement ajouté des fonctionnalités puissantes, telles que la recherche en texte intégral (2008), les fonctions de fenêtre (2009) et la prise en charge de JSON (2012). Ils ont également rendu la base de données plus solide, grâce à des fonctionnalités telles que la réplication en streaming, la veille chaude, la mise à niveau sur place (2010), la réplication logique (2017), et en corrigeant avec diligence les bogues et en lissant les aspérités.

PostgreSQL est désormais une plateforme

L'une des fonctionnalités les plus marquantes ajoutées à PostgreSQL à cette époque était la possibilité de prendre en charge des extensions : des modules logiciels qui ajoutent des fonctionnalités à PostgreSQL (2011). Les extensions ont permis à encore plus de développeurs d'ajouter des fonctionnalités à PostgreSQL de manière indépendante, rapide et avec un minimum de coordination.

Grâce aux extensions, PostgreSQL a commencé à devenir plus qu'une simple base de données relationnelle. Grâce à PostGIS, c'est devenu une excellente base de données géospatiale ; grâce à TimescaleDB, c'est devenu une excellente base de données de séries chronologiques ; hstore, un magasin clé-valeur ; AGE, une base de données de graphiques ; pgvector, une base de données vectorielles. PostgreSQL est devenu une plateforme.

Désormais, les développeurs peuvent utiliser PostgreSQL pour sa fiabilité, son évolutivité (en remplacement des bases de données non relationnelles), son analyse de données (en remplacement des entrepôts de données), et bien plus encore.

Et le Big Data ?

À ce stade, le lecteur intelligent devrait se demander : « Qu'en est-il du Big Data ? C'est une bonne question. Historiquement, les « big data » (par exemple, des centaines de téraoctets, voire des pétaoctets) – et les requêtes d'analyse associées – ne conviennent pas à une base de données telle que PostgreSQL, qui ne s'adapte pas elle-même horizontalement.

Cela aussi est en train de changer. En novembre dernier, nous avons lancé « stockage hiérarchisé », qui hiérarchise automatiquement vos données entre le stockage sur disque et le stockage objet (S3), créant ainsi la possibilité d'avoir une table infinie.

Ainsi, même si le « Big Data » a toujours été un point faible pour PostgreSQL, bientôt aucune charge de travail ne sera trop importante.

PostgreSQL est la réponse. PostgreSQL nous permet de nous libérer et de construire l'avenir.

Libérez-vous, construisez l'avenir, adoptez PostgreSQL

Au lieu de nous contenter de plusieurs systèmes de bases de données différents, chacun avec ses propres particularités et langages de requête, nous pouvons compter sur la base de données la plus polyvalente et, peut-être, la plus fiable au monde : PostgreSQL. Nous pouvons consacrer moins de temps à la plomberie et plus de temps à construire l’avenir.

Et PostgreSQL ne cesse de s'améliorer. La communauté PostgreSQL continue d'améliorer le noyau. De nombreuses autres entreprises contribuent aujourd'hui à PostgreSQL, y compris les hyperscalers.

L'écosystème PostgreSQL actuel ( Source )

Il existe également des entreprises indépendantes plus innovantes qui s'appuient sur le noyau pour améliorer l'expérience PostgreSQL : Supabase (2020) fait de PostgreSQL une alternative viable à Firebase pour les développeurs Web et mobiles ; Néon (2021) et Xata (2022) font tous deux évoluer PostgreSQL vers zéro pour les charges de travail intermittentes sans serveur ; Tembo (2022) fournit des piles prêtes à l'emploi pour divers cas d'utilisation ; Nil (2023) facilite PostgreSQL pour les applications SaaS ; et beaucoup plus.

Et bien sûr, il y a nous, Échelle de temps (2017).

Échelle de temps démarrée sous le nom « PostgreSQL pour les séries temporelles »

L'histoire de Timescale vous semblera probablement un peu familière : nous résolvions certains problèmes difficiles de données de capteurs pour les clients IoT, et nous étions noyés sous les données. Pour suivre le rythme, nous avons construit une pile complexe comprenant au moins deux systèmes de bases de données différents (dont l'un était une base de données de séries chronologiques).

Un jour, nous avons atteint notre point de rupture. Dans notre interface utilisateur, nous voulions filtrer les appareils à la fois par type d'appareil et par temps de disponibilité. Cela aurait dû être une simple jointure SQL. Mais comme nous utilisions deux bases de données différentes, cela nécessitait plutôt d'écrire du code de colle dans notre application entre nos deux bases de données. Il nous faudrait des semaines et tout un sprint technique pour réaliser le changement.

Ensuite, l'un de nos ingénieurs a eu une idée folle : pourquoi ne pas simplement créer une base de données de séries chronologiques directement dans PostgreSQL ? De cette façon, nous n’aurions qu’une seule base de données pour toutes nos données et serions libres de livrer les logiciels plus rapidement. Ensuite, nous l’avons construit et cela nous a rendu la vie tellement plus facile. Ensuite, nous en avons parlé à nos amis et ils ont voulu l'essayer. Et nous avons réalisé que c’était quelque chose que nous devions partager avec le monde.

Nous avons donc open source notre extension de séries chronologiques, TimescaleDB, et l'a annoncé au monde le 4 avril 2017. À l’époque, les startups basées sur PostgreSQL étaient assez rares. Nous étions parmi les premiers.

Au cours des sept années qui ont suivi, nous avons massivement investi à la fois dans l'extension et dans notre service cloud PostgreSQL, offrant une expérience de développement PostgreSQL de mieux en mieux pour les séries temporelles et les analyses : requêtes 350 fois plus rapides, insertions 44 % plus élevées via des hypertables (auto- tables de partitionnement); des temps de réponse en millisecondes pour les requêtes courantes via des agrégats continus (vues matérialisées en temps réel) ; Plus de 90 % d'économies sur les coûts de stockage grâce à la compression en colonnes native ; stockage d'objets infini et peu coûteux via un stockage hiérarchisé ; et plus.

Échelle de temps étendue au-delà des séries chronologiques

C'est là que nous avons commencé, dans le domaine des données chronologiques, et c'est aussi ce pour quoi nous sommes le plus connus.

Mais l’année dernière, nous avons commencé à nous développer.

Vecteur d'échelle de temps

Nous avons lancé Vecteur d'échelle de temps (« PostgreSQL++ for AI applications »), ce qui fait de PostgreSQL une base de données vectorielles encore meilleure. Timescale Vector s'adapte à plus de 100 millions de vecteurs, en s'appuyant sur pgvector avec des performances encore meilleures. Des entreprises et des équipes innovantes utilisent déjà Timescale Vector en production à grande échelle, notamment OuvertSauced , une plateforme d'informations sur les événements GitHub, avec plus de 100 millions de vecteurs ; VieRallye , une plateforme de prédiction de la viralité sociale, avec plus de 100 millions de vecteurs ; et Lecteur de marché , une plateforme d'informations financières, avec plus de 30 millions de vecteurs.

PopSQL

Récemment, nous avons également acquis PopSQL pour créer et offrir la meilleure interface utilisateur PostgreSQL. PopSQL est l'éditeur SQL pour la collaboration en équipe, avec saisie semi-automatique, exploration de schéma, gestion des versions et visualisation. Des centaines de milliers de développeurs et d'analystes de données ont utilisé PopSQL pour travailler avec leurs données, que ce soit sur PostgreSQL, Timescale ou d'autres sources de données comme Redshift, Snowflake, BigQuery, MySQL, SQL Server, etc.

PopSQL est l'éditeur SQL pour la collaboration en équipe

Connaissances

Nous avons également lancé « Insights », le plus grand effort de dogfooding que nous ayons jamais entrepris , qui suit chaque requête de base de données pour aider les développeurs à surveiller et à optimiser les performances de la base de données. Insights surmonte plusieurs limitations de pg_stat_statements (l'extension officielle pour voir les statistiques de votre base de données). L'ampleur a été énorme et témoigne de la capacité de notre produit (et de notre équipe) : plus d'un billion de requêtes normalisées (c'est-à-dire des requêtes dont les valeurs de paramètres ont été remplacées par des espaces réservés) ont été collectées, stockées et analysées, avec plus de 10 milliards de nouvelles requêtes. requêtes ingérées chaque jour.

L'échelle de temps est désormais « PostgreSQL rendu puissant »

Aujourd'hui, Timescale est devenu PostgreSQL puissant, à n'importe quelle échelle. Nous résolvons désormais des problèmes complexes liés aux données, ce que personne d'autre ne fait, non seulement dans les séries chronologiques, mais aussi dans les domaines de l'IA, de l'énergie, des jeux, des données des machines, des véhicules électriques, de l'espace, de la finance, de la vidéo, de l'audio, du Web3 et bien plus encore.

Nous pensons que les développeurs devraient utiliser PostgreSQL pour tout, et nous améliorons PostgreSQL pour qu'ils le puissent.

Les clients utilisent Timescale non seulement pour leurs données de séries chronologiques, mais également pour leurs données vectorielles et leurs données relationnelles générales. Ils utilisent Timescale pour pouvoir utiliser PostgreSQL pour tout. Vous pouvez également: commencez ici gratuitement .

Coda : Yoda ?

Notre réalité humaine, à la fois physique et virtuelle, hors ligne et en ligne, est remplie de données. Comme pourrait le dire Yoda, les données nous entourent, nous lient. Cette réalité est de plus en plus régie par des logiciels, écrits par des développeurs de logiciels, par nous.

Cela vaut la peine d’apprécier à quel point cela est remarquable. Il n'y a pas si longtemps, en 2002, alors que j'étais étudiant diplômé du MIT, le monde avait perdu confiance dans les logiciels. Nous nous remettions de l’effondrement de la bulle Internet. Les principales publications économiques ont proclamé que « Cela n'a pas d'importance .» À l’époque, il était plus facile pour un développeur de logiciels d’obtenir un bon emploi dans la finance que dans la technologie – ce que faisaient beaucoup de mes camarades de classe au MIT, moi y compris.

Mais aujourd’hui, surtout dans ce monde d’IA générative, c’est nous qui façonnons l’avenir. Nous sommes les futurs bâtisseurs. Nous devrions nous pincer.

Tout devient ordinateur. Cela a été largement une bonne chose : nos voitures sont plus sûres, nos maisons sont plus confortables et nos usines et nos fermes sont plus productives. Nous avons un accès instantané à plus d’informations que jamais. Nous sommes plus connectés les uns aux autres. Parfois, cela nous a rendus en meilleure santé et plus heureux.

Mais pas toujours. Comme la force, l’informatique a à la fois un côté clair et un côté obscur. Il est de plus en plus évident que les téléphones mobiles et les médias sociaux contribuent directement à une épidémie mondiale de maladie mentale chez les adolescents . Nous sommes toujours aux prises avec les implications de IA et biologie synthétique . Alors que nous acceptons notre plus grand pouvoir, nous devons reconnaître que cela s’accompagne de responsabilités.

Nous sommes devenus les gardiens de deux ressources précieuses qui affectent la façon dont l’avenir se construit : notre temps et notre énergie.

Nous pouvons soit choisir de consacrer ces ressources à la gestion de la plomberie, soit adopter PostgreSQL for Everything et construire le bon avenir.

Je pense que vous savez où nous en sommes.

Merci d'avoir lu. #Postgres4Life

( Source )

Cet article a été écrit par Ajay Kulkarni .