PostgreSQL reicht aus

• Eine Seite, die Links dazu sammelt, wie PostgreSQL in den verschiedensten Bereichen eingesetzt werden kann
  • Hintergrundjobs, Message Queues, GIS, Audit-Logs, Zugriffskontrolle, Berechtigungsverwaltung, Suche, Zeitreihen, Graphdaten, externe Daten, HTTP, API, Events/Replikation/CDC, Unit-Tests, Migrationen, Dashboards/UI, Datenvisualisierung, HTML und Anwendungen, LSP (Language Server)

PostgreSQL is Enough

• PostgreSQL überall einsetzen
• Simplify: Vereinfachen durch das Verlagern von Code in Datenbankfunktionen

Hintergrundjobs

• Mit pg_cron lassen sich in PostgreSQL geplante Aufgaben verwalten.

Message Queue

• Bietet Informationen dazu, wie man PostgreSQL als Message-Queue-Technologie auswählt.
• pgmq ist ein auf PostgreSQL basierendes Message-Queue-System.

GIS/Karten

• PostGIS erweitert PostgreSQL um Geodatenbank-Funktionen.

Audit-Logs

• pgMemento und pgaudit verfolgen Änderungen in PostgreSQL und verwalten Audit-Logs.

Zugriffskontrolle

• acl wird verwendet, um Zugriffssteuerungslisten in PostgreSQL zu verwalten.

Authentifizierung

• Das PostgreSQL-Modul pgcrypto und pgjwt übernehmen die Authentifizierung innerhalb der Datenbank.

Suche

• Nützliche Links zu den Full-Text-Suchfunktionen von PostgreSQL.
• paradedb, pg_embedding, pgvector verbessern die Suchfunktionen in PostgreSQL.

Zeitreihendaten

• timescaledb erweitert PostgreSQL für die Verwaltung von Zeitreihendaten.

Graphdaten

• Apache AGE erweitert PostgreSQL um Graphdatenbank-Funktionen.

Externe Daten

• wrappers integriert externe Datenquellen in PostgreSQL.

HTTP

• pgsql-http und pg_net verarbeiten HTTP-Anfragen in PostgreSQL.

API

• PostgREST, graphql-engine, postgraphile, pg_graphql bauen API-Server auf Basis von PostgreSQL.

Events, Replikation, CDC

• Der PostgreSQL-Befehl NOTIFY sowie walex, peerdb, debezium, pglogical verfolgen Datenänderungen und bieten Replikationsfunktionen.

Unit-Tests

• pgtap ist ein Tool für Unit-Tests von PostgreSQL-Datenbanken.

Migrationen

• postgresql-migrations und bytebase verwalten Migrationen von PostgreSQL-Datenbanken.

Dashboards / UI

• Baserow, NocoDB, AppSmith bieten Benutzeroberflächen und Dashboards.

Datenvisualisierung

• Evidence und Metabase sind Tools zur Datenvisualisierung.

HTML und Anwendungen

• SQLpage, Omnigres, pg_render, plmustache integrieren PostgreSQL-Daten in Webanwendungen.

Sprachserver

• postgres_lsp bietet Unterstützung für das Language Server Protocol für PostgreSQL.

Was fehlt?

• Bitte teilt fehlende Inhalte in den Kommentaren

Meinung von GN⁺

• PostgreSQL zeigt mit seinen vielfältigen Erweiterungen und Tools, dass es weit über ein einfaches Datenbankmanagementsystem hinausgeht und eine vielseitige Plattform ist.
• Dieser Beitrag bietet Entwicklern eine nützliche Ressource, indem er Wege aufzeigt, wie sich mit PostgreSQL unterschiedlichste Anforderungen von Anwendungen erfüllen lassen.
• Besonders hervorgehoben wird das Potenzial, die Systemarchitektur zu vereinfachen und die Performance zu optimieren, indem Funktionen direkt innerhalb der Datenbank verarbeitet werden.

[eususu]

Davon nutze ich persönlich postgREST und bin damit zufrieden.

[GN⁺]

Hacker-News-Kommentare

• Erfahrungsbericht über den Versuch, den Anwendungs-Stack zu vereinfachen

  Ein Nutzer berichtet, dass er häufig versucht, den Anwendungs-Stack zu vereinfachen, mit zunehmender Komplexität der Anwendung aber erkennt, dass unterschiedliche Technologie-Stacks nötig sind. Wenn man versucht, alles auf eine einzelne Technologie wie Postgres zu konsolidieren, kann sich das unpraktisch anfühlen. Trotzdem kann es besser sein, bestehende Technologien zu erweitern, als eine neue Schicht hinzuzufügen. Zum Beispiel ist es viel einfacher, Postgres als Message Queue zu verwenden, als eine separate Message Queue zu betreiben. Postgres ist auch unter Datenbanken besonders erweiterbar, und es macht viel Spaß, darauf aufbauende Technik zu entwickeln.

• Meinung eines ParadeDB-Entwicklers zur Erweiterbarkeit von Postgres

  Als einer der Entwickler von ParadeDB stellt er über Postgres-Erweiterungen schnelle Such- und Analysefunktionen bereit. Bei kleinen Workloads wie in einem Startup ist es sinnvoll, möglichst lange innerhalb von Postgres zu arbeiten. Mit wachsender Größe kann Postgres jedoch nicht mehr alles allein lösen. Um verschiedene Workloads innerhalb von Postgres zu bewältigen, muss man Systeme nach konkreten Anforderungen trennen und unabhängige Skalierbarkeit sowie Resilienz sicherstellen. Ab diesem Punkt braucht man einen spezialisierten Lösungs-Stack für die jeweilige Anforderung. Es gibt zwar Bewegungen, Stack-Komponenten in einer Postgres-Version zu bauen, aber jede Lösung geht über Postgres hinaus, und er glaubt nicht, dass es für alle Stack-Komponenten eine Postgres-basierte Lösung geben wird.

• Meinung zur Entscheidung, neue Projekte mit sqlite zu starten

  Ein Nutzer hat entschieden, bei jedem neuen Projekt mit sqlite zu beginnen und erst dann zu wechseln, wenn es wirklich nötig ist. Wenn Postgres in 90 % der Fälle passt, dann passt sqlite in 80 % der Fälle, ist leicht zu starten und bietet gute Performance. Wenn vertikale Skalierung irgendwann nicht mehr ausreicht, wird man mit dem bereits Gebauten vermutlich zufrieden sein.

• Zweifel eines C++-Experten an der Notwendigkeit von Datenbanken

  Ein C++-Experte ohne große Datenbankerfahrung stellt die Notwendigkeit von Datenbanken infrage. Er kommt aus einer Branche, in der viele angepasste binäre Dateiformate genutzt werden, und hat den Eindruck, dass Datenbanken oberflächlich viele Probleme zu lösen scheinen, in der Praxis aber nicht. Beschränkungen bei Datentypen, Probleme bei Updates und Kompatibilitätsprobleme zwischen verschiedenen SQL-Engines lassen den Einsatz von Datenbanken wie eine schlechte Idee erscheinen. Er versteht die Vorteile bei der Interoperabilität großer Datenmengen, fragt aber ansonsten ernsthaft nach der Notwendigkeit von Datenbanken.

• Meinung zu PostgreSQL-Zusatzfunktionen

  Es wird darauf hingewiesen, dass die meisten Zusatzfunktionen bereits in MariaDB eingebaut sind, und ein Teil der Motivation hinter dem PostgreSQL-HTTP-Client wird zitiert. Auf die Idee, dass es gut wäre, Trigger schreiben zu können, die Webservices aufrufen, meint der Nutzer, solche Aufgaben würde er lieber jemand anderem überlassen.

• Probleme bei der Verbindung fortgeschrittener Funktionen mit Code-Management-Erfahrungen

  Er nutzt Postgres sehr intensiv, stößt aber jedes Mal, wenn er fortgeschrittene Funktionen verwendet, auf das Problem, diese mit all den guten Seiten des Codings zu verbinden: Versionsverwaltung, Code-Review, Typen, Tests und statische Analyse. Er stellt eine Frage zu Migrationen.

• Vorteile beim Prototyping neuer Funktionen mit dem bestehenden Stack

  Ein Nutzer teilt die Erfahrung, dass es besser ist, neue Funktionen zunächst als Prototyp mit dem bestehenden Stack zu bauen, statt etwas Neues einzuführen. Mit sorgfältiger Kuratierung kann ein früher Prototyp mit demselben Stack in Produktionscode überführt werden. Wenn das System jedoch an seine Grenzen stößt, kann man das Gefühl bekommen, Redis oder andere spezialisierte Werkzeuge zu brauchen. Wichtig ist, API-Wrapper zu schreiben, bei Bedarf nur die interne Implementierung zu ändern und Migrationen gründlich zu testen. Er erwähnt, dass Menschen oft überrascht sind, wie lange man Technologieentscheidungen aufschieben kann.

• Erfahrungsbericht eines Nutzers mit Postgres, Redis und S3

  Er nutzt die Kombination aus Postgres, Redis und S3, und diese Kombination hat sich für ihn bisher nie als Fehlentscheidung erwiesen. Manchmal möchte er Pub/Sub mit Postgres ausprobieren, tut es aber nicht, weil er für Caching und sidekiq ohnehin Redis braucht und Redis außerdem hervorragend ist.

• Grenzen von Postgres bei großangelegter Datenanalyse

  Ein Nutzer berichtet, dass er Postgres zwar sehr mag, es aber bei sehr großen Datenmengen nicht mehr ausreicht. Für Workloads vom Typ OLTP ist Postgres perfekt, aber wenn mehr OLAP-Unterstützung nötig ist, empfiehlt er StarRocks. Die Erfahrung, Daten für Analysen aus Postgres nach StarRocks zu übertragen, sei hervorragend, und StarRocks unterstütze auch direkte Abfragen auf dem Data Lake.

• Wunsch nach einer Komprimierungsfunktion für jsonb in Postgres

  Er verwendet sowohl Mongo als auch PG, findet PG aber deutlich einfacher und würde Mongo zur Vereinfachung gern aufgeben. Was er braucht, ist einfach eine komprimierte jsonb-Spalte, bei der nur Einfügen, Auswählen und Löschen möglich sind, ohne Updates oder Abfragen. Dabei wünscht er sich wie bei Mongo eine Kompressionsrate von 80 bis 90 % für wiederkehrende JSON-Schlüssel, ohne zusätzlichen Wartungsaufwand.