7 Datenbanken für 2025

xguru · 2024-12-09T09:56:01+09:00

Vorstellung von 7 DBs, die es wert sind, beachtet zu werden, um unterschiedliche Probleme zu lösen Dies ist keine Liste der „besten DBs“, sondern eine Sammlung von Tools, die neue und nützliche Perspektiven bieten Für 2025 wird empfohlen, jeweils eine Woche in jede dieser DBs zu investieren (7 DBs in 7 Weeks) 1. PostgreSQL: die Standarddatenbank PostgreSQL ist eine stabile Technologie, die standardmäßig eingesetzt wird Der Ausdruck „Just use Postgres“ ist ein weithin bekanntes Meme und steht sinnbildlich für Verlässlichkeit Es erfüllt ACID und bietet starke Funktionen einschließlich physischer und logischer Replikation Es ist eine stabile Datenbank mit breiter Unterstützung durch große Anbieter Der größte Reiz von PostgreSQL: Erweiterbarkeit Über Extensions lassen sich einzigartige Funktionen hinzufügen Beispiele wichtiger Extensions: AGE: Unterstützung für Graph-Datenstrukturen und die Cypher-Abfragesprache TimescaleDB: Unterstützung für die Arbeit mit Zeitreihendaten Hydra Columnar: bietet eine spaltenbasierte Storage Engine Extensions sind ein Kernelement, das PostgreSQL von anderen Datenbanken unterscheidet Nützlichkeit und Erweiterbarkeit von PostgreSQL Es verfügt über ein vielfältiges Ökosystem, und die Standardeinstellungen sind sinnvoll und benutzerfreundlich Auch Nicht-PostgreSQL-Dienste bieten Client-Kompatibilität über das Postgres-Wire-Protocol Es ist leichtgewichtig genug, um sogar in WebAssembly-(Wasm-)Umgebungen installiert zu werden Empfehlung, PostgreSQL zu lernen Es lohnt sich, Zeit zu investieren, um die Möglichkeiten und Grenzen von PostgreSQL zu verstehen Beispiel: die Komplexität von MVCC (Multi-Version Concurrency Control) verstehen Empfohlen werden die Entwicklung einer einfachen CRUD-Anwendung und das Schreiben von PostgreSQL-Extensions 2. SQLite: die Local-First-Datenbank SQLite ist eine „Local-First“-Datenbank, die eigenständig laufen kann Sie verlässt das Client-Server-Modell und läuft in derselben Umgebung wie die Anwendung Beispiel: WhatsApp und Signal nutzen SQLite auf dem Gerät, um Chat-Daten zu speichern Fortgeschrittene Einsatzszenarien für SQLite Kreative Nutzung weit über eine grundlegende ACID-konforme Datenbank hinaus Neue Tools und Extensions: Litestream: bietet Streaming-Backups für SQLite LiteFS: unterstützt verteilten Zugriff und ermöglicht flexiblere Topologien CR-SQLite: nutzt CRDTs (Conflict-free Replicated Data Types), um beim Zusammenführen von Change Sets die Notwendigkeit zur Konfliktauflösung zu beseitigen Neue Aufmerksamkeit für die Popularität von SQLite Dank Ruby on Rails 8.0 rückt es erneut in den Fokus 37signals: entwickelt Rails-Module auf Basis von SQLite (z. B. Solid Queue) Unterstützung von Rails für die Verwaltung mehrerer SQLite-Datenbanken (database.yml) Bluesky: verwendet für jeden Nutzer eine eigene SQLite-Datenbank als Personal Data Server Empfehlung, den Einsatz von SQLite zu lernen Mit SQLite lokale Architekturansätze experimentell erproben Versuchen, das bisherige PostgreSQL-basierte Client-Server-Modell durch SQLite zu ersetzen 3. DuckDB: die Datenbank, die alles abfragen kann DuckDB ist eine eingebettete Datenbank, die auf OLAP spezialisiert ist Wie SQLite arbeitet sie zusammen mit der Anwendung, fokussiert sich aber auf OLAP statt auf OLTP Ein System, das für Datenanalyse und abfragezentrierte Nutzung entworfen wurde Die „Query-Anything“-Eigenschaft von DuckDB Unterschiedliche Datenquellen können direkt per SQL abgefragt werden: gängige Dateiformate wie CSV, TSV und JSON Unterstützung für fortgeschrittene Dateiformate wie Parquet Diese Fähigkeit bietet Flexibilität, etwa bei der Analyse von Datenströmen von Bluesky Erweiterbarkeit und Ökosystem Auch DuckDB verfügt über Extensions, wenn auch nicht so reichhaltig wie Postgres (ein relativ junges Projekt) Es gibt viele Community-Erweiterungen; bemerkenswert ist gsheets (Anbindung an Google Sheets) Empfehlung, den Einsatz von DuckDB zu lernen Mit Python-Notebooks oder Evidence für Datenanalyse und -verarbeitung experimentieren Kombination mit SQLite: analytische Abfragen einer SQLite-Datenbank an DuckDB delegieren, um die Performance zu steigern 4. ClickHouse: die spaltenorientierte Datenbank ClickHouse ist eine Datenbank, die auf OLAP-Workloads spezialisiert ist Die Kombination aus PostgreSQL für OLTP und ClickHouse für OLAP ist ideal Sie verarbeitet groß angelegte analytische Workloads und unterstützt hohe Dateninsertraten durch horizontale Skalierung und Sharding Wichtige Merkmale von ClickHouse Hierarchical Storage wird unterstützt: „Hot Data“ und „Cold Data“ können getrennt gespeichert werden Beispiel: Die GitLab-Dokumentation behandelt Einsatzfälle dazu im Detail Verarbeitung großer Datensätze und Echtzeitanalyse: Geeignet für Datensätze, deren Größe für DuckDB schwer zu bewältigen ist Liefert starke Performance in Situationen, in denen Echtzeitanalyse erforderlich ist Komfort im Betrieb Dokumentation zu Deployment, Skalierung, Backups und anderen Betriebsaspekten ist systematisch und detailliert Beispiel: Es gibt sogar Dokumentation dazu, wie passende CPU-Einstellungen gewählt werden Empfehlung, ClickHouse zu lernen Mit großen analytischen Datensätzen experimentieren oder in DuckDB erstellte Analysen nach ClickHouse übertragen Mit der eingebetteten Version von ClickHouse, chDB, ist ein direkterer Vergleich mit SQLite möglich 5. FoundationDB: die geschichtete Datenbank FoundationDB ist ein einzigartiges System, das als „Fundament einer Datenbank“ dient Es wurde als Key-Value-Store entworfen, funktioniert aber eher als „Grundlage“ zum Aufbau von Datenbanken als als einfache Datenbank Es wird von großen Unternehmen wie Apple, Snowflake und Tigris Data eingesetzt Wichtige Merkmale und Grenzen Einschränkungen: Transaktionsdaten dürfen 10 MB nicht überschreiten Transaktionen dürfen nach dem ersten Lesen nicht länger als 5 Sekunden dauern Durch diese Beschränkungen sind vollständige ACID-Transaktionen auch in großen Umgebungen möglich Beispiel: Betrieb von Clustern mit mehr als 100 TiB Design und Tests von FoundationDB Es wurde für bestimmte Workloads optimiert entworfen Simulationstests belegen Stabilität und Skalierbarkeit: Antithesis und andere Datenbanken verwenden dieselbe Testmethodik Verwandte Referenzen: Dokumente von Tyler Neely und Phil Eaton FoundationDB als „geschichtete“ Datenbank Die Kopplung zwischen Storage Engine und Datenmodell ist locker: Die Storage Engine kann auf verschiedenen Schichten neu zugeordnet werden Beispiele: Record Layer, Document Layer (bereitgestellt von der FoundationDB-Organisation) Das von Tigris Data verfasste Beispiel für Layer-Design ist eine nützliche Referenz Empfehlung, FoundationDB zu lernen Tutorials durcharbeiten und das Potenzial erkunden, Systeme wie RocksDB zu ersetzen Design Recipes und zugehörige Papers lesen Über die Dokumente zu Anti-Features und Features die Einsatzgrenzen und die lösbaren Probleme verstehen 6. TigerBeetle: die kompromisslos genaue Datenbank TigerBeetle ist eine Single-Purpose-Datenbank, die auf Finanztransaktionen spezialisiert ist Anders als General-Purpose-Datenbanken ist sie auf einen bestimmten Zweck fokussiert, insbesondere auf Finanztransaktionen Sie ist als Open Source verfügbar und wurde mit dem Ziel hoher Zuverlässigkeit und Genauigkeit entworfen Designphilosophie für kompromisslose Genauigkeit Umsetzung von NASAs Power of Ten Rules und Protocol-Aware Recovery Verwendung von strict serialisability und Direct I/O, um Probleme im Zusammenhang mit dem Kernel-Page-Cache zu vermeiden Die Gründlichkeit zeigt sich in der Safety-Dokumentation und im besonderen Programmierstil „Tiger Style“ Innovativer Ansatz mit der Sprache Zig Zig ist eine noch vergleichsweise junge Sprache für Systemprogrammierung, passt aber ideal zu den Zielen von TigerBeetle Die Stärken von Zig werden genutzt, um Einfachheit und Performance zu maximieren Vorschläge zum Lernen und Nutzen von TigerBeetle In einer lokalen Deployment-Umgebung mit der Modellierung von Finanzkonten experimentieren: Installation und Nutzung anhand des Quick Start Die System-Architecture-Dokumentation heranziehen, um Kombinationsmöglichkeiten mit General-Purpose-Datenbanken zu untersuchen Beispiel: Integration zusammen mit PostgreSQL oder FoundationDB zur Erweiterung der Einsatzszenarien 7. CockroachDB: die globale Datenbank CockroachDB ist eine global verteilte Datenbank Sie ist mit dem PostgreSQL-Wire-Protocol kompatibel und unterstützt horizontale Skalierung sowie starke Konsistenz Das von Google Spanner inspirierte Design ermöglicht die Ausdehnung der Datenbank über mehrere Regionen hinweg Wichtige technische Merkmale von CockroachDB Technik zur Zeitsynchronisation: Google Spanner verwendet Atomuhren und GPS-Uhren, CockroachDB wurde jedoch so entworfen, dass es auch auf Standardhardware läuft NTP-basierte Korrektur von Synchronisationslatenzen, Vergleich von Clock Drift zwischen Knoten und Ausschluss von Mitgliedern bei Überschreitung des maximalen Offsets Multi-Region-Konfiguration: Mit der Funktion Table Localities ist eine Optimierung entlang von Read/Write-Trade-offs möglich Daten werden passend zur geografischen Lage der Nutzer verteilt, um Performance und Latenz zu verbessern Lernvorschläge für den Einsatz von CockroachDB Neuimplementierung des MovR-Beispiels: MovR (Beispiel für eine verteilte Anwendung) mit einer Sprache und einem Framework nach Wahl umsetzen Mit den Multi-Region- und Skalierungsstrategien von CockroachDB beim Entwurf globaler Anwendungen experimentieren Warum CockroachDB wählen Anders als andere verteilte Datenbanken wie DynamoDB kann es kostenlos lokal ausgeführt werden Es bietet die differenzierenden Eigenschaften starke Konsistenz und globale Verteilung Wrap Up Die vorgestellten Datenbanken wurden jeweils entwickelt, um unterschiedliche Probleme und Anforderungen zu lösen Nutzen Sie 2025, um diese Datenbanken kennenzulernen und interessantere sowie kreativere Wege der Problemlösung zu erkunden!

(matt.blwt.io)

53 Punkte von xguru 2024-12-09 | 14 Kommentare | Auf WhatsApp teilen

Vorstellung von 7 DBs, die es wert sind, beachtet zu werden, um unterschiedliche Probleme zu lösen
Dies ist keine Liste der „besten DBs“, sondern eine Sammlung von Tools, die neue und nützliche Perspektiven bieten
Für 2025 wird empfohlen, jeweils eine Woche in jede dieser DBs zu investieren (7 DBs in 7 Weeks)

1. PostgreSQL: die Standarddatenbank

PostgreSQL ist eine stabile Technologie, die standardmäßig eingesetzt wird
- Der Ausdruck „Just use Postgres“ ist ein weithin bekanntes Meme und steht sinnbildlich für Verlässlichkeit
- Es erfüllt ACID und bietet starke Funktionen einschließlich physischer und logischer Replikation
- Es ist eine stabile Datenbank mit breiter Unterstützung durch große Anbieter
Der größte Reiz von PostgreSQL: Erweiterbarkeit
- Über Extensions lassen sich einzigartige Funktionen hinzufügen
- Beispiele wichtiger Extensions:
  - AGE: Unterstützung für Graph-Datenstrukturen und die Cypher-Abfragesprache
  - TimescaleDB: Unterstützung für die Arbeit mit Zeitreihendaten
  - Hydra Columnar: bietet eine spaltenbasierte Storage Engine
- Extensions sind ein Kernelement, das PostgreSQL von anderen Datenbanken unterscheidet
Nützlichkeit und Erweiterbarkeit von PostgreSQL
- Es verfügt über ein vielfältiges Ökosystem, und die Standardeinstellungen sind sinnvoll und benutzerfreundlich
- Auch Nicht-PostgreSQL-Dienste bieten Client-Kompatibilität über das Postgres-Wire-Protocol
- Es ist leichtgewichtig genug, um sogar in WebAssembly-(Wasm-)Umgebungen installiert zu werden
Empfehlung, PostgreSQL zu lernen
- Es lohnt sich, Zeit zu investieren, um die Möglichkeiten und Grenzen von PostgreSQL zu verstehen
- Beispiel: die Komplexität von MVCC (Multi-Version Concurrency Control) verstehen
- Empfohlen werden die Entwicklung einer einfachen CRUD-Anwendung und das Schreiben von PostgreSQL-Extensions

2. SQLite: die Local-First-Datenbank

SQLite ist eine „Local-First“-Datenbank, die eigenständig laufen kann
- Sie verlässt das Client-Server-Modell und läuft in derselben Umgebung wie die Anwendung
- Beispiel: WhatsApp und Signal nutzen SQLite auf dem Gerät, um Chat-Daten zu speichern
Fortgeschrittene Einsatzszenarien für SQLite
- Kreative Nutzung weit über eine grundlegende ACID-konforme Datenbank hinaus
- Neue Tools und Extensions:
  - Litestream: bietet Streaming-Backups für SQLite
  - LiteFS: unterstützt verteilten Zugriff und ermöglicht flexiblere Topologien
  - CR-SQLite: nutzt CRDTs (Conflict-free Replicated Data Types), um beim Zusammenführen von Change Sets die Notwendigkeit zur Konfliktauflösung zu beseitigen
Neue Aufmerksamkeit für die Popularität von SQLite
- Dank Ruby on Rails 8.0 rückt es erneut in den Fokus
- 37signals: entwickelt Rails-Module auf Basis von SQLite (z. B. Solid Queue)
  - Unterstützung von Rails für die Verwaltung mehrerer SQLite-Datenbanken (database.yml)
- Bluesky: verwendet für jeden Nutzer eine eigene SQLite-Datenbank als Personal Data Server
Empfehlung, den Einsatz von SQLite zu lernen
- Mit SQLite lokale Architekturansätze experimentell erproben
- Versuchen, das bisherige PostgreSQL-basierte Client-Server-Modell durch SQLite zu ersetzen

3. DuckDB: die Datenbank, die alles abfragen kann

DuckDB ist eine eingebettete Datenbank, die auf OLAP spezialisiert ist
- Wie SQLite arbeitet sie zusammen mit der Anwendung, fokussiert sich aber auf OLAP statt auf OLTP
- Ein System, das für Datenanalyse und abfragezentrierte Nutzung entworfen wurde
Die „Query-Anything“-Eigenschaft von DuckDB
- Unterschiedliche Datenquellen können direkt per SQL abgefragt werden:
  - gängige Dateiformate wie CSV, TSV und JSON
  - Unterstützung für fortgeschrittene Dateiformate wie Parquet
- Diese Fähigkeit bietet Flexibilität, etwa bei der Analyse von Datenströmen von Bluesky
Erweiterbarkeit und Ökosystem
- Auch DuckDB verfügt über Extensions, wenn auch nicht so reichhaltig wie Postgres (ein relativ junges Projekt)
- Es gibt viele Community-Erweiterungen; bemerkenswert ist gsheets (Anbindung an Google Sheets)
Empfehlung, den Einsatz von DuckDB zu lernen
- Mit Python-Notebooks oder Evidence für Datenanalyse und -verarbeitung experimentieren
- Kombination mit SQLite: analytische Abfragen einer SQLite-Datenbank an DuckDB delegieren, um die Performance zu steigern

4. ClickHouse: die spaltenorientierte Datenbank

ClickHouse ist eine Datenbank, die auf OLAP-Workloads spezialisiert ist
- Die Kombination aus PostgreSQL für OLTP und ClickHouse für OLAP ist ideal
- Sie verarbeitet groß angelegte analytische Workloads und unterstützt hohe Dateninsertraten durch horizontale Skalierung und Sharding
Wichtige Merkmale von ClickHouse
- Hierarchical Storage wird unterstützt:
  - „Hot Data“ und „Cold Data“ können getrennt gespeichert werden
  - Beispiel: Die GitLab-Dokumentation behandelt Einsatzfälle dazu im Detail
- Verarbeitung großer Datensätze und Echtzeitanalyse:
  - Geeignet für Datensätze, deren Größe für DuckDB schwer zu bewältigen ist
  - Liefert starke Performance in Situationen, in denen Echtzeitanalyse erforderlich ist
Komfort im Betrieb
- Dokumentation zu Deployment, Skalierung, Backups und anderen Betriebsaspekten ist systematisch und detailliert
- Beispiel: Es gibt sogar Dokumentation dazu, wie passende CPU-Einstellungen gewählt werden
Empfehlung, ClickHouse zu lernen
- Mit großen analytischen Datensätzen experimentieren oder in DuckDB erstellte Analysen nach ClickHouse übertragen
- Mit der eingebetteten Version von ClickHouse, chDB, ist ein direkterer Vergleich mit SQLite möglich

5. FoundationDB: die geschichtete Datenbank

FoundationDB ist ein einzigartiges System, das als „Fundament einer Datenbank“ dient
- Es wurde als Key-Value-Store entworfen, funktioniert aber eher als „Grundlage“ zum Aufbau von Datenbanken als als einfache Datenbank
- Es wird von großen Unternehmen wie Apple, Snowflake und Tigris Data eingesetzt
Wichtige Merkmale und Grenzen
- Einschränkungen:
  - Transaktionsdaten dürfen 10 MB nicht überschreiten
  - Transaktionen dürfen nach dem ersten Lesen nicht länger als 5 Sekunden dauern
- Durch diese Beschränkungen sind vollständige ACID-Transaktionen auch in großen Umgebungen möglich
  - Beispiel: Betrieb von Clustern mit mehr als 100 TiB
Design und Tests von FoundationDB
- Es wurde für bestimmte Workloads optimiert entworfen
- Simulationstests belegen Stabilität und Skalierbarkeit:
  - Antithesis und andere Datenbanken verwenden dieselbe Testmethodik
  - Verwandte Referenzen: Dokumente von Tyler Neely und Phil Eaton
FoundationDB als „geschichtete“ Datenbank
- Die Kopplung zwischen Storage Engine und Datenmodell ist locker:
  - Die Storage Engine kann auf verschiedenen Schichten neu zugeordnet werden
  - Beispiele: Record Layer, Document Layer (bereitgestellt von der FoundationDB-Organisation)
- Das von Tigris Data verfasste Beispiel für Layer-Design ist eine nützliche Referenz
Empfehlung, FoundationDB zu lernen
- Tutorials durcharbeiten und das Potenzial erkunden, Systeme wie RocksDB zu ersetzen
- Design Recipes und zugehörige Papers lesen
- Über die Dokumente zu Anti-Features und Features die Einsatzgrenzen und die lösbaren Probleme verstehen

6. TigerBeetle: die kompromisslos genaue Datenbank

TigerBeetle ist eine Single-Purpose-Datenbank, die auf Finanztransaktionen spezialisiert ist
- Anders als General-Purpose-Datenbanken ist sie auf einen bestimmten Zweck fokussiert, insbesondere auf Finanztransaktionen
- Sie ist als Open Source verfügbar und wurde mit dem Ziel hoher Zuverlässigkeit und Genauigkeit entworfen
Designphilosophie für kompromisslose Genauigkeit
- Umsetzung von NASAs Power of Ten Rules und Protocol-Aware Recovery
- Verwendung von strict serialisability und Direct I/O, um Probleme im Zusammenhang mit dem Kernel-Page-Cache zu vermeiden
- Die Gründlichkeit zeigt sich in der Safety-Dokumentation und im besonderen Programmierstil „Tiger Style“
Innovativer Ansatz mit der Sprache Zig
- Zig ist eine noch vergleichsweise junge Sprache für Systemprogrammierung, passt aber ideal zu den Zielen von TigerBeetle
- Die Stärken von Zig werden genutzt, um Einfachheit und Performance zu maximieren
Vorschläge zum Lernen und Nutzen von TigerBeetle
- In einer lokalen Deployment-Umgebung mit der Modellierung von Finanzkonten experimentieren:
  - Installation und Nutzung anhand des Quick Start
- Die System-Architecture-Dokumentation heranziehen, um Kombinationsmöglichkeiten mit General-Purpose-Datenbanken zu untersuchen
- Beispiel: Integration zusammen mit PostgreSQL oder FoundationDB zur Erweiterung der Einsatzszenarien

7. CockroachDB: die globale Datenbank

CockroachDB ist eine global verteilte Datenbank
- Sie ist mit dem PostgreSQL-Wire-Protocol kompatibel und unterstützt horizontale Skalierung sowie starke Konsistenz
- Das von Google Spanner inspirierte Design ermöglicht die Ausdehnung der Datenbank über mehrere Regionen hinweg
Wichtige technische Merkmale von CockroachDB
- Technik zur Zeitsynchronisation:
  - Google Spanner verwendet Atomuhren und GPS-Uhren, CockroachDB wurde jedoch so entworfen, dass es auch auf Standardhardware läuft
  - NTP-basierte Korrektur von Synchronisationslatenzen, Vergleich von Clock Drift zwischen Knoten und Ausschluss von Mitgliedern bei Überschreitung des maximalen Offsets
- Multi-Region-Konfiguration:
  - Mit der Funktion Table Localities ist eine Optimierung entlang von Read/Write-Trade-offs möglich
  - Daten werden passend zur geografischen Lage der Nutzer verteilt, um Performance und Latenz zu verbessern
Lernvorschläge für den Einsatz von CockroachDB
- Neuimplementierung des MovR-Beispiels:
  - MovR (Beispiel für eine verteilte Anwendung) mit einer Sprache und einem Framework nach Wahl umsetzen
- Mit den Multi-Region- und Skalierungsstrategien von CockroachDB beim Entwurf globaler Anwendungen experimentieren
Warum CockroachDB wählen
- Anders als andere verteilte Datenbanken wie DynamoDB kann es kostenlos lokal ausgeführt werden
- Es bietet die differenzierenden Eigenschaften starke Konsistenz und globale Verteilung

Wrap Up

Die vorgestellten Datenbanken wurden jeweils entwickelt, um unterschiedliche Probleme und Anforderungen zu lösen
Nutzen Sie 2025, um diese Datenbanken kennenzulernen und interessantere sowie kreativere Wege der Problemlösung zu erkunden!

14 Kommentare

wfedev 2025-11-28

Alles abfragen! 😆🐤

budaestew 2024-12-16

Ich war überrascht, wie herausragend DuckDB bei der Analyseleistung ist.

halfenif 2024-12-09

Ich arbeite seit einigen Monaten mit sqlite. Nach Datum geordnet. Ich bearbeite Daten in einer Größenordnung von 2 Millionen Einträgen und 5 GB.

Mit der Verarbeitungsgeschwindigkeit bin ich zufrieden, aber es dauert zu lange, das Ganze nach der Aufbereitung wieder in Excel zu exportieren und den Beteiligten bereitzustellen.

Ich sollte mich wohl etwas genauer mit dem Ansatz unter Verwendung von OpenPyXl beschäftigen.

kimjj81 2024-12-18

Ich weiß nicht, welcher Zauber dahintersteckt, aber anscheinend nutzen sie die Kombination aus duckDB und sqlite.

channprj 2024-12-09

Überraschend, dass MongoDB gar nicht erwähnt wurde.

felizgeek 2024-12-09

Falls Sie sich Sorgen um die Lernkurve für Entwickler machen, empfehle ich SQLite. Es ist dateibasiert und daher einfach.

savvykang 2024-12-09

Wenn sicher ist, dass kein Remote-Zugriff benötigt wird, ist das wirklich eine sehr zufriedenstellende Lösung. Es gibt keinen Verwaltungsaufwand mehr für die DB, und auch Datenbearbeitung sowie Backup/Wiederherstellung sind angenehm einfach.

aer0700 2024-12-09

Wenn man sagt, dass man SQLITE verwenden will, ist das etwas, wofür man leicht Gegenwind bekommt, aber bevor man sagt, dass man SQLITE verwendet hat, merkt es auch niemand ... SQLITE ist besser, als man denkt.

jpumpkin94 2024-12-09

Ich nutze seit Jahrzehnten (??) nur MySQL,
und würde mich über viele Kommentare von Leuten freuen, die PostgreSQL in der Praxis produktiv einsetzen, wie es damit aussieht.

zuppiy 2024-12-09

„Elefanten sind Seehunden überlegen“
Das trifft in den meisten Situationen zu

roxie 2024-12-11

hahaha

kibae 2024-12-09

Ich bin 2001 von einem fehlerbehafteten mysql (damals v3.x) auf pgsql umgestiegen.
Es gibt viele Punkte, in denen ich es für überlegen halte, aber in der Praxis ist die Existenz von Partial Indexes meiner Meinung nach die stärkste Funktion.

chanhee 2024-12-09

Beruflich habe ich nur Oracle und Sqlserver verwendet, und als ich dann MySQL nutzen wollte, gab es wirklich viel zu oft Momente, in denen ich dachte: "Warum geht das nicht?" Ich erinnere mich selbst nicht mehr genau daran.
Letztendlich bin ich dann zu Postgres gewechselt.

bbulbum 2024-12-09

Nachdem ich zuvor mit Postgres gearbeitet habe und nun an einen Ort gewechselt bin, an dem MySQL verwendet wird, denke ich gefühlt ziemlich oft: Warum geht das nicht? Warum kommt hier nicht diese Performance heraus?
Ich erinnere mich nicht mehr genau, was es war (vielleicht etwas Kleines, vielleicht auch nicht).