Einer der größten Trends in der heutigen Softwareentwicklung ist die Entwicklung von PostgreSQL zum De-facto-Datenbankstandard. Es gibt einige Blogbeiträge darüber, wie man PostgreSQL für alles verwenden kann, aber noch keinen, der erklärt, warum das so ist (und noch wichtiger, warum das wichtig ist).
Bis jetzt!
01 PostgreSQL wird zum De-facto-Datenbankstandard
02 Alles wird zum Computer
03 Die Rückkehr von PostgreSQL
04 Machen Sie sich frei, gestalten Sie die Zukunft, nutzen Sie PostgreSQL
05 Timescale begann als „PostgreSQL für Zeitreihen“
06 Zeitskala über Zeitreihen hinaus erweitert
07 Timescale ist jetzt „PostgreSQL made Powerful“
08 Coda: Yoda?
In den letzten Monaten ist „PostgreSQL für alles“ zu einem immer lauter werdenden Schlachtruf unter Entwicklern geworden:
„PostgreSQL ist nicht nur eine einfache relationale Datenbank; es ist ein Datenmanagement-Framework mit dem Potenzial, den gesamten Datenbankbereich zu erfassen. Der Trend, „Postgres für alles zu verwenden“, ist nicht mehr auf einige Eliteteams beschränkt, sondern entwickelt sich zu einer gängigen Best Practice.“
(
„Eine Möglichkeit, Ihren Stack zu vereinfachen und die beweglichen Teile zu reduzieren, die Entwicklung zu beschleunigen, das Risiko zu senken und mehr Funktionen in Ihrem Startup bereitzustellen, besteht darin, „Postgres für alles zu verwenden“. Postgres kann – bis zu Millionen von Benutzern – viele Backend-Technologien ersetzen, darunter Kafka, RabbitMQ, Mongo und Redis.“
(
(
„Als ich zum ersten Mal von Postgres hörte (zu einer Zeit, als MySQL absolut dominierte), wurde es mir als „die Datenbank, die von diesen Mathe-Freaks erstellt wurde“ beschrieben, und dann fiel mir ein: Ja, das sind genau die Leute, die Sie für Ihre Datenbank haben möchten.“
(
Quelle )
„Es hat ein bemerkenswertes Comeback erlebt. Was gibt es sonst noch, jetzt, wo NoSQL tot ist und Oracle MySQL besitzt?“
( Quelle )
„Postgres ist nicht nur eine relationale Datenbank. Es ist eine Lebenseinstellung.“
( Quelle )
Dank seiner grundsoliden Grundlage und seiner Vielseitigkeit durch native Funktionen und Erweiterungen können Entwickler PostgreSQL jetzt für alles verwenden und komplexe, instabile Datenarchitekturen durch unkomplizierte Einfachheit ersetzen:
Dies könnte erklären, warum PostgreSQL im letzten Jahr MySQL den ersten Platz in der Rangliste der beliebtesten Datenbanken unter professionellen Entwicklern (60.369 Befragte) abgenommen hat:
In welchen Datenbankumgebungen haben Sie im letzten Jahr umfangreiche Entwicklungsarbeit geleistet und in welchen möchten Sie im nächsten Jahr arbeiten? Mehr als 49 % der Befragten antworteten mit PostgreSQL. (
Diese Ergebnisse stammen aus der Stack Overflow-Entwicklerumfrage 2023. Wenn Sie einen Blick auf die Zeit werfen, können Sie den stetigen Anstieg der PostgreSQL-Einführung in den letzten Jahren erkennen:
Während PostgreSQL zwischen 2020 und 2022 die zweitbeliebteste Datenbank der Teilnehmer der Stack Overflow-Entwicklerumfrage war, hat ihre Nutzung kontinuierlich zugenommen. Quelle:
Dies ist nicht nur ein Trend unter kleinen Startups und Hobbyisten. Tatsächlich nimmt die Verwendung von PostgreSQL in Organisationen aller Größen zu:
Der Prozentsatz der PostgreSQL-Nutzung nach Unternehmensgröße. (
Für uns bei Timescale ist dieser Trend nichts Neues. Wir glauben seit fast einem Jahrzehnt an PostgreSQL. Deshalb haben wir unser Geschäft auf PostgreSQL aufgebaut, deshalb sind wir einer der
Es gibt zwar einige Blogbeiträge dazu, wie man PostgreSQL für alles verwenden kann, aber noch keinen dazu, warum das passiert (und, noch wichtiger, warum das wichtig ist).
Bis jetzt.
Doch um die Gründe dafür zu verstehen, müssen wir einen noch grundlegenderen Trend verstehen und wissen, wie dieser Trend die fundamentale Natur der menschlichen Realität verändert.
Alles – unsere Autos, unsere Häuser, unsere Städte, unsere Bauernhöfe, unsere Fabriken, unsere Währungen, unsere Dinge – wird zu einem Computer. Auch wir werden digital. Jedes Jahr digitalisieren wir mehr von unserer eigenen Identität und unseren Handlungen: wie wir Dinge kaufen, wie wir uns unterhalten, wie wir Kunst sammeln, wie wir Antworten auf unsere Fragen finden, wie wir kommunizieren und uns vernetzen, wie wir ausdrücken, wer wir sind.
Vor 22 Jahren schien diese Idee des „ubiquitous computing“ kühn. Damals war ich Doktorand am MIT AI Lab und arbeitete an meinem
Seitdem hat sich viel geändert. Computer sind heute allgegenwärtig: auf unseren Schreibtischen, in unseren Taschen, in unseren Sachen und in unserer „Cloud“. Das haben wir vorausgesagt.
Die Zweitrundeneffekte dieser Veränderungen waren jedoch nicht das, was die meisten von uns erwartet hatten:
Ubiquitous Computing hat zu allgegenwärtigen Daten geführt . Mit jedem neuen Computergerät sammeln wir mehr Informationen über unsere Realität: menschliche Daten, Maschinendaten, Geschäftsdaten, Umweltdaten und synthetische Daten. Diese Daten überfluten unsere Welt.
Die Datenflut hat zu einer kambrischen Explosion von Datenbanken geführt . All diese neuen Datenquellen erforderten neue Speicherorte. Vor zwanzig Jahren gab es vielleicht fünf brauchbare Datenbankoptionen. Heute sind es mehrere Hundert, die meisten davon sind auf bestimmte Anwendungsfälle oder Daten spezialisiert, und jeden Monat kommen neue hinzu.
Mehr Daten und mehr Datenbanken haben zu einer höheren Softwarekomplexität geführt . Die Auswahl der richtigen Datenbank für Ihre Software-Workload ist nicht mehr einfach. Stattdessen sind Entwickler gezwungen, komplexe Architekturen zusammenzuschustern, die Folgendes umfassen können: eine relationale Datenbank (aufgrund ihrer Zuverlässigkeit), eine nicht relationale Datenbank (aufgrund ihrer Skalierbarkeit), ein Data Warehouse (aufgrund seiner Fähigkeit, Analysen durchzuführen) und einen Objektspeicher (aufgrund seiner Fähigkeit, alte Daten kostengünstig zu archivieren). Diese Architektur kann sogar noch spezialisiertere Komponenten enthalten, wie etwa eine Zeitreihen- oder Vektordatenbank.
Mehr Komplexität bedeutet weniger Zeit für die Entwicklung. Komplexe Architekturen sind anfälliger, erfordern eine komplexere Anwendungslogik, bieten weniger Zeit für die Entwicklung und verlangsamen die Entwicklung. Komplexität ist kein Vorteil, sondern ein echter Kostenfaktor.
Da Computer allgegenwärtiger geworden sind, ist auch unsere Realität stärker mit Computern verflochten. Wir haben Computer in unsere Welt gebracht und uns selbst in ihre Welt. Wir sind nicht mehr nur unsere Offline-Identitäten, sondern ein Hybrid dessen, was wir offline und online tun.
Softwareentwickler sind die Vorhut der Menschheit in dieser neuen Realität. Wir sind diejenigen, die die Software entwickeln, die diese neue Realität formt.
Doch Entwickler werden heutzutage mit Daten überflutet und ertrinken in der Komplexität der Datenbank.
Dies bedeutet, dass Entwickler – anstatt die Zukunft zu gestalten – immer mehr Zeit mit der Verwaltung der technischen Infrastruktur verbringen.
Wie sind wir hierher gekommen?
Ubiquitous Computing hat zu allgegenwärtigen Daten geführt. Dies geschah nicht über Nacht, sondern in kaskadierenden Wellen über mehrere Jahrzehnte hinweg:
Mit jeder Welle wurden Computer kleiner, leistungsfähiger und allgegenwärtiger. Jede Welle baute zudem auf der vorherigen auf: Personalcomputer sind kleinere Großrechner; das Internet ist ein Netzwerk verbundener Computer; Smartphones sind noch kleinere Computer, die mit dem Internet verbunden sind; Cloud Computing demokratisierte den Zugang zu Computerressourcen; das Internet der Dinge besteht aus Smartphone-Komponenten, die als Teil anderer physischer Dinge rekonstruiert wurden, die mit der Cloud verbunden sind.
Doch in den letzten beiden Jahrzehnten gab es nicht nur in der physischen, sondern auch in der digitalen Welt Fortschritte in der Computertechnik, was unsere hybride Realität widerspiegelt:
Mit jeder neuen Computerwelle erhalten wir neue Informationsquellen über unsere hybride Realität: menschliche digitale Abgase, Maschinendaten, Geschäftsdaten und synthetische Daten. Zukünftige Wellen werden noch mehr Daten erzeugen. All diese Daten treiben neue Wellen an, von denen die jüngste die generative KI ist, die wiederum unsere Realität weiter prägt.
Computerwellen sind nicht isoliert, sondern kaskadenartig wie Dominosteine. Was als Datenrinnen begann, wurde bald zu einer Datenflut. Und die Datenflut führte dann zur Schaffung von immer mehr Datenbanken.
Für all diese neuen Datenquellen sind neue Speicherorte – oder Datenbanken – erforderlich.
Mainframes begannen mit dem
Die kollaborative Kraft des Internets ermöglichte die Entstehung von Open-Source-Software, darunter auch die ersten Open-Source-Datenbanken:
Das Internet erzeugte außerdem enorme Datenmengen, was zur Entwicklung der ersten nicht-relationalen Datenbanken bzw. NoSQL-Datenbanken führte:
Um das Jahr 2010 herum erreichten wir einen Wendepunkt. Bis dahin stützten sich Softwareanwendungen hauptsächlich auf eine einzige Datenbank – z. B. Oracle, MySQL, PostgreSQL – und die Wahl war relativ einfach.
Doch „Big Data“ wurde immer größer: Das Internet der Dinge führte zum Anstieg von Maschinendaten; die Smartphone-Nutzung begann dank iPhone und Android exponentiell zu wachsen, was zu noch mehr digitalem Menschenmüll führte; Cloud Computing demokratisierte den Zugang zu Rechenleistung und Speicher und verstärkte diese Trends. Generative KI hat dieses Problem in jüngster Zeit durch die Erstellung von Vektordaten noch verschärft.
Mit der zunehmenden Menge der erfassten Daten entstanden spezialisierte Datenbanken:
Vor zwanzig Jahren gab es vielleicht fünf brauchbare Datenbankoptionen. Heute gibt es
Angesichts dieser Flut und spezialisierter Datenbanken mit einer Vielzahl von Kompromissen blieb den Entwicklern keine andere Wahl, als komplexe Architekturen zusammenzuschustern.
Diese Architekturen umfassen typischerweise eine relationale Datenbank (für Zuverlässigkeit), eine nicht-relationale Datenbank (für Skalierbarkeit), ein Data Warehouse (für Datenanalyse), einen Objektspeicher (für kostengünstige Archivierung) und noch spezialisiertere Komponenten wie eine Zeitreihen- oder Vektordatenbank für diese Anwendungsfälle.
Mehr Komplexität bedeutet jedoch weniger Zeit für die Entwicklung. Komplexe Architekturen sind anfälliger, erfordern eine komplexere Anwendungslogik, bieten weniger Zeit für die Entwicklung und verlangsamen die Entwicklung.
Dies bedeutet, dass Softwareentwickler, anstatt die Zukunft zu gestalten, viel zu viel Zeit mit der Wartung der Infrastruktur verbringen. Dies ist der Stand der Dinge heute.
Es gibt einen besseren Weg.
Hier nimmt unsere Geschichte eine neue Wendung. Unser Held ist keine glänzende neue Datenbank, sondern ein alter Hase mit einem Namen, den nur eine Mutter, die Kernentwicklerin ist, lieben könnte: PostgreSQL.
Anfangs war PostgreSQL mit großem Abstand die Nummer zwei hinter MySQL. MySQL war einfacher zu verwenden, hatte ein Unternehmen dahinter und einen Namen, den jeder leicht aussprechen konnte. Doch dann wurde MySQL von Sun Microsystems (2008) übernommen, das wiederum von Oracle (2009) übernommen wurde. Und Softwareentwickler, die MySQL als kostenlosen Retter aus der teuren Oracle-Diktatur betrachteten, begannen, ihre Verwendung zu überdenken.
Zur gleichen Zeit verbesserte eine verteilte Entwickler-Community, gesponsert von einer Handvoll kleiner, unabhängiger Unternehmen, PostgreSQL langsam immer weiter. Sie fügten in aller Stille leistungsstarke Funktionen hinzu, wie Volltextsuche (2008), Fensterfunktionen (2009) und JSON-Unterstützung (2012). Sie machten die Datenbank auch solider, durch Funktionen wie Streaming-Replikation, Hot-Standby, In-Place-Upgrade (2010), logische Replikation (2017) und durch sorgfältiges Beheben von Fehlern und Glätten von Ecken und Kanten.
Eine der wirkungsvollsten Funktionen, die PostgreSQL in dieser Zeit hinzugefügt wurden, war die Fähigkeit zur Unterstützung von Erweiterungen: Softwaremodule, die die Funktionalität von PostgreSQL erweitern (2011).
Dank Erweiterungen wurde PostgreSQL mehr als nur eine großartige relationale Datenbank. Dank PostGIS wurde es eine großartige georäumliche Datenbank; dank TimescaleDB wurde es eine großartige Zeitreihendatenbank; hstore, ein Schlüssel-Wert-Speicher; AGE, eine Graphdatenbank; pgvector, eine Vektordatenbank. PostgreSQL wurde zu einer Plattform.
Jetzt können Entwickler PostgreSQL aufgrund seiner Zuverlässigkeit, Skalierbarkeit (Ersatz nicht-relationaler Datenbanken), Datenanalyse (Ersatz von Data Warehouses) und mehr nutzen.
An dieser Stelle sollte der kluge Leser fragen: „Was ist mit Big Data?“ Das ist eine berechtigte Frage. In der Vergangenheit waren „Big Data“ (z. B. Hunderte von Terabyte oder sogar Petabyte) – und die damit verbundenen Analyseabfragen – für eine Datenbank wie PostgreSQL, die nicht von selbst horizontal skaliert, nicht geeignet.
Auch das ändert sich. Im vergangenen November haben wir „
Während „Big Data“ in der Vergangenheit eine Schwachstelle für PostgreSQL war, wird ihm bald keine Arbeitslast mehr zu groß sein.
PostgreSQL ist die Antwort. Mit PostgreSQL können wir uns befreien und die Zukunft gestalten.
Anstatt uns mit mehreren verschiedenen Datenbanksystemen herumzuschlagen, jedes mit seinen eigenen Eigenheiten und Abfragesprachen, können wir uns auf die vielseitigste und wahrscheinlich zuverlässigste Datenbank der Welt verlassen: PostgreSQL. Wir können weniger Zeit mit der technischen Umsetzung verbringen und mehr Zeit darauf verwenden, die Zukunft zu gestalten.
Und PostgreSQL wird immer besser. Die PostgreSQL-Community verbessert den Kern ständig. Heute tragen viele weitere Unternehmen zu PostgreSQL bei, darunter auch die Hyperscaler.
Das heutige PostgreSQL-Ökosystem (
Darüber hinaus gibt es innovativere, unabhängige Unternehmen, die rund um den Kern daran arbeiten, das PostgreSQL-Erlebnis zu verbessern:
Und natürlich gibt es uns,
Die Geschichte von Timescale kommt Ihnen wahrscheinlich bekannt vor: Wir haben einige schwierige Sensordatenprobleme für IoT-Kunden gelöst und sind in Daten ertrunken. Um mithalten zu können, haben wir einen komplexen Stack erstellt, der mindestens zwei verschiedene Datenbanksysteme umfasste (eines davon war eine Zeitreihendatenbank).
Eines Tages erreichten wir unseren Bruchpunkt. In unserer Benutzeroberfläche wollten wir Geräte sowohl nach Gerätetyp als auch nach Betriebszeit filtern. Dies hätte ein einfacher SQL-Join sein sollen. Da wir jedoch zwei verschiedene Datenbanken verwendeten, mussten wir stattdessen Verbindungscode in unsere Anwendung zwischen unseren beiden Datenbanken schreiben. Wir hätten Wochen und einen ganzen Entwicklungssprint gebraucht, um die Änderung vorzunehmen.
Dann hatte einer unserer Ingenieure eine verrückte Idee: Warum bauen wir nicht einfach eine Zeitreihendatenbank direkt in PostgreSQL? Auf diese Weise hätten wir nur eine Datenbank für alle unsere Daten und könnten Software schneller ausliefern. Dann haben wir sie gebaut und sie hat unser Leben so viel einfacher gemacht. Dann haben wir unseren Freunden davon erzählt und sie wollten es ausprobieren. Und uns wurde klar, dass dies etwas war, das wir mit der Welt teilen mussten.
Deshalb haben wir unsere Zeitreihenerweiterung TimescaleDB als Open Source freigegeben und
In den sieben Jahren seitdem haben wir stark in die Erweiterung und in unseren PostgreSQL-Cloud-Dienst investiert und bieten eine immer bessere PostgreSQL-Entwicklererfahrung für Zeitreihen und Analysen: 350-mal schnellere Abfragen, 44 % höhere Einfügungen über Hypertabellen (automatisch partitionierte Tabellen); Antwortzeiten im Millisekundenbereich für allgemeine Abfragen über kontinuierliche Aggregate (materialisierte Ansichten in Echtzeit); über 90 % Speicherkosteneinsparungen durch native Spaltenkomprimierung; unbegrenzter, kostengünstiger Objektspeicher über mehrstufigen Speicher und mehr.
Hier haben wir angefangen, im Bereich Zeitreihendaten, und das ist auch das, wofür wir am bekanntesten sind.
Aber letztes Jahr haben wir begonnen zu expandieren.
Wir starteten
Kürzlich,
PopSQL ist der SQL-Editor für die Teamzusammenarbeit
Außerdem haben wir „
Heute ist Timescale leistungsstarkes PostgreSQL – in jedem Maßstab. Wir lösen jetzt harte Datenprobleme – die sonst niemand löst – nicht nur in Zeitreihen, sondern auch in den Bereichen KI, Energie, Gaming, Maschinendaten, Elektrofahrzeuge, Weltraum, Finanzen, Video, Audio, Web3 und vielem mehr.
Wir sind der Meinung, dass Entwickler PostgreSQL für alles verwenden sollten, und wir verbessern PostgreSQL, damit sie dies tun können.
Kunden verwenden Timescale nicht nur für ihre Zeitreihendaten, sondern auch für ihre Vektordaten und allgemeinen relationalen Daten. Sie verwenden Timescale, damit sie PostgreSQL für alles verwenden können. Sie können das auch:
Unsere menschliche Realität, sowohl physisch als auch virtuell, offline und online, ist voller Daten. Wie Yoda sagen würde: Daten umgeben uns, binden uns. Diese Realität wird zunehmend von Software bestimmt, die von Softwareentwicklern, von uns, geschrieben wird.
Es lohnt sich, zu erkennen, wie bemerkenswert das ist. Vor nicht allzu langer Zeit, im Jahr 2002, als ich MIT-Student war, hatte die Welt das Vertrauen in Software verloren. Wir erholten uns gerade vom Platzen der Dotcom-Blase. Führende Wirtschaftspublikationen verkündeten: „
Doch heute, gerade in dieser Welt der generativen KI, sind wir diejenigen, die die Zukunft gestalten. Wir sind die Erbauer der Zukunft. Wir sollten uns kneifen.
Alles wird zum Computer. Das hat sich größtenteils als positiv erwiesen: Unsere Autos sind sicherer, unsere Häuser komfortabler und unsere Fabriken und Bauernhöfe produktiver. Wir haben sofortigen Zugriff auf mehr Informationen als je zuvor. Wir sind besser miteinander vernetzt. Manchmal hat uns das gesünder und glücklicher gemacht.
Aber nicht immer. Wie die Macht hat auch die Computertechnik eine helle und eine dunkle Seite. Es gibt immer mehr Hinweise darauf, dass Mobiltelefone und soziale Medien direkt zu einer
Wir sind zu Verwaltern zweier wertvoller Ressourcen geworden, die Einfluss darauf haben, wie die Zukunft gestaltet wird: unserer Zeit und unserer Energie.
Wir können diese Ressourcen entweder für die Verwaltung der technischen Infrastruktur aufwenden oder PostgreSQL für alles nutzen und die richtige Zukunft aufbauen.
Ich denke, Sie wissen, wo wir stehen.
Danke fürs Lesen. #Postgres4Life
(
Dieser Beitrag wurde von Ajay Kulkarni geschrieben.