Rezension von Sigma Computing, Cloud-native BI Softwareanbieter

Zuletzt aktualisiert: Dezember, 2025

Zurück zu Marktforschung

Sigma Computing ist ein cloudbasiertes Analyse- und Business-Intelligence-(BI)-Produkt, das in erster Linie als interaktive „Tabellenkalkulations-/Arbeitsbuch“-Schicht oberhalb moderner Cloud-Datenlager konzipiert wurde, in der Endnutzer Tabellen, Pivot-Tabellen, Diagramme und Berechnungen in einer Arbeitsbuch-Benutzeroberfläche erstellen, während die rechenintensive Verarbeitung im zugrunde liegenden Datenlager (z. B. Snowflake, BigQuery, Databricks) erfolgt. Das Unternehmen positioniert das Produkt so, dass es Geschäftsbenutzern ermöglicht, direkt auf regulierten Daten im Datenlager zu arbeiten, während es gleichzeitig operative Workflows wie benutzergetriebene Schreibzugriffe in das Datenlager (via Input Tables) und durch die Benutzeroberfläche ausgelöste Automatisierungen innerhalb von Arbeitsbüchern (via Actions) unterstützt, sowie optionale „KI-unterstützte“ Funktionen, die Eingabeaufforderungen und Daten an datenlager-gehostete Modelle oder externe LLM-Anbieter unter kundenkontrollierten Integrationen weiterleiten können.

Überblick über Sigma Computing

Das Kernproduktkonzept von Sigma ist ein interaktives Arbeitsbuch, das sich wie eine Tabellenkalkulation verhält, aber über Daten im Umfang von Datenlagern arbeitet. Eine von Sigma-Ingenieuren verfasste, peer-reviewte technische Abhandlung beschreibt, wie Arbeitsbuch-Konstrukte in Datenbankabfragen übersetzt/kompiliert und im Cloud-Datenlager ausgeführt werden, anstatt in eine separate In-Memory-Engine extrahiert zu werden.¹ Diese „Pushdown“-Orientierung steht im Zentrum von Sigmas Differenzierung (und stellt auch eine wesentliche Einschränkung dar: Sigmas Fähigkeiten entsprechen dem, was durch die SQL-Semantik eines Datenlagers ausgedrückt werden kann, zuzüglich der Erweiterungen, die Sigma durch eng gefasste Funktionen wie Writeback Tables, eingebettete Python-Ausführung auf bestimmten Plattformen und Integrationen mit Drittanbieter-/Datenlager-KI-Diensten hinzufügt).

Sigma Computing vs Lokad

Sigma und Lokad bedienen grundsätzlich unterschiedliche Problembereiche. Sigma ist eine Analyse-/Arbeitsbuch-Schicht zur Erkundung, Modellierung und Operationalisierung von Erkenntnissen auf Cloud-Datenlagern; seine „Automatisierung“ und „KI“ werden am besten durch die Interaktivität im Arbeitsbuch (Actions), den kontrollierten Schreibzugriff in das Datenlager (Input Tables) und Integrationen, die Eingabeaufforderungen/Daten an datenlager-gehostete oder externe KI-Modelle unter Kundenkonfiguration weiterleiten, belegt.²³⁴ Sigmas einzig explizit belegte Prognosefähigkeit in den geprüften Quellen ist eine Schnittstelle zur Forecasting-ML-Funktion von Snowflake (d. h. die Darstellung einer Datenlager-Funktionalität über die Sigma-Benutzeroberfläche).⁵

Lokad hingegen ist explizit auf predictive optimization for supply chains ausgerichtet – probabilistische Prognosen als Grundlage für Entscheidungsoptimierung – anstatt auf allgemeine BI. Lokads eigene Materialien definieren probabilistische Prognosen in Begriffen von supply chain (Wahrscheinlichkeitsverteilungen über Ergebnisse statt Punktwerte) und stellen dies als wesentlich dar, um robuste operative Entscheidungen unter Unsicherheit zu treffen.⁶ Lokads Einordnung als “die Quantitative Supply Chain” hebt entscheidungsorientierte Ergebnisse hervor (z. B. priorisierte Entscheidungs-Dashboards und Skripte als Ergebnisse) anstatt eines analytischen Arbeitsbuchs für den allgemeinen Gebrauch.⁷ Selbst wenn man es skeptisch als vom Anbieter verfasste Darstellung behandelt, ist die Kernunterscheidung klar: Sigma ist ein BI-/Arbeitsbuch-Produkt, das in erster Linie Daten liest und analysiert (neben begrenzten Schreib-/Workflow-Anbindungen), während Lokads bezeichnete Produktabsicht darin besteht, operative Entscheidungen (Ordering, Inventory, Scheduling, Pricing) unter Unsicherheit mithilfe probabilistischer Modellierung zu berechnen und zu priorisieren.⁶⁷

Aus der Perspektive eines Käufers bedeutet dies, dass die Tools keine direkten Ersatzprodukte für supply chain optimization sind: Sigma mag verwendet werden, um supply-chain Dashboards, Szenariotabellen und eingebettete Analytics-Apps auf Datenlagern zu erstellen, aber die geprüften Belege zeigen nicht, dass Sigma die supply-chain-spezifischen prognoseoptimierenden Methoden bereitstellt, die Lokad beschreibt (probabilistische Nachfrage-/Lead-Time-Modellierung in Verbindung mit Entscheidungsoptimierung).⁶⁷ Im Gegensatz dazu versucht Lokad nicht, eine allgemeine unternehmensweite BI-Schicht für alle Abteilungen zu sein; seine Darstellung ist spezialisiert auf supply-chain Entscheidungsfindung, und seine Vergleichsseiten und sein Manifest argumentieren explizit gegen generische „Planungs“-Paradigmen.⁸⁹

Unternehmenshintergrund und Geschichte

Unternehmensidentität und früheste öffentliche Einreichungen

SEC Form D-Einreichungen deuten auf eine frühere Namensgeschichte des Unternehmens hin (z. B. erscheint „Bitmoon Computing Inc.“ in älteren Unterlagen, die mit Sigma Computing in Verbindung stehen) und liefern datierte Belege für Fundraising-Aktivitäten und das „Datum des ersten Verkaufs“ bestimmter Angebote.¹⁰¹¹ Diese Einreichungen gehören zu den wenigen primären, von Aufsichtsbehörden bereitgestellten Quellen, die für den Finanzierungszeitplan eines privaten Unternehmens verfügbar sind.

Finanzierungsrunden und Meilensteine (geprüft)

• Series C (2021): Reuters berichtete im Dezember 2021 über die Series-C-Finanzierung von Sigma und bezeichnete das Unternehmen als ein cloudbasiertes Analytics-Startup, das darauf ausgerichtet ist, Geschäftsteams die Analyse von Daten in cloudbasierten Datenlagern zu ermöglichen.¹²
• Series D (2024): Reuters berichtete, dass Sigma im Mai 2024 200M USD bei einer Bewertung von 1,5B USD aufbrachte.¹³
• Series B2 (2019): VentureBeat berichtete über eine 30M USD „Series B2“-Runde im August 2019 und stellte Sigma als eine Analytics-Plattform für cloudbasierte Datenlager dar.¹⁴

Auf der Produktseite kennzeichnen mehrere öffentliche Mitteilungen bedeutende Funktionsausweitungen:

• Input Tables writeback (2023): Eine Business Wire-Mitteilung (und syndizierte Wiederveröffentlichungen) beschreibt Input Tables als eine Funktion, die es Benutzern ermöglicht, Daten direkt über Sigma-gemanagte Tabellen in ein cloudbasiertes Datenlager zu schreiben.³
• Warehouse-integrated forecasting (2024): Sigmas Änderungsprotokoll gibt an, dass „Create time series forecasts“ es Benutzern ermöglicht, die Forecasting-ML-Funktion von Snowflake zu nutzen, ohne SQL schreiben zu müssen.⁵
• Tenant-style segmentation for embedded analytics (2025): Sigmas Blog stellt „Sigma Tenants“ als ein Governance- und Skalierungskonzept für Enterprise/embedded Analytics-Einsätze vor.¹⁵

Akquisitionsaktivitäten und unternehmensbezogene Maßnahmen

In den oben überprüften Quellen (SEC-Angebots-Einreichungen, umfassende Pressberichterstattung zu Finanzierungsrunden und Sigmas eigene Produktankündigungen) zeigt sich keine Akquisitionstätigkeit von Sigma Computing (weder als Erwerber noch als erworbenes Unternehmen). Dies ist ein negativer Befund: Das Fehlen von Beweisen ist nicht der Beweis des Fehlens, aber es ist bemerkenswert, dass wesentliche Berichterstattungen über Finanzierungen und regulatorische Einreichungen keine M&A-Ereignisse aufzeigen.¹⁰¹²¹³ Ein praktisches Risiko in dieser Forschungsrichtung ist die Namenskollision mit anderen „Sigma“-Entitäten (z. B. mit nicht verwandten „Sigma Software“-Firmen); solche Ergebnisse wurden als irrelevant betrachtet, sofern sie nicht eindeutig Sigma Computing (cloud BI) zugeordnet werden konnten und verifiziert wurden.¹³

Produkt und Architektur: Wie Sigma funktioniert (Mechanismen, nicht Slogans)

Arbeitsbuch-Kompilierung und Ausführung im Datenlager

Eine wichtige primäre technische Quelle ist das VLDB-Paper „Sigma Workbook: A Spreadsheet for Cloud Data Warehouses“, welches das Arbeitsbuch als eine tabellenkalkulationsähnliche Benutzeroberfläche beschreibt, in der benutzerdefinierte Berechnungen in Datenbankoperationen überführt werden, sodass die Ausführung im Datenlager erfolgt.¹ Dies stimmt mit Sigmas weitergehender Dokumentation überein, die besagt, dass Arbeitsbücher Live-Daten von verbundenen Plattformen verwenden und Daten integrieren können, die über Sigma-gemanagte Konstrukte (z. B. Input Tables) geschrieben wurden.¹⁶

Skeptischer Blick: Dieser architektonische Ansatz ist glaubwürdig und technisch nachvollziehbar (und ungewöhnlich gut gestützt durch ein peer-reviewtes Systems-Forum für ein Enterprise-BI-Produkt). Er impliziert jedoch auch, dass viele „fortgeschrittene“ Verhaltensweisen in der Praxis Orchestrierungen von Datenlager-Fähigkeiten (SQL-Engines, ML-Funktionen des Datenlagers, plattformbezogene Python-Runtimes) sind, wobei Sigma die benutzerseitige Autorenschicht, Funktionen zur Rückverfolgbarkeit/Governance und die Workflow-Verknüpfung bereitstellt.

Writeback und „operational BI“: Input Tables

Sigmas „Input Tables“ werden als Arbeitsbuch-Elemente dokumentiert, die eine strukturierte Dateneingabe unterstützen und die Daten im Datenlager erweitern können, ohne die Quelltabellen zu überschreiben, wodurch Was-wäre-wenn-Analysen, Prototyping und verwandte Szenarien ermöglicht werden.¹⁷ Eine Pressemitteilung aus dem Jahr 2023 ist deutlicher: Input Tables erstellen Sigma-gemanagte Tabellen im cloudbasierten Datenlager des Kunden, die über getippte Eingaben, Dropdown-Menüs und Einfügeoperationen befüllt werden.³ Dies ist eine nicht triviale Funktion, da sie von einer rein lesenden BI in einen kontrollierten Writeback übergeht. Die Beweislücke: Öffentliche Quellen liefern keine detaillierten Informationen zu Transaktionssemantik, Konkurrenzsteuerung, Audit-Logging, Rollback oder Konfliktlösung über die hochgradige Beschreibung „Sigma-gemanagte Tabellen in Ihrem Datenlager“ hinaus.³¹⁷ Für regulierte Umgebungen wären diese fehlenden Details wesentlich, um die betriebliche Sicherheit zu validieren.

Workflow-Automatisierung innerhalb von Arbeitsbüchern: Actions

Sigmas Dokumentation definiert „Actions“ als benutzerkonfigurierte Interaktivität, bestehend aus Bedingungen, Auslösern und Effekten, die Sequenzen mehrerer Aktionen unterstützt.² Dies kommt eher einem leichtgewichtigen Anwendungs-/Workflow-Builder als klassischem Dashboarding nahe. Dennoch ist es (laut den öffentlichen Dokumenten) kein allgemeiner Orchestrierungsmechanismus: Es handelt sich um ereignis-/triggerbasierte Logik im Umfang des Arbeitsbuchs, die zwar leistungsfähig für eingebettete Analytics-UX sein kann, jedoch nicht mit unternehmensgerechter Prozessautomatisierung mit langlebigen Warteschlangen, compensierenden Transaktionen und formalen SLAs vergleichbar ist.²

Eingebettete Python-Ausführung (plattformbezogen)

Sigmas Dokumentation beschreibt ein „Python element“, in dem Code im Kontext der Datenplattform des Kunden ausgeführt wird (mit unterschiedlichem Verhalten für Databricks versus Snowflake) und über Actions ausgelöst werden kann.¹⁸ Dies ist bedeutsam, da es Sigma über reines SQL-Pushdown hinaus erweitert – bleibt jedoch stark abhängig vom Ausführungsmodell, den Berechtigungen und der Paketverfügbarkeit der verbundenen Plattform.¹⁸

KI / ML / „Optimierung“ Ansprüche: Was ist belegt?

Forecasting: Explizite Abhängigkeit von Snowflakes ML-Funktion

Sigmas eigenes Änderungsprotokoll besagt, dass die Zeitreihenprognose in Sigma es den Nutzern ermöglicht, Snowflakes Forecasting-ML-Funktion zu nutzen, ohne dass vorher SQL-Kenntnisse erforderlich sind.⁵ Dies ist ein klares Beispiel dafür, dass Sigma eine zugrunde liegende ML-Grundfunktion des Datenlagers als Produkt aufbereitet. Technisch ist dies glaubwürdig und nützlich; es ist jedoch kein Beleg für eine proprietäre Prognose-Engine, die von Sigma entwickelt wurde.

„KI-unterstützte Funktionen“: Integration und Routing, kein offengelegtes Inhouse-Modell

Sigmas “Notice for enabling AI-enabled features” ist für Unternehmenssoftware-Dokumentation ungewöhnlich offen: Sie besagt, dass die Aktivierung von KI-Funktionen dazu führen kann, dass “Input Data, Prompts, Customer Data, and User Information” an eine Drittanbieteranwendung (z. B. OpenAI/Azure OpenAI) weitergeleitet wird, abhängig von der Konfiguration, und warnt ausdrücklich, dass die Ausgaben ungenau, voreingenommen sein und einer manuellen Überprüfung bedürfen.⁴ Die gleiche Mitteilung unterscheidet zwischen:

• Warehouse AI Models (Modelle, die vom verbundenen Datenlager “gehostet oder ausgeführt” werden), und
• External AI Models (extern gehostete Anbieter unter den API-Zugangsdaten des Kunden).⁴

Sigmas Dokumentation “Manage external AI integrations” stellt diese KI-Fähigkeiten als unterstützende Funktionen dar, wie z. B. “Ask Sigma”, Diagramm-Erklärungen und ein Formelassistent, und beschreibt sie als eine Integration eines externen Modells anstelle eines von Sigma trainierten Modells.¹⁹

Skeptische Schlussfolgerung: Die öffentlich dokumentierte KI-Oberfläche ist am besten zu verstehen als (1) UI-/Assistenzfunktionen, die von Drittanbieter-/Datenlager-Modellen unterstützt werden, und (2) die Integration von ML-Funktionen des Datenlagers (z. B. Forecasting) in die Arbeitsbuch-Erfahrung. Die geprüften öffentlichen Quellen belegen nicht, dass Sigma einen neuartigen, proprietären LLM oder eine originelle Optimierungs-Engine betreibt, die mit Operations-Research-Solvern vergleichbar wäre; die “KI”‑Behauptungen sind in erster Linie Integrations- und Benutzererfahrungsschichten über externen/datenlagerbasierten Fähigkeiten.⁵⁴¹⁹

Technische Hinweise: Stack und Bereitstellungsorientierung

Eine Sigma-Stellenausschreibung im Engineering verweist auf einen modernen cloud-nativen Stack, der Rust und Go, GraphQL, Node und Kubernetes umfasst.²⁰ Dies ist konsistent mit einer SaaS-BI-Steuerebene, die Multi-Mandanten-Metadaten, Authentifizierung, Abfrageplanung/-orchestrierung und eine umfangreiche Web-UI verwalten muss. Das technische Paper bestätigt, dass die zentrale Herausforderung des Produkts in der Kompilierung/Übersetzung von Arbeitsbuch-Semantiken in Datenlager-Abfragen und in der interaktiven Performance über große Datensätze liegt.¹

Bereitstellungs- und Rollout-Modell (evidenzbasiert, nicht angenommen)

Sigmas Dokumentation betont, dass Arbeitsbücher Live-Daten von verbundenen Plattformen nutzen und Daten integrieren können, die über Sigma-gemanagte Konstrukte (wie Input Tables) erstellt wurden.¹⁶ Praktisch deutet dies auf ein Bereitstellungsmodell hin, bei dem:

1. Ein Unternehmen Sigma mit seinen cloudbasierten Datenplattformen (warehouse/lakehouse) verbindet,
2. regulierten semantischen Inhalt (Tabellen/Modelle/Arbeitsbücher) in Sigma erstellt,
3. optional kontrollierte Writeback-Tabellen und Arbeitsbuch-Automatisierung aktiviert,
4. optional KI-Anbieter (datenlager-gehostet oder extern) konfiguriert.¹⁶¹⁷²⁴

Öffentliche Dokumentationen liefern nicht genügend Details, um Implementierungsmethoden rigoros zu vergleichen (z. B. typische Projektphasen, Zeitpläne oder Change-Management-Muster), wie es supply-chain planning Anbieter oft durch umfangreiche Fallstudien tun. Sigma veröffentlicht zwar Produkteinführungsgeschichten und kundenzentrierte Inhalte, aber diese sind nicht gleichzusetzen mit technischen Bereitstellungs-Runbooks oder geprüften Implementierungs-Postmortems.¹⁵

Benannte Kunden und Fallstudien: Stärke der Belege

Sigmas öffentliche Produktseiten und Einführungsmaterialien liefern einige Verweise auf benannte Kunden (z. B. besagt eine Seite „Product Launch Fall 2025“, dass Tenants von Duolingo und Built genutzt wird).²¹ Reuters berichtete in Zusammenhang mit Sigmas Finanzierungsrunde 2024 ebenfalls über benannte Kunden (z. B. DoorDash und Blackstone) in der Presseberichterstattung.¹³

Für die technische Validierung wären jedoch detaillierte, extern verifizierte Fallstudien, die Folgendes beschreiben, der stärkste Beleg:

• Datenmengen und Performance,
• Governance-/Sicherheitskontrollen,
• operative Workflow-Ergebnisse,
• messbare Geschäftsauswirkungen, und
• Ausfallmodi und Gegenmaßnahmen.

Innerhalb der hier geprüften Quellen sind solche tiefgehenden, unabhängig verfassten Fallstudien begrenzt. Sigmas eigene Ankündigungen und Blogs sind informativ, bleiben jedoch vom Anbieter verfasst und sollten entsprechend gewichtet werden.³¹⁵²¹

Fazit

Sigma Computing zeigt sich am besten als cloud-native BI-/Analytics-Plattform, optimiert für Cloud-Datenlager, mit ungewöhnlich starker öffentlicher technischer Untermauerung für sein Workbook-to-Warehouse-Ausführungsmodell anhand eines begutachteten Systempapiers.¹ Sein Produkt hat sich über passive Analysen hinaus erweitert zu kontrolliertem Writeback (Input Tables), werkbuchbezogener Workflow-Interaktivität (Actions) und optionalen KI-Unterstützungsfunktionen, die über warehouse-gehostete oder externe Modelle bei kundenseitiger Konfiguration geleitet werden.³²⁴ Die am besten verteidigbare Interpretation von Sigmas „AI/ML“-Haltung, basierend auf der geprüften Dokumentation, ist, dass Sigma die ML- und LLM-Fähigkeiten von Drittanbietern/warehouse produktisiert, anstatt eine proprietäre Prognose-/Optimierungs-Engine offenzulegen.⁵⁴¹⁹

Kommerziell erscheint Sigma gut kapitalisiert und etabliert im Cloud-Daten-Stack-Ökosystem, mit großen Finanzierungsrunden, die von Reuters berichtet werden, und mehreren namentlich genannten Unternehmenskunden, auf die in der Presse und in Sigmas eigenen Materialien verwiesen wird.¹²¹³²¹ Allerdings sollte Sigma (basierend auf den hier vorliegenden Beweisen) nicht als supply chain optimization vendor charakterisiert werden; jeglicher supply chain value wäre indirekt – über Analysen und operative Berichterstattung/Workflows auf Basis von warehouse-Daten – es sei denn, ein Käufer baut (oder integriert) spezialisierte Prognose-/Optimierungssysteme parallel zu Sigma.

Quellen