Auf der Unbound hat HubSpot HubSQL angekündigt – eine eigene SQL-Sprache innerhalb der Plattform. Von allen Ankündigungen ist das die, die im Arbeitsalltag vermutlich am meisten verändert. Nicht weil sie spektakulär aussieht, sondern weil sie an einer Stelle ansetzt, an der fast jedes gewachsene Portal irgendwann hängenbleibt: der Auswertung großer Datenmengen.
Der typische Verlauf sieht so aus: Ein Unternehmen startet mit HubSpot, die Standard-Reports reichen. Nach zwei Jahren liegen mehrere hunderttausend Kontakte, Deals über mehrere Pipelines und eigene Objekte im Portal. Die Fragen werden komplexer – Kohortenbetrachtungen, Attribution über mehrere Touchpoints, Verknüpfungen zwischen Objekten, die der Report Builder so nicht abbildet.
Ab diesem Punkt gab es bisher im Wesentlichen zwei Wege. Entweder man hat die Frage so lange vereinfacht, bis sie in den Custom Report Builder passte. Oder man hat die Daten exportiert und in ein externes Data Warehouse gespiegelt, dort ausgewertet und die Ergebnisse zurückgespielt. Der erste Weg kostet Erkenntnis, der zweite kostet Budget, Zeit und eine zusätzliche Fehlerquelle in der Synchronisation.
HubSQL setzt genau dazwischen an: Abfragen in SQL-Syntax, direkt auf den Daten im Portal, ohne sie vorher irgendwohin zu bewegen.
Wer schon einmal SQL geschrieben hat, kennt den Unterschied zwischen einem Report-Baukasten und einer Abfragesprache. Der Baukasten gibt vor, welche Fragen stellbar sind. Eine Abfragesprache gibt vor, wie man fragt – was man fragt, bleibt offen. Das ist der eigentliche Gewinn.
Konkret heißt das: Verknüpfungen über mehrere Objekte hinweg, Aggregationen, die im Report Builder nicht vorgesehen sind, und Auswertungen, die man vorher überhaupt nicht formulieren konnte, ohne die Daten zu exportieren.
Wichtig zur Einordnung: Das ist kein Feature für das Marketing-Team im Tagesgeschäft. HubSQL richtet sich an Menschen, die mit Daten arbeiten – RevOps, Analytics, technisch versierte Admins. Wer bisher keine SQL-Kenntnisse im Haus hat, gewinnt durch die Ankündigung erst einmal nichts.
Die drei Ebenen konkurrieren nicht, sie stapeln sich. Wer HubSQL als Ersatz für den Report Builder versteht, baut sich unnötige Abhängigkeit von einer einzelnen Person auf.
HubSQL macht das Warehouse nicht überflüssig. Es verschiebt nur die Schwelle, ab der sich eines lohnt. Weiterhin klar für ein externes Warehouse spricht:
Die ehrliche Kurzfassung: HubSQL ist stark für alles, was innerhalb von HubSpot passiert. Sobald die Frage das Portal verlässt, bleibt das Warehouse die Antwort.
Die Ankündigung ist noch frisch, Details zu Verfügbarkeit und Lizenzierung solltet ihr direkt bei HubSpot prüfen. Unabhängig davon gibt es zwei Dinge, die sich jetzt schon lohnen – und die ohnehin überfällig sind.
Erstens: Datenqualität. Eine Abfragesprache macht schlechte Daten nicht besser, sie macht sie nur schneller sichtbar. Doppelte Datensätze, uneinheitlich gepflegte Auswahlfelder und verwaiste Properties führen zu Ergebnissen, die technisch korrekt und fachlich falsch sind. Wer HubSQL produktiv nutzen will, sollte vorher aufräumen.
Zweitens: die offenen Fragen sammeln. In den meisten Teams gibt es eine stille Liste von Auswertungen, die man mal gebraucht hätte und dann aufgegeben hat, weil es nicht ging. Genau diese Liste ist der Testfall. Schreibt sie auf, bevor ihr über Werkzeuge redet.
HubSQL ist die Ankündigung mit der längsten Halbwertszeit aus diesem Unbound-Jahrgang. Agenten und neue Oberflächen verändern sich schnell wieder – eine Abfrageebene auf den eigenen Daten bleibt. Für Unternehmen, die bisher zwischen „reicht nicht" und „zu teuer" feststeckten, schließt sie eine echte Lücke.
Gleichzeitig gilt: Der Nutzen hängt vollständig daran, ob im Haus jemand ist, der die Fragen stellen kann. Die Technik ist die kleinere Hälfte.
HubSQL ist eine von HubSpot angekündigte SQL-Sprache, mit der sich Daten direkt innerhalb der Plattform abfragen lassen. Ziel ist die Auswertung großer Datenmengen, ohne die Daten vorher in ein separates Data Warehouse zu übertragen.
Nein. Der Custom Report Builder deckt weiterhin den größten Teil der individuellen Auswertungen ab und ist für alle Nutzerinnen und Nutzer bedienbar. HubSQL setzt darunter an – für Fragestellungen, die der Builder strukturell nicht abbilden kann, und für Datenmengen, bei denen er an Grenzen stößt.
In vielen Fällen ja. Ein externes Data Warehouse bleibt die bessere Wahl, wenn Daten aus mehreren Systemen zusammengeführt werden, wenn Zustände über die Zeit historisiert werden müssen, wenn bereits eine BI-Landschaft wie Power BI oder Looker besteht oder wenn hohe Governance-Anforderungen gelten. HubSQL verschiebt die Schwelle, ab der sich ein Warehouse lohnt, hebt sie aber nicht auf.
HubSQL richtet sich an Personen, die regelmäßig mit Daten arbeiten – typischerweise RevOps, Analytics oder technisch versierte HubSpot-Admins. Ohne SQL-Kenntnisse im Haus entsteht durch das Feature zunächst kein unmittelbarer Nutzen.
Vor allem die Datenqualität. Eine Abfragesprache macht schlechte Daten nicht besser, sondern macht sie schneller sichtbar. Dubletten, uneinheitlich gepflegte Auswahlfelder und verwaiste Properties führen zu Ergebnissen, die technisch korrekt und fachlich falsch sind. Sinnvoll ist außerdem, vorab die Auswertungen zu sammeln, die bisher an den Grenzen der Standard-Reports gescheitert sind.