Zusammenfassung

MotherDuck erweitert die analytische Leistung von DuckDB auf die cloud mit kollaborativen Funktionen und bietet eine viermal schnellere Leistung als BigQuery sowie Kosteneinsparungen gegenüber herkömmlichen data Warehouses durch serverlose, nutzungsabhängige Preise. Nach der Ankündigung der neuen europäischen cloud von MotherDuck waren wir von der Leistung und dem attraktiven Preis beeindruckt. MotherDuck kann bereits in Ihre Goldschichten integriert werden, um die Bereitstellung von data zu beschleunigen und gleichzeitig Kosten zu sparen. Siehe Leistungsbenchmark.

Einführung

In der sich schnell entwickelnden Landschaft der data fordert ein neuer Akteur die etablierte Ordnung der cloud data Warehouses heraus. MotherDuckbaut auf dem Fundament von DuckDBauf der Grundlage der blitzschnellen Analyse-Engine von DuckDB aufbaut, verspricht eine Leistung auf Unternehmensniveau mit der Einfachheit und Kosteneffizienz, nach der sich moderne data sehnen. Aber kann diese Ente wirklich mit den etablierten Giganten konkurrieren?

Wir haben MotherDuck einem strengen Test mit etablierten Wettbewerbern unterzogen, um zu sehen, ob es dem Hype gerecht wird. Was wir dabei herausgefunden haben, stellt den aktuellen Status quo analytischer Datenbanken in Frage und deutet auf einen grundlegenden Wandel in der Art und Weise hin, wie wir an die cloud data herangehen. Dies ist die Geschichte, wie eine eingebettete Datenbank das Fliegen lernte, und warum sie Ihren data revolutionieren könnte.

Um diesen neuen Kunden zu gewinnen, müssen sich die Einzelhändler schnell anpassen.

Eine schlüpfende Ente

MotherDuck beschreibt sich selbst als "data mit einer Skalierung auf Terabytes für kundenorientierte Analysen und BI". Um zu verstehen, was diesesdata so besonders macht, müssen wir zunächst einen Blick auf DuckDBDas Open-Source-Datenbanksystem DuckDB hat in den letzten Jahren den data Stack in aller Stille revolutioniert. Einfach ausgedrückt, ist DuckDB ein In-Memory-OLAP-SQL-Datenbanksystem. Für diejenigen, die mit dem Datenbankjargon nichts am Hut haben, wollen wir einmal auspacken, was das eigentlich bedeutet:

OLAP steht für Online Analytical Processing. Es handelt sich dabei um eine Datenbank, die darauf ausgelegt ist, riesige data zu verarbeiten und komplexe Geschäftsfragen schnell zu beantworten. Im Gegensatz zu herkömmlichen Datenbanken, die sich durch das Auffinden einzelner Datensätze auszeichnen (z. B. die Suche nach einer Kundenbestellung), sind OLAP-Datenbanken darauf ausgelegt, Millionen von Zeilen zu durchsuchen und umfangreiche Berechnungen in Sekundenschnelle durchzuführen. Sie erreichen diese Geschwindigkeit, indem sie data in Spalten und nicht in Zeilen speichern. So lassen sich blitzschnell Trends analysieren, Durchschnittswerte berechnen oder Umsätze über ganze Datensätze summieren. Dies ist derselbe Ansatz, der auch in modernen data Warehouses wie BigQuery oder Snowflake verwendet wird. Auf der anderen Seite gibt es OLTP-Datenbanken (Online Transaction Processing) wie PostgreSQL, SQLite oder MySQL. Dies sind die Arbeitstiere, die Ihre Anwendungen antreiben und Tausende von einzelnen Lese- und Schreibvorgängen pro Sekunde verarbeiten, damit Ihre Anwendung reibungslos läuft. Weitere Informationen zu OLAP und OLTP.

Um zu verstehen, wie revolutionär der Ansatz von DuckDB wirklich ist, müssen wir einen Schritt zurücktreten und uns ansehen, wie wir hierher gekommen sind. Mitte der 1990er Jahre, als Web-Giganten wie Yahoo und Amazon auf den Plan traten, stießen sie auf eine Mauer, die die gesamte data umgestalten sollte. Diese Unternehmen ertranken in einer data, die wir später als Big data" bezeichnen würden, und ihre bestehenden Systeme konnten einfach nicht mehr mithalten. Die Lösung? Teure, monolithische Infrastrukturen, die den Umfang bewältigen konnten. Doch als die Hardwarekosten in den 2000er Jahren drastisch sanken, kam eine neue Philosophie auf: Warum nicht viele kleinere, billigere Maschinen verwenden, anstatt größere zu kaufen? Aus dieser Überlegung heraus entstanden verteilte Systeme wie MapReduce und Apache Hadoop, Technologien zur Verteilung von Arbeitslasten auf Cluster von Standardhardware. Amazon machte sich diesen Trend zunutze, indem es diese verteilten Technologien als Dienste verpackte und mit Amazon Web Services die erste große cloud ins Leben rief. Jahrelang wurde dies zum Standardverfahren: Wenn man ein data hatte, verteilte man es auf mehrere Maschinen (Fundamentals of Data Engineering, Joe Reis & Matt Housley).

Faszinierend ist jedoch Folgendes: Während alle mit der Entwicklung verteilter Systeme beschäftigt waren, geschah im Hintergrund etwas anderes. Die gleichen Kräfte, die das verteilte Rechnen wirtschaftlich machten, machten auch die einzelnen Rechner unglaublich leistungsfähig. Ihr Laptop ist heute mit mehr Arbeitsspeicher, schnelleren Prozessoren und besserem Speicher unglaublich leistungsfähig geworden. Die Entwickler von DuckDB erkannten diese übersehene Chance: Was wäre, wenn wir, anstatt immer weiter zu skalieren, intelligenter skalieren könnten? Was wäre, wenn wir viele data ganz ohne die Komplexität verteilter Systeme lösen könnten?

Eine der am häufigsten eingesetzten Datenbank-Engines der WeltSQLite verfolgt einen radikal anderen Ansatz als herkömmliche Datenbanken. Während PostgreSQL und MySQL als separate Server laufen, mit denen sich Anwendungen über ein Netzwerk verbinden, wird SQLite als leichtgewichtige Bibliothek direkt in Ihre Anwendung eingebettet. Es gibt keinen Server, der konfiguriert werden muss, keinen Netzwerk-Overhead und keine komplexe Einrichtung, sondern nur eine reine, lokale Datenbankfunktionalität, die innerhalb des Prozesses Ihrer Anwendung läuft. Diese Einfachheit, kombiniert mit bemerkenswerter Zuverlässigkeit und Geschwindigkeit, hat dazu geführt, dass SQLite von mobilen Anwendungen bis hin zu Webbrowsern allgegenwärtig ist.

DuckDB wendet dieselbe eingebettete Philosophie auf analytische Workloads an und beweist, dass man nicht immer ein verteiltes System braucht, um große Datenmengen zu verarbeiten. So wie SQLite die lokale data revolutioniert hat, nutzt DuckDB die rohe Kraft Ihres lokalen Rechners, um Analysen wieder einfach zu machen. Die Installation dauert nur wenige Sekunden, es gibt keine externen Abhängigkeiten, mit denen Sie sich herumschlagen müssen, und plötzlich können Sie komplexe analytische Abfragen auf Gigabytes von data ausführen, ohne eine einzige cloud zu starten.

Das Besondere an DuckDB ist, dass es Entwickler dort abholt, wo sie sind. Sie müssen einen Python DataFrame analysieren? DuckDB kann ihn direkt abfragen. Sie möchten eine CSV-Datei durchsuchen? Das ist kein Problem. Diese nahtlose Integration in Kombination mit der blitzschnellen Columnar-Engine hat DuckDB zu einem der am schnellsten wachsenden Datenbanksysteme im Bereich der Analytik gemacht. Die Leistungssteigerungen sind oft so dramatisch, dass Sie sich fragen, warum Sie überhaupt verteilte Systeme einsetzen. Wenn Sie tiefer in die technische Philosophie hinter diesem Ansatz eintauchen möchten, empfehlen wir Ihnen folgende Lektüre "Prozessbegleitendes analytisches Data mit DuckDB" von Hannes Mühleisen, dem Miterfinder von DuckDB.

Nachdem Sie nun wissen, was DuckDB ist, lassen Sie uns über seine Grenzen sprechen. Jede Technologie hat Kompromisse. DuckDB kann nur auf einem einzigen Rechner betrieben werden und akzeptiert nur eine Verbindung zur gleichen Zeit. In einer Welt, in der data cloud Lösungen entwickeln, die ganze Unternehmen bedienen, ist dies eine ziemlich große Einschränkung. Es ist nicht möglich, dass mehrere Analysten gleichzeitig dieselbe DuckDB-Instanz abfragen, und schon gar nicht können Datensätze von verschiedenen Teams gemeinsam genutzt werden, wie es bei einem herkömmlichen data Warehouse der Fall wäre. Bei aller Schnelligkeit und Einfachheit sperrt DuckDB Ihre data im Wesentlichen auf einen einzigen Rechner, auf den jeweils nur eine Person Zugriff hat. Wie kann man also diese unglaublich schnelle, aber von Natur aus auf einen einzigen Benutzer ausgerichtete Datenbank in ein cloud data Warehouse verwandeln, das ein ganzes Unternehmen bedienen kann?

Die Ente, die das Fliegen lernte

An dieser Stelle kommt MotherDuck ins Spiel. MotherDuck ist ein serverloses data Warehouse, das die Lücke zwischen der reinen Leistung von DuckDB und den Anforderungen moderner data an die Zusammenarbeit schließt. MotherDuck schafft ein sogenanntes "individualisiertes Analytics data Warehouse", das jedem Benutzer seine eigene hochleistungsfähige DuckDB-Instanz zur Verfügung stellt und gleichzeitig die Möglichkeit bietet, data innerhalb des Unternehmens gemeinsam zu nutzen. So funktioniert die Architektur:

In herkömmlichendata ist Ihr Laptop nur ein dummes Terminal. Alle schweren Aufgaben werden auf entfernten Servern ausgeführt, für die Sie stundenweise bezahlen. Die Sache ist jedoch die: Ihr MacBook ist wahrscheinlich schneller als eine data für 20 bis 60 Dollar pro Stunde. MotherDuck versucht, diese Rechenleistung mit zwei innovativen Ansätzen zu nutzen: 

  • Browserbasierte Analysen, die Berechnungen direkt zum Nutzer bringen.
  • Duale Ausführung, die auf intelligente Weise die Verarbeitungsleistung Ihres lokalen Rechners mit cloud kombiniert, um schneller Ergebnisse zu erzielen, als dies mit einem der beiden Ansätze allein möglich wäre.

Bevor ich auf diese beiden Methoden eingehe, möchte ich anmerken, dass die Rechenleistung von MotherDuck besonders gut zur Geltung kommt, wenn sie auf Ihre Goldschicht. Für diejenigen, die mit diesem Begriff nicht vertraut sind, ist die Goldschicht die endgültigen, geschäftsfähigen data , die bereinigt, aggregiert und angereichert wurden. Im Wesentlichen handelt es sich dabei um die ausgefeilten Datensätze, die Ihre Analysen, Berichte und maschinellen Lernverfahren unterstützen. Diese data sind die Grundlage für Ihre wichtigsten Geschäftsentscheidungen, weshalb die Leistung hier absolut entscheidend ist. Jeder Stakeholder hat schon einmal unter quälend langsamen Dashboards gelitten, und jedes Mitglied des data hat schon einmal auf das sich drehende Rad des Todes gestarrt, während es darauf wartete, dass komplexe Abfragen beendet wurden. MotherDuck geht diese Frustration frontal an.

In-Browser-Analysen

Diese Lösung nutzt das leichtgewichtige und portable Design von DuckDB, das über WebAssembly (Wasm) direkt in Ihrem Browser ausgeführt werden kann. Stellen Sie sich Wasm als eine Technologie vor, mit der komplexe Software nativ in Ihrem Browser ausgeführt werden kann: keine Plugins, keine Downloads, nur Rechenleistung, wo Sie sie am meisten brauchen. Mit DuckDB, das clientseitig ausgeführt wird, können Sie komplexe analytische Abfragen durchführen, ohne die übliche Prozedur des Sendens von Anfragen an einen Server und des Wartens auf Antworten. Die data findet direkt in Ihrem Browser statt, wodurch Netzwerklatenz vermieden und Abhängigkeiten von der Infrastruktur vollständig reduziert werden. Sie können diese Magie selbst erleben, indem Sie DuckDB in Ihrem Browser.

Auch wenn wir hier nicht näher auf die technische Umsetzung eingehen wollen, ist es doch erwähnenswert, dass DuckDB-Wasm sich auszeichnet. Ausführliche Forschung in diesem Papier zeigt, dass es bestehende browserbasierte Lösungen wie die Wasm-Version von SQLite oder Lovefield, eine JavaScript-basierte Datenbank, deutlich übertrifft. Diese clevere technische Demo signalisiert einen grundlegenden Wandel in der Art und Weise, wie wir über den Standort analytischer Berechnungen denken.

MotherDuck bietet diese von Wasm angetriebene Architektur, wie Mehdi Ouazza in diesem Artikel erklärt diesem Artikel. Dieser Ansatz ist besonders leistungsfähig für Gold-Layer-Analysen. Ihr data kann mit sauberen, geschäftsfähigen data arbeiten, ohne sich um die Backend-Infrastruktur kümmern zu müssen. Die Verarbeitung erfolgt lokal, um eine maximale Geschwindigkeit zu erreichen, und Sie erzielen einige der schnellsten Antwortzeiten, die möglich sind, indem Sie die Netzwerklatenz vollständig eliminieren. Außerdem vermeiden Sie die hohen Rechenkosten, die Ihnen herkömmlichedata gerne für jede Abfrage in Rechnung stellen. Das ist ein überzeugendes Angebot: schnellere Analysen, niedrigere Kosten und eine einfachere Architektur in einem.

 

Doppelte Ausführung

Eine weitere Möglichkeit, MotherDuck in Ihrer Goldschicht zu nutzen, ist die duale Ausführungsfunktion, die auf intelligente Weise lokale Verarbeitungsleistung mit cloud kombiniert. Anstatt Ihr gesamtes data zu zwingen, dieselben Rechenressourcen zu teilen, gibt MotherDuck jedem Benutzer sein eigenes "Entlein": eine individuelle, serverlose Recheninstanz, die mit seinen Anforderungen skaliert.

Die wahre Stärke der dualen Ausführung zeigt sich, wenn Sie mit data arbeiten, die über verschiedene Quellen verstreut sind. Stellen Sie sich vor, Sie müssen data abfragen, die in MotherDuck gespeichert sind, sie mit Dateien in S3 kombinieren und sie mit einem Datensatz verbinden, der sich lokal auf Ihrem Laptop befindet. Herkömmliche cloud würden Sie dazu zwingen, alles an einen Ort hochzuladen, bevor Sie quellenübergreifende Abfragen durchführen können. Die hybride Ausführung von MotherDuck ist intelligenter. Sie analysiert Ihre Abfrage, speichert nur die erforderlichen data aus jeder Quelle und führt intelligente Verknüpfungen zwischen verschiedenen Standorten durch, wodurch Sie Zeit und Kosten für die data sparen.

Unter der Haube zerlegt der Optimierer von MotherDuck Ihre Abfrage in einen DAG (gerichteten azyklischen Graphen) von Operationen, schätzt die Kosten für die Ausführung jedes Knotens vor Ort gegenüber der Ausführung an einem anderen Ort und kümmert sich automatisch um die data . Sie schreiben einfach SQL, MotherDuck ermittelt die optimale Ausführungsstrategie. Mit diesem Ansatz wird die cloud grundlegend neu definiert. Wir müssen uns nicht mehr zwischen lokaler Einfachheit und cloud entscheiden, die jeweils ihre eigene Komplexität in Bezug auf data und Workflow-Orchestrierung mit sich bringen. Mit MotherDuck erhalten Sie das Beste aus beiden Welten: Sie können lokal ausgeführt werden, wenn Ihr Rechner damit zurechtkommt, und bei Bedarf in die cloud skalieren und mühelos gemeinsam nutzen. Es handelt sich um eine serverlose Lösung, die die Kosten für cloud senkt, da Sie nur für das zahlen, was Sie tatsächlich berechnen.

Aber jetzt wird es interessant: Die gemeinsame Nutzung von data wird mühelos. Erinnern Sie sich noch daran, dass die Zusammenarbeit mit DuckDB aufgrund der Einzelplatznutzung mühsam war? Wenn ein data eine beeindruckende Analyse erstellte, musste er alles exportieren und auf ein gemeinsames Speichersystem hochladen, nur damit seine Kollegen darauf zugreifen konnten. Mit MotherDuck ist die gemeinsame Nutzung so einfach wie das Klicken auf eine Schaltfläche oder das Ausführen einer einzigen Codezeile, um einen Null-Kopie-Snapshot mit entsprechenden Zugriffskontrollen zu erstellen. Keine data , keine Speicherduplizierung, nur sofortige Zusammenarbeit.

Erfahren Sie mehr über Dual/Hybrid Query Execution im MotherDuck Paper von der der Konferenz über innovative Data (CIDR). Sie können sich auch diesen dbt Coalesce Vortrag von Jordan Tigani, Mitbegründer und CEO von MotherDuck, ansehen.

Enten in freier Wildbahn

Wir haben gesehen, wie MotherDuck die data von erheblichem Overhead befreit und gleichzeitig leistungsstarke Analysefunktionen für Ihre Goldschicht bereitstellt. Aber die Theorie geht nur so weit. Wir wollten MotherDuck im Vergleich zu etablierten Anbietern im Bereich cloud data Warehouse testen. Ein Blick auf den Data 2025 der von Metabase veröffentlicht wurde, fanden wir etwas Überraschendes: PostgreSQL ist nach wie vor die beliebteste Datenbankwahl, auch für analytische Workloads, gefolgt von Snowflake und BigQuery bei den befragten Unternehmen. Daraus ergaben sich unsere Vergleichsziele.

Wir haben beschlossen, MotherDuck mit gehostetem PostgreSQL auf Google Cloud und BigQuery zu vergleichen, wobei wir Apache Superset als unser BI-Tool der Wahl. Superset war aus mehreren Gründen sinnvoll: Es ist Open Source, weit verbreitet und hat native MotherDuck-Kompatibilität mit den meisten anderen großen Datenbanken. Unsere Testumgebung bestand aus Apache Superset, das auf der Google Cloud Kubernetes Engine bereitgestellt und mit drei verschiedenen Backends verbunden war: BigQuery, PostgreSQL auf Cloud SQL und MotherDuck.

Wir haben unsere Tests in zwei Phasen unterteilt. Zunächst führten wir den TPC-H-Benchmark durch: ein standardisierter Benchmark zur Entscheidungsunterstützung, der uns zeigen sollte, wie MotherDuck in einer kontrollierten, theoretischen Umgebung abschneidet. Dann gingen wir näher an die Realität heran und testeten, wie die Beziehung zwischen Superset und MotherDuck im Vergleich zu herkömmlichen data Warehouses in realen Dashboarding-Szenarien aussah.

TPC-H-Benchmarking

TPC-H ist der Standard für die Prüfung der Leistung analytischer Datenbanken. Es handelt sich um einen Benchmark zur Entscheidungsunterstützung, der entwickelt wurde, um große data zu untersuchen, komplexe Abfragen auszuführen und Antworten auf kritische Geschäftsfragen in verschiedenen Branchen zu liefern. Die vollständige Spezifikation finden Sie in der offiziellen Dokumentation. Der Benchmark besteht aus 22 Abfragen, die reale analytische Workloads simulieren, von einfachen Aggregationen bis hin zu komplexen Multi-Table-Joins.

Wir haben jede Abfrage einzeln durch das SQL-Labor von Superset für alle drei Datenbanken laufen lassen: MotherDuck, BigQuery und PostgreSQL. Wir haben die Abfragen auch direkt in der grafischen Benutzeroberfläche von MotherDuck getestet, um die Client-Server-Latenz zu eliminieren und weil, offen gesagt, jedes Unternehmen, das MotherDuck verwendet, seine data wahrscheinlich in der vom Notizbuch inspirierten Oberfläche von MotherDuck arbeiten lässt und nicht im SQL Lab von Superset. Außerdem kann die MotherDuck-Anwendung die bereits erwähnte WebAssembly-Architektur nutzen, und wir waren neugierig, wie diese browserbasierte Ausführung im Vergleich zu herkömmlichen Server-Client-Modellen abschneiden würde. Um faire Tests zu gewährleisten, war der Cache von Superset während aller Benchmarks deaktiviert.

Für diesen Benchmark haben wir den TPC-H-Skalierungsfaktor 10 (SF-10) verwendet, der einen Datensatz von 10 GB erzeugt. Wir haben uns für den Skalierungsfaktor 10 entschieden, weil 10 GB eine realistische Datensatzgröße für die analytischen Arbeitslasten der meisten Unternehmen darstellt, die groß genug ist, um aussagekräftige Leistungsunterschiede aufzuzeigen, ohne eine Infrastruktur im Unternehmensmaßstab zu erfordern. Hier sehen Sie, wie sich die data auf die wichtigsten Tabellen verteilen:

Wir haben die DuckDB TPC-H-Erweiterung verwendet, um die data lokal zu generieren, und sie dann nahtlos in MotherDuck hochgeladen. Dank der data von MotherDuck dauerte der Vorgang nur wenige Minuten.

Hier sind die TPC-H SF-10 Ergebnisse in Sekunden. Die gelbe Spalte zeigt die Ergebnisse der nativen Benutzeroberfläche der MotherDuck-App, während die anderen Spalten die Leistung des SQL Lab von Superset (SST) darstellen:

MotherDuck liefert durchgängig eine Leistung von weniger als einer Sekunde: 21 von 22 Abfragen über Superset werden in weniger als einer Sekunde abgeschlossen.und alle Abfragen werden in weniger als einer Sekunde abgeschlossen, wenn sie direkt über die MotherDuck-App ausgeführt werden. BigQuery zeigt eine respektable Leistung, ist aber im Durchschnitt etwa 4x langsamer als MotherDuck über die gesamte Benchmark-Suite hinweg. PostgreSQL zeigt eine gänzlich andere Geschichte, mit deutlich langsamerer Leistung und klaren Schwierigkeiten bei komplexen Aggregationen und Joins. Dies war vorhersehbar, da PostgreSQL grundsätzlich für OLTP-Workloads und nicht für die analytische Verarbeitung konzipiert ist, aber wir haben es in unseren Vergleich einbezogen, da es von Unternehmen nach wie vor häufig für analytische Aufgaben verwendet wird. Es ist erwähnenswert, dass PostgreSQL mit geeigneten Optimierungstechniken wie Indizierung, Partitionierung oder Materialized Views eine viel bessere Leistung erzielen könnte, aber selbst dann würde es immer noch gegen seine zeilenbasierte Architektur ankämpfen. Die Leistungslücke macht deutlich, warum es speziell entwickelte OLAP-Systeme wie MotherDuck gibt: Wenn Sie komplexe analytische Abfragen auf umfangreichen Datenbeständen durchführen, ist die Architektur von enormer Bedeutung.

TPC-H zeigt zwar die reine Abfrageleistung an, aber der eigentliche Test ist, wie sich dies auf die tatsächliche Benutzererfahrung in Business Intelligence-Tools auswirkt.

Leistung des Dashboards

Wir sahen, dass die Leistung für data , die mit SQL an ihrem data Warehouse arbeiten, hervorragend war, aber wir wollten testen, ob sich diese Verbesserung auch auf das Dashboarding übertragen lässt, bei dem die Geschäftsbeteiligten tatsächlich mit den data interagieren. Schließlich nützen blitzschnelle SQL-Abfragen nicht viel, wenn Ihre Dashboards immer noch ewig zum Laden brauchen.

Um dies zu testen, haben wir einen realistischen E-Commerce-Datensatz von Kaggle mit 67,5 Millionen Zeilen und einer data von 9 GB, d. h. einer Größenordnung, mit der viele Unternehmen bei ihren monatlichen Kundenanalysen arbeiten. Anhand dieser einzigen Tabelle haben wir ein umfassendes Dashboard erstellt, mit dem wir die Fähigkeit der einzelnen Systeme zur Bewältigung realer Business-Intelligence-Arbeitslasten testen konnten:

Ich habe das Dashboard in mehreren Durchläufen ausgiebig getestet, verschiedene Filter angewandt, Ladezeiten gemessen, den Cache deaktiviert und die Antwortzeiten über die Entwicklertools meines Browsers überwacht. Nach mehreren Testzyklen, um konsistente Ergebnisse sicherzustellen, sind hier die Dashboard-Leistungskennzahlen in Sekunden:

Unsere Dashboard-Ladetests zeigen die praktischen Auswirkungen der Datenbankleistung auf die Benutzererfahrung. MotherDuck bietet eine außergewöhnliche Dashboard-Reaktionszeit mit einer durchschnittlichen Ladezeit von nur 3,35 Sekunden und ermöglicht so wirklich interaktive Analysen, bei denen die Benutzer data ohne Reibungsverluste erkunden können. Im Gegensatz dazu benötigt BigQuery 8,55 Sekunden zum Laden desselben Dashboards. Dies ist für geplante Berichte noch akzeptabel, führt aber zu spürbaren Verzögerungen, die von explorativen Analysen abhalten können. Die Ladezeit von PostgreSQL von 216 Sekunden (>3 Minuten) macht es für die Verwendung in Dashboards völlig unpraktisch. Dieser Leistungsvorteil für MotherDuck kann die Art und Weise, wie Geschäftsanwender mit data interagieren, grundlegend verändern. Wenn Dashboards in Sekunden statt in Minuten geladen werden, steigt die Benutzerakzeptanz, können Analysten schnell auf Erkenntnisse zurückgreifen und die Analyse wird zu einem Wettbewerbsvorteil und nicht zu einem Engpass.

Vergleich der Preise

MotherDuck kombiniert Speicherung mit Abrechnung nach Aufwand Rechenleistung, optimiert für interaktive Analysen. Da die Skalierung auf einer einzigen Maschine erfolgt, anstatt sie über einen Cluster zu verteilen, wird der Overhead vermieden, für den die Benutzer letztendlich bezahlen. Eine Sitzung mit Dutzenden von Abfragen kostet vielleicht nur 0,05 bis 0,10 Dollar, während ein Team, das monatlich Tausende von Abfragen durchführt, vielleicht nur 20 bis 40 Dollar ausgibt. Im Gegensatz dazu können Always-on-Datenbanken 300 bis 500 US-Dollar pro Monat kosten, nur um in Betrieb zu bleiben, und cloud berechnen oft 5 bis 10 US-Dollar pro gescanntem TB. Mit seinem Scale-up-Design hält MotherDuck die Preisgestaltung einfach, vorhersehbar und kosteneffizient.

MotherDuck mag auf den ersten Blick teurer erscheinen, da es eine Organisationsgebühr und ein anderes Preismodell für die Datenverarbeitung hat. Beide Systeme verwenden jedoch Preismodelle, die unterschiedliche Nutzungsmuster begünstigen: BigQuery eignet sich hervorragend für die Verarbeitung großer Stapel, während MotherDuck für interaktive Analysen optimiert ist. Bei unserem TPC-H-Benchmark kostete die Ausführung von 22 Abfragen auf SF-10 $0,03 für MotherDuck gegenüber $0,60-$1,00 für BigQuery. Wenn man den Infrastruktur-Overhead berücksichtigt - unser PostgreSQL-Setup benötigte 14 €/Tag, nur um online zu bleiben - bietet der serverlose Ansatz von MotherDuck oft bessere Gesamtbetriebskosten für interaktive analytische Workloads.

Im Unternehmensmaßstab verschiebt sich die Wirtschaftlichkeit je nach Nutzungsmuster. BigQuery wird kosteneffektiver für die Stapelverarbeitung sehr großer Mengen, während MotherDuck seinen Vorteil für interaktive Analysen und explorative Workflows beibehält. Die wichtigste Erkenntnis: Wählen Sie Ihr Preismodell auf der Grundlage der Art und Weise, wie Ihr Team tatsächlich mit den data arbeitet, und nicht nur auf der Grundlage der reinen Kosten pro Einheit.

Hinweis: Alle Preisbeispiele beziehen sich auf die Region Europa-West4 und sollten eher zur Veranschaulichung dienen, da die tatsächlichen Kosten stark von den spezifischen Nutzungsmustern und data abhängen.

Schlussfolgerung

MotherDuck stellt einen grundlegenden Wandel in der Art und Weise dar, wie wir über analytische Datenbanken denken. Es stellt die Annahme in Frage, dass Sie komplexe, verteilte Systeme benötigen, um ernsthafte data zu bewältigen. MotherDuck übernimmt die eingebettete Philosophie von DuckDB und erweitert sie auf die cloud. So bietet MotherDuck die kollaborativen Funktionen, die moderne data benötigen, und behält gleichzeitig die Leistung bei, die DuckDB so außergewöhnlich macht.

Unsere Benchmarking-Ergebnisse sprechen eine deutliche Sprache: MotherDuck übertraf sowohl BigQuery als auch PostgreSQL durchgängig um ein Vielfaches und lieferte eine Abfrageleistung von weniger als einer Sekunde bei 10-GB-Datensätzen und Dashboard-Ladezeiten, die wirklich interaktive Analysen ermöglichen. Der Leistungsvorteil gegenüber BigQuery und der sehr große Vorteil gegenüber PostgreSQL in Dashboard-Szenarien bezieht sich nicht nur auf schnellere Abfragen, sondern auf die Umwandlung von Analysen in eine interaktivere, explorative Erfahrung, die eine data Entscheidungsfindung fördert.

Am wichtigsten ist vielleicht, dass MotherDuck diese Leistung erreicht und gleichzeitig die Komplexität der Infrastruktur und die Kosten drastisch reduziert. Während herkömmliche cloud eine ständig verfügbare Infrastruktur erfordern, die monatlich Hunderte von Dollar kostet, wird beim serverlosen Modell von MotherDuck nur die tatsächliche Nutzung berechnet, was die Kosten oft senkt. Das Pay-per-Compute-Preismodell ist perfekt auf die Arbeitsweise von Analysten abgestimmt: Sie führen mehrere Abfragen in Explorationssitzungen durch, anstatt isolierte, unregelmäßige Anfragen zu stellen.

Die Auswirkungen gehen über die reine Leistung und die Kosten hinaus. Das duale Ausführungsmodell und die browserbasierten Analysefunktionen von MotherDuck deuten auf eine Zukunft hin, in der die Grenze zwischen lokalem und cloud zunehmend fließend wird. Anstatt Teams zu zwingen, sich zwischen lokaler Einfachheit und cloud zu entscheiden, bietet MotherDuck beides und leitet die Berechnungen intelligent dorthin, wo sie am sinnvollsten sind.

Was mich beim Testen wirklich beeindruckt hat, war die Einfachheit der Nutzung und Einrichtung von MotherDuck. Das duale Ausführungsmodell ermöglichte es mir, data sowohl lokal als auch in der cloud gleichzeitig abzufragen, während die Einrichtung der Verbindung zwischen Superset und MotherDuck bemerkenswert einfach war.

Für Unternehmen, die ihre analytischen Fähigkeiten modernisieren möchten, beginnend mit der Goldschicht, bietet MotherDuck ein sehr attraktives Angebot: Leistung auf Unternehmensniveau, kollaborative Workflows und Kosteneffizienz, und das alles ohne den betrieblichen Aufwand einer herkömmlichen data Warehouse-Infrastruktur. In einer Welt, in der data Entscheidungen zunehmend den Wettbewerbsvorteil bestimmen, ist die Fähigkeit, data interaktiv und in Sekundenschnelle zu untersuchen, nicht nur ein Nice-to-have, sondern wird immer wichtiger.

Sind Sie bereit, die Leistung von MotherDuck selbst zu erleben? Sie können mit einer 21-tägigen kostenlosen Testversion oder mit dem kostenlosen 10-GB-Plan beginnen, um es mit Ihren eigenen Datensätzen und Arbeitslasten zu testen. Wenn Sie wissen möchten, ob MotherDuck zu Ihrem spezifischen data passt oder Hilfe bei der Implementierung benötigen, wenden Sie sich an unser Team bei ArtefactWir würden uns freuen, Ihre analytischen Anforderungen zu bewerten und Ihnen bei der Umstellung auf eine effizientere und kostengünstigere Analyseinfrastruktur zu helfen.