Perplexity Computer verbindet sich mit Snowflake und Databricks

Wer eine Datenplattform betreibt, kennt den echten Engpass: nicht die Rechenleistung, sondern die Analyse-Warteschlange. Der Vertrieb will Pipelinezahlen vor dem Mittagessen, die Finanzabteilung einen Umsatzschnitt bis Freitag – und ein überlasteter Analyst ist der Flaschenhals. Mit dem neuesten Schritt richtet Perplexity seinen agentischen Workspace Computer direkt auf diese Warteschlange aus, indem er ihn mit Snowflake und Databricks verbindet.

Das Versprechen ist bekannt: Nicht-technische Nutzer stellen Fragen auf Englisch, der Agent schreibt das SQL, und die Ergebnisse sind an echte Warehouse-Tabellen geknüpft. Das Interessante ist nicht das Versprechen. Es ist die Governance-Infrastruktur darunter.

Wichtige Details

Das Release positioniert Computer als Daten-Agent für Enterprise-Analysen, wie TestingCatalog AI News berichtete. Nutzer stellen Fragen über autorisierte Warehouse- und Lakehouse-Daten. Computer generiert Abfragen, liest Quelltabellen, wendet Filter an und gibt Kennzahlen zurück, die an die zugrundeliegenden Daten gebunden sind. Die Zielgruppe sind Business-, Produkt-, Vertriebs-, Finanz- und Operationsteams, die kein SQL auf Abruf schreiben können.

Die Anwendungsfälle decken die unspektakulären, aber teuren Workflows ab: Pipeline-Analysen, Produktnutzungsauswertungen, Kundensegmentierung, Umsatztrendzusammenfassungen und wiederkehrende Analyseprozesse. Das Feature wird über Perplexitys Snowflake- und Databricks-Konnektoren bereitgestellt und ist auf Pro-, Max-, Enterprise-Pro- und Enterprise-Max-Nutzer beschränkt. Admins steuern den Rollout auf Organisationsebene.

Auf der Snowflake-Seite werden Datenbanken, Schemata, Tabellen, Views, materialisierte Views und strukturierte Datenformate wie CSV, JSON und Parquet-basierte Tabellen abgedeckt. Die Snowflake-Dokumentation lohnt sich für alle, die dies gegen materialisierte Views einrichten, besonders weil das Kostenverhalten dort schnell eigenwillig wird. Auf der Databricks-Seite umfasst die Integration Unity-Catalog-Tabellen und -Views, Delta-Lake-Tabellen, Schemata, Kataloge, externe Tabellen, die im Unity Catalog registriert sind, sowie strukturierte Daten. Unstrukturierte Assets – Bilder, Audio, Video, Dateien in warehouse-spezifischem Speicher – werden in dieser Phase nicht unterstützt.

Das technische Kernstück heißt Data Map. Perplexity beschreibt es als gemeinsame organisationale semantische Schicht, die aus der Warehouse-Struktur, Tabellenbeziehungen, historischen Abfragemustern und vom Admin bereitgestelltem Geschäftskontext aufgebaut wird. Admins können die Karte prüfen und bearbeiten, aktualisieren und vorgeschlagene Änderungen auf Basis von Nutzerfeedback genehmigen. Dieser letzte Punkt ist wichtiger, als das Marketing suggeriert.

Bei der Authentifizierung unterstützt Snowflake Benutzer-OAuth, Service-Accounts mit Key-Pair-Authentifizierung oder programmatische Zugriffstoken. Databricks verwendet individuelle OAuth-Identitäten. Abfragen laufen unter bestehenden Plattformberechtigungen, sodass der Zugriff durch Snowflake RBAC oder Databricks Unity Catalog – nicht durch Perplexitys UI – kontrolliert wird. Admins können Konnektoren deaktivieren, den Zugriff verwalten und Read-only-Verhalten auf Datenplattformebene durchsetzen.

Warum das für Datenteams wichtig ist

Ohne Marketing-Sprache bleiben zwei echte Fragen für einen Plattform-Verantwortlichen: Wer besitzt die Semantik, und wer zahlt für die Abfragen?

Bei der Semantik ist Data Map die richtige Antwort. Teams, mit denen ich gearbeitet habe, sind alle an der gleichen Wand bei Text-to-SQL gescheitert: Das Modell ist technisch fähig, weiß aber nicht, dass rev_net_v3 die Tabelle ist, der die Finanzabteilung tatsächlich vertraut, und dass rev_net_v2 die ist, die Rückerstattungen stillschweigend doppelt zählt. Eine semantische Schicht mit Admin-Überprüfung, Aktualisierung und Genehmigungsablauf verhindert, dass der Agent selbstsicher falsche Zahlen liefert. Es ist dasselbe Muster, das Teams bereits in dbt aufbauen – nur dass jetzt ein LLM statt eines BI-Tools darauf zugreift.

Meine Einschätzung: Der Wert dieses Releases steht und fällt damit, wie diszipliniert Admins bei der Pflege der Data Map sind. Wer diese Arbeit überspringt, hat einen sehr teuren Weg entwickelt, plausibel aussehenden Unsinn zu erzeugen.

Bei den Kosten ist die Integration ein Thin Client auf einem Warehouse, das pro Abfrage abrechnet. Jede „schnelle Frage" eines Vertriebsmitarbeiters wird zu einem Snowflake- oder Databricks-Scan. Ich habe Produktionsvorfälle erlebt, bei denen ein einziges falsch konfiguriertes BI-Dashboard alle fünfzehn Minuten einen vollständigen Table Scan auf einer fünf Milliarden Zeilen großen Events-Tabelle ausgeführt hat – und die Monatsrechnung traf wie ein Faustschlag. Jetzt stelle man sich das vor, aber der Auslöser sind Hunderte nicht-technische Nutzer, die neugierige Fragen in eine Chat-Box tippen.

Die Gegenmaßnahmen existieren. Abfragen laufen unter Plattformberechtigungen. Admins können Read-only auf Warehouse-Ebene durchsetzen. Materialisierte Views und voraggregierte Tabellen sind nach wie vor nützlich. Aber das Budget-Gespräch wird laut sein bei jeder Organisation, die das ohne Query-Governance aktiviert. Planen Sie dafür, bevor die Beschaffung den SOW unterzeichnet, nicht danach.

Die unbequeme Wahrheit: Dieses Produkt verlagert einen bedeutenden Teil der Analysework­last von Ihrem BI-Tool zu einem Chat-Interface – und Ihre Warehouse-Rechnung wird nicht unterscheiden, welches die Abfrage ausgelöst hat.

Branchenauswirkungen

Für iGaming- und Fintech-Plattformen ist die Rechnung spezifisch. Diese Branchen betreiben bereits umfangreiche analytische Workloads gegen Warehouses für Risikobewertung, Spielersegmentierung, Betrugssignale und regulatorische Berichterstattung. Das Versprechen, einem Fraud-Ops-Lead zu erlauben, „Zeig mir Einzahlungsanomalien der letzten 48 Stunden nach Region" zu fragen, ohne einen Analysten zu benachrichtigen, ist genuinen Nutzen. Das Risiko besteht darin, dass dieselbe Abfrage, ad hoc gegen rohe Event-Tabellen ausgeführt, zehnmal so viel kostet wie die entsprechende Dashboard-Kachel gegen einen ordentlich modellierten Mart.

Für Ad-Tech ist die Lücke bei unstrukturierten Daten relevant. Kreativ-Assets, Video, Audio, Logs in warehouse-benachbartem Object Storage – das alles liegt noch nicht im Scope. Computer ist also nützlich für die Ausgaben- und Performance-Seite, weniger für die Creative-Analyse. Gut zu wissen, bevor jemand im Marketing annimmt, es deckt alles ab.

Für Enterprise-Infrastrukturteams ist die Authentifizierungsgeschichte die Schlagzeile. Service-Accounts mit Key-Pair-Auth, OAuth, programmatische Token bei Snowflake; OAuth-Identität bei Databricks; Berechtigungen durchgesetzt durch RBAC und Unity Catalog. Das ist die richtige Antwort. Es bedeutet, dass ein Sicherheitsreview dies tatsächlich genehmigen kann, ohne dass das Team ein neues Berechtigungsmodell erfinden muss. Es bedeutet auch, dass der Schadenradius eines kompromittierten Perplexity-Accounts durch das begrenzt ist, was dieser Nutzer im Warehouse ohnehin tun konnte – genau so, wie es sein soll.

Das breitere Signal ist, dass semantische Schichten zum umkämpften Terrain in der Analytik werden. dbt hat eine. Looker hat eine. Cube hat eine. Jetzt hat Perplexity eine. Wer die vertrauenswürdige Definition von „monatlich wiederkehrendem Umsatz" in Ihrem Unternehmen besitzt, besitzt den Analyse-Workflow. Das ist ein ernstzunehmender Ort, um eine Fahne zu setzen.

Was zu beobachten ist

Drei Dinge sind in den nächsten zwei Quartalen beobachtenswert.

Erstens, Query-Cost-Telemetrie. Jedes Team, das dies einführt, sollte Perplexity-originierte Abfragen in den Snowflake- oder Databricks-Nutzungsdaten separat instrumentieren und wöchentlich überprüfen. Wenn man die Quelle nicht taggen kann, kann man die Ausgaben nicht steuern. Das erste Finanzteam, das eine überraschende Warehouse-Rechnung erhält, wird das letzte sein, das das nächste KI-Tool ohne Kostenschranken genehmigt.

Zweitens, Data-Map-Drift. Vom Admin genehmigte semantische Schichten neigen dazu zu verfallen, sobald die Person, die sie aufgebaut hat, die Rolle wechselt. Beobachten Sie, ob Perplexity Versionierung, Besitzer-Metadaten und Veraltungssignale für Data-Map-Einträge hinzufügt. Ohne diese wird die Schicht in 18 Monaten zum Ladenhüter.

Drittens, die Frage unstrukturierter Daten. Derzeit liegt das außerhalb des Scopes. Wenn Perplexity dies auf Abfrageprotokolle, Support-Transkripte oder Medienmetadaten neben dem Warehouse ausweitet, wird das Produkt deutlich interessanter – und das Governance-Problem deutlich schwieriger. Für OLAP-lastige Shops, die bereits Engines wie ClickHouse für Log-Analysen evaluieren, lohnt es sich zu beobachten, ob agentische Interfaces auch auf diese Datenspeicher zugreifen.

Wichtigste Erkenntnisse

• Governance ist wirklich gut: Abfragen erben Snowflake-RBAC- und Databricks-Unity-Catalog-Berechtigungen, sodass bestehende Zugriffskontrolle weiterhin gilt.
• Data Map ist das eigentliche Produkt: Die semantische Schicht mit Admin-Überprüfung unterscheidet dies von einem generischen Text-to-SQL-Spielzeug. Pflegen Sie sie, oder überspringen Sie den Rollout.
• Budget für Warehouse-Ausgaben einplanen: Jede Chat-Abfrage ist ein abrechenbarer Scan. Taggen, überwachen und voraggregieren, bevor es einem breiten Publikum zugänglich gemacht wird.
• Unstrukturierte Daten sind außerhalb des Scopes: Bilder, Audio, Video und warehouse-benachbarte Dateien werden noch nicht unterstützt. Entsprechend planen.
• Tier-Beschränkungen sind wichtig: Nur Pro-, Max-, Enterprise-Pro- und Enterprise-Max-Nutzer erhalten Zugang, mit Admin-Kontrollen auf Organisationsebene. Beschaffung und IT müssen vor dem Pilotprojekt abgestimmt sein.