EDB verzeichnet 2,7-fache Concurrency-Verlangsamung gegenüber Snowflakes 3,9-facher im TPC-DS-Test

Die Hauptzahl aus dem McKnight Consulting Group Benchmark beträgt 58 Prozent: Das ist die Obergrenze der jährlichen TCO-Einsparungen, die EDB Postgres AI for WarehousePG gegenüber den führenden Cloud-Data-Warehouses bei einer 10-TB-erweiterten TPC-DS-Arbeitslast beansprucht. Im konkret genannten Beispiel entspricht das 222.886 $ pro Jahr für EDB gegenüber 351.953 $ für eine Multi-Cluster-Snowflake-Bereitstellung – ein Delta von 37 Prozent auf absoluter Dollarbasis. Ob 58 Prozent oder 37 Prozent die ehrlichere Zahl ist, hängt von einer Konfiguration ab, die die Pressemitteilung nicht vollständig beschreibt – und diese Lücke ist relevant.

Was geschah

Am 31. März 2026 veröffentlichte EnterpriseDB die Ergebnisse einer unabhängigen Benchmark-Studie von McKnight Consulting Group zusammen mit seinen Q1-Plattform-Updates, wie PR Newswire aus Wilmington berichtete. McKnight testete EDB PG AI for WarehousePG gegen Snowflake, Databricks, Amazon Redshift und Hive auf Apache Iceberg mit einem 10-TB-erweiterten TPC-DS-Datensatz, wobei das Testdesign auf parallele Mixed-Workloads mit hoher Gleichzeitigkeit ausgerichtet war und nicht auf die Spitzenleistung einzelner Abfragen.

Die gemeldeten Concurrency-Ergebnisse beim Skalieren von einem auf fünf gleichzeitige Nutzer lauten: EDB PG AI mit 2,7-facher Verlangsamung, Snowflake mit 3,9-facher, Redshift mit 4,0-facher, Databricks mit 4,1-facher. Mit anderen Worten: Die drei Cloud-Warehouses liegen bei dieser Metrik innerhalb eines 5-Prozent-Bandes, während EDB dem Feld um rund 30 bis 35 Prozent voraus liegt. William McKnights Einschätzung war bewusst zurückhaltend: Cloud-Warehouses seien weiterhin für „die anspruchsvollsten Abfragen" geeignet, sagte er, aber EDB PG AI „arbeite effizient für die Hochfrequenz-Analytik, die das Tagesgeschäft antreibt" – und er befürwortete ausdrücklich „einen hybriden Ansatz" anstelle einer vollständigen Ablösung.

EDB kombiniert den Benchmark mit einem Q1-Plattform-Release, das GPU-beschleunigte Analytik über Apache Spark plus NVIDIA cuDF (behauptete 50- bis 100-fache Beschleunigung bei Datensätzen ab 3 TB) umfasst, ein auf Langflow aufgebautes Agent Studio mit nativem MCP-Support, ein Vektor-Engine-Upgrade mit VectorChord (behauptete 100-fach schnellere Indizierung), einen neuen WarehousePG Enterprise Manager für MPP-Workloads, einen Administrations-Chatbot in natürlicher Sprache sowie die Red Hat Ansible Automation Platform-Zertifizierung mit Failover unter 30 Sekunden über Availability Zones hinweg.

Technische Analyse

Der Schwerpunkt des Benchmarks liegt auf Concurrency-Skalierung, nicht auf reiner Abfragelatenz – und diese Wahl zeigt, was EDB tatsächlich verkauft. TPC-DS bei 10 TB mit einem bis fünf gleichzeitigen Nutzern ist kein Stresstest für die elastische Skalierung eines serverlosen Warehouses. Es ist ein Stresstest für Vorhersagbarkeit unter der Art von wiederkehrenden Dashboard- und agentengesteuerten Workloads, die dasselbe Warehouse-Cluster zu überlappenden Zeiten treffen. Eine 2,7-fache Verlangsamung bei fünffacher Parallelität bedeutet, dass EDB sublinear degradiert, während Snowflakes 3,9-fache, Redshifts 4,0-fache und Databricks' 4,1-fache alle näher an einer linearen Degradation relativ zur Nutzerzahl liegen. Das ist konsistent mit dem, was man von einer Postgres-abgeleiteten MPP-Engine auf dedizierter Kapazität gegenüber Abfrage-Engines erwarten würde, die Compute-Pool-Zuteilung aushandeln müssen.

Das Preismodell ist die zweite Achse. EDB berechnet kernbasierte Kapazität, während Snowflake, Databricks und Redshift alle verbrauchsbasierte Preise auf Warehouse- oder Cluster-Größen aufsetzen. Für ein hochfrequentes Dashboard-Tier oder eine agentische Schleife, die Abfragen in einem Abfrageintervall ausgibt, macht das Verbrauchspreismodell das Abfragevolumen zu einer GuV-Variablen. Kapazitätspreise machen es zu einem Fixkostenposten. Der Vergleich von 222.886 $ gegenüber 351.953 $ ist der finanzielle Ausdruck dieses architektonischen Unterschieds bei einer bestimmten Workload-Form.

Was die Quelle nicht offenlegt und was die Interpretation wesentlich verändert: die konfigurierte Cluster-Größe für jedes System, das Storage-Tier (getrennt vs. co-located), ob Snowflake auf einem Multi-Cluster-Warehouse mit Auto-Scale-Obergrenzen oder einem festen Warehouse lief, die Aufschlüsselung des Query-Mixes innerhalb des erweiterten TPC-DS und ob Result-Caching aktiviert war. Ohne diese Angaben gilt folgende Einschränkung: Selbst wenn EDBs Vorsprung unter anderen Konfigurationen um die Hälfte schrumpft, ist ein TCO-Vorteil von 15 bis 20 Prozent auf einem dauerhaften Hochfrequenz-Tier noch vertretbar. Wenn diese Konfigurationsdetails in die andere Richtung kippen, könnte der Vorteil bei ad-hoc-abfragedominierten Workloads zusammenbrechen.

Wer betroffen ist

Die Teams, die diesem Pitch am stärksten ausgesetzt sind, sind jene, die intensive parallele BI auf Snowflake oder Databricks betreiben, bei denen das Workload-Muster vorhersehbar ist: Hunderte von Dashboards, die planmäßig aktualisiert werden, eingebettete Analytik für Endnutzer oder Agenten-Schleifen, die das Warehouse im Minutentakt aufrufen. Das sind genau die Workloads, bei denen Verbrauchspreise gegenüber Kapazitätspreisen am schlechtesten abschneiden, weil das Abfragevolumen strukturell und nicht explorativ ist. iGaming-Betreiber mit Echtzeit-Spielersegment-Dashboards, Fintechs mit Betrugserkennungs-Lookups gegen analytische Stores und AdTech-Teams mit Attribution-Aktualisierungen passen alle in dieses Profil.

Die Cloud-Warehouse-Anbieter sind nicht in unmittelbarer Gefahr. McKnight selbst sagte, dass Cloud-Warehouses bei „den anspruchsvollsten Abfragen" weiterhin die Nase vorn hätten – das bedeutet die explorative Datenwissenschaft und ad-hoc-analytische Arbeit, bei der elastisches Burst-Pricing sinnvoll ist. Die Bedrohung ist enger gefasst: Das operative Analytik-Tier, das Always-on-Segment, ist der Bereich, in dem Kapazitätspreise auf Postgres-kompatiblen MPP strukturell günstiger werden. Zu erwarten ist eine Workload-Bifurkation statt einer vollständigen Migration. CTOs, die bereits Postgres für OLTP betreiben, erhalten ein naheliegendes Erweiterungsspiel.

Das in den nächsten 90 Tagen am stärksten exponierte Team ist jenes, das die Snowflake- oder Databricks-Rechnung in einem Unternehmen verantwortet, in dem das Finanzteam begonnen hat zu fragen, warum die Analytikkosten mit der Mitarbeiterzahl multipliziert mit der Dashboard-Anzahl skalieren. Ein 37-prozentiger Dollar-Vergleich von einem namentlich genannten Drittanbieter-Analysten ist genau das Artefakt, das Einkaufsabteilungen nutzen, um eine Nachverhandlung zu erzwingen. Wir wissen nicht, welche Rabattstufen die Cloud-Warehouse-Anbieter entgegenstellen werden, aber die Grenze ist testbar: Wenn EDBs Behauptung einer unabhängigen Replikation standhält, ist damit zu rechnen, dass Snowflake-Account-Manager innerhalb von zwei Quartalen tiefere Kapazitätsbindungsrabatte anbieten.

Handlungsempfehlungen für Datenteams

Erstens: Klassifizieren Sie Ihre Warehouse-Ausgaben nach Workload-Muster, nicht nach Team. Trennen Sie das Always-on-Tier (geplante Dashboards, eingebettete Analytik, agentische Schleifen) vom explorativen Tier (Notebooks, ad-hoc-SQL, Model-Training-Feature-Pulls). Das Always-on-Tier ist der Bereich, in dem Kapazitätspreise gewinnen. Wenn dieses Tier mehr als 60 Prozent Ihrer Warehouse-Ausgaben ausmacht, haben Sie eine echte Bewertung durchzuführen – kein Beschaffungs-Bluff.

Zweitens: Replizieren Sie die Benchmark-Form auf Ihren eigenen Daten, bevor Sie die Zahlen eines Anbieters glauben – einschließlich dieser. Nehmen Sie eine repräsentative Auswahl Ihrer geplanten Abfrage-Workload, führen Sie sie mit einem Nutzer und mit fünf gleichzeitigen Nutzern auf Ihrem aktuellen Warehouse aus und messen Sie das Verlangsamungsverhältnis. Wenn Sie besser als 3,9-fach abschneiden, bilden die McKnight-Zahlen Ihre Umgebung nicht ab. Wenn Sie schlechter abschneiden, verdient EDBs Pitch einen echten Proof of Concept.

Drittens: Nehmen Sie die agentische Seite ernst. Nativer MCP-Support in EDBs Agent Studio bedeutet, dass Agenten Postgres direkt als Tool ansprechen können, was eine Übersetzungsschicht entfernt, über die die meisten aktuellen Agenten-Stacks mit Retrieval-Pipelines hinwegkommen. In Kombination mit VectorChord auf derselben Engine kollabiert das Vector-Store und den operativen Store in einem einzigen verwalteten Substrat. Das ist architektonisch interessant – unabhängig vom Benchmark.

Viertens: Ignorieren Sie die Ansible-Zertifizierung und den Failover-Anspruch unter 30 Sekunden nicht. Für regulierte Branchen, in denen das Warehouse im kritischen Pfad für Compliance-Reporting liegt, war Multi-AZ-HA auf dem analytischen Tier historisch ein individuelles Engineering-Problem. Wenn das nun eine verpackte Zertifizierung ist, verändert das die Build-versus-Buy-Kalkulation für Plattform-Teams.

Wichtigste Erkenntnisse

• EDB PG AIs 2,7-fache Concurrency-Verlangsamung übertrifft Snowflake (3,9-fach), Redshift (4,0-fach) und Databricks (4,1-fach) bei einem 10-TB-TPC-DS-Test – jedoch nur im offengelegten Bereich von ein bis fünf Nutzern.
• Der Dollar-Vergleich von 222.886 $ gegenüber 351.953 $ ist eine konfigurierte Instanz, kein universeller Anspruch – und die zugrundeliegende Cluster-Größe wird im Release nicht offengelegt.
• Kapazitätspreise schlagen Verbrauchspreise strukturell bei Always-on-Workloads; das Gegenteil gilt für burstige explorative Analytik, was McKnight ausdrücklich einräumte.
• Die Q1-Plattform-Ergänzungen (NVIDIA cuDF-Integration, Langflow-basiertes Agent Studio, VectorChord, Ansible-Zertifizierung mit Failover unter 30 Sekunden) zielen auf das agentische Workload-Tier ab und nicht auf klassisches BI.
• Testbare Vorhersage: Wenn EDBs Concurrency-Vorsprung real ist, ist davon auszugehen, dass mindestens ein großer Cloud-Warehouse-Anbieter innerhalb von zwei Quartalen ein Kapazitätsbindungs-Preistier oder eine Fixkosten-Concurrency-SKU ankündigt.