Snowflake Cortex Search: Überblick, Preise & Kostenmonitoring

Cortex Search von Snowflake ist ein vollständig verwalteter, hybrider Suchdienst, der Vektor-, Keyword- und semantische Suche vereint. Er ist auf RAG-Anwendungen (Retrieval Augmented Generation) und Enterprise-Search-Szenarien ausgelegt – Snowflake kümmert sich im Hintergrund um Embedding, Indexing und die Serving-Infrastruktur. Während die klassische Keyword-Suche nach exakten Begriffen sucht, wertet Cortex Search die semantische Bedeutung eines Suchmusters innerhalb von Textdaten aus. So lässt sich eine Customer-Service-Datenbank nach "billing problems" durchsuchen und liefert sämtliche Tickets rund um Abrechnungsthemen – selbst dann, wenn dieser Wortlaut im Text gar nicht auftaucht.

Unsere Kunden setzen Cortex Search inzwischen umfassend ein, und eine der häufigsten Fragen lautet: "Wie behalte ich im Blick, was mich das eigentlich kostet?"

Die Herausforderung: Die Kostenstruktur von Cortex Search ist komplexer als bei klassischen Snowflake-Diensten. Anders als bei einem einfachen Warehouse, das Sie nach Bedarf hoch- und wieder herunterfahren, laufen bei Cortex Search mehrere Kostenkomponenten parallel. Ohne sauberes Monitoring kann die Rechnung schnell unangenehm hoch ausfallen.

Schauen wir uns zunächst an, wie Cortex Search funktioniert, und gehen anschließend die Abrechnungskomponenten und das Monitoring durch.

Unter der Haube kombiniert Cortex Search Vektorsuche (auf Basis der Arctic-Embed-Modelle von Snowflake), Keyword-Suche und semantisches Reranking, um hochrelevante Ergebnisse zu liefern. Sobald Sie einen Service anlegen, übernimmt Snowflake automatisch das Erzeugen der Embeddings, das Indexing und die Serving-Infrastruktur – Ihre Quelldaten werden so aufbereitet, dass sie mit niedriger Latenz ausgeliefert werden können.

Ein praktisches Beispiel für das Aufsetzen und Nutzen von Cortex Search für Support-Tickets:

-- 1. Create sample data table
CREATE OR REPLACE TABLE support_transcripts (
    transcript_text VARCHAR,
    region VARCHAR,
    agent_id VARCHAR
);

INSERT INTO support_transcripts VALUES
    ('My internet has been down since yesterday, can you help?', 'North America', 'AG1001'),
    ('I was overcharged for my last bill, need an explanation.', 'Europe', 'AG1002'),
    ('How do I reset my password? The email link is not working.', 'Asia', 'AG1003'),
    ('I received a faulty router, can I get it replaced?', 'North America', 'AG1004');

-- 2. Create the Cortex Search service
CREATE OR REPLACE CORTEX SEARCH SERVICE transcript_search_service

Code ausklappen

Wie Sie sehen, überlassen wir es der KI, "Billing problems" zu interpretieren und die passenden Zeilen zurückzugeben.

Die Funktion SEARCH_PREVIEW liefert JSON-Ergebnisse, die für jeden Treffer einen Relevance Score enthalten. Mit PARSE_JSON und FLATTEN erhalten Sie eine saubere tabellarische Ausgabe, die zeigt, welche Transkripte am besten zu Ihrer Abfrage passen – samt Metadaten und Confidence Scores. So lassen sich Suchergebnisse mühelos in Anwendungen oder weitere SQL-Analysen einbinden.

Filter auf Metadaten-Spalten wie Region oder Zeitraum sind ebenfalls möglich – ideal, wenn Sie semantisches Verständnis und strukturierte Filterung kombinieren möchten:

-- Filter results by region
SELECT SNOWFLAKE.CORTEX.SEARCH_PREVIEW(
    'transcript_search_service',
    '{
        "query": "password reset problems",
        "columns": ["transcript_text", "region", "agent_id"],
        "filter": {"@eq": {"region": "Asia"}},
        "limit": 10
    }'
);

Cortex Search hat 5 Preiskomponenten:

1. Serving Compute: 6,3 Credits pro GB/Monat an indexierten Daten (läuft durchgehend – egal, ob Sie gerade Abfragen ausführen oder nicht)
2. Embedding-Tokens: Kosten pro Million Token an Text in den Suchspalten während der Indexierung. Das hängt vom verwendeten Modell ab. Die Kosten der einzelnen Modelle finden Sie in der Snowflake Credit Consumption Table. Beispielpreise mit Stand September 2025:
3. snowflake-arctic-embed-l-v2.0: 0,05 Credits pro Million Tokens. Das ist einer der günstigsten KI-Dienste bei Snowflake!
4. Warehouse Compute: Standard-Warehouse-Tarife für das Materialisieren und Aktualisieren der Suchdaten sowie für die Ausführung von Queries
5. Storage: Für Suchindizes fallen Speichergebühren zu Ihrem Standard-Storage-Tarif an (z. B. 23 USD/TB/Monat)
6. Cloud Services: In der Regel kostenfrei (Berechnung nur, wenn >10 % der täglichen Warehouse-Nutzung)

Praxisbeispiel: 10 Millionen Support-Tickets mit durchschnittlich 500 Tokens je Ticket, Embedding-Modell zu 0,32 Credits pro Million Tokens:

• Tokens insgesamt: 10 Millionen Zeilen × 500 Tokens = 5 Milliarden Tokens
• Embedding-Kosten: 5 Milliarden Tokens ÷ 1 Million × 0,05 Credits = 250 Credits für die initiale Indexierung
  • Bei 3 USD/Credit sind das 750 USD
• Plus laufendes Serving: Bei einem 50-GB-Index entspricht das 50 × 6,3 = 315 Credits/Monat allein für den laufenden Betrieb
  • 945 USD bei 3 USD/Credit.

Anders als Warehouses, die Sie pausieren können, laufen die Serving-Kosten von Cortex Search durchgehend mit. Ein 100-GB-Index kostet 630 Credits pro Monat (rund 1.890 USD bei 3 USD/Credit) – unabhängig vom Query-Volumen. Sie zahlen das auch dann, wenn niemand sucht.

Kosten und Nutzung von Cortex Search überwachen

Snowflake stellt im Schema ACCOUNT_USAGE zwei spezielle Views für das Tracking der Cortex-Search-Kosten bereit. Die View CORTEX_SEARCH_DAILY_USAGE_HISTORY schlüsselt die täglichen Kosten nach Verbrauchstyp auf (Serving vs. Embedding), während CORTEX_SEARCH_SERVING_USAGE_HISTORY stündliche Details zu den Serving-Credits liefert – ideal, um Nutzungsmuster zu erkennen.

Tagesbeispiel:

-- Daily usage including serving and embedding costs
SELECT
    USAGE_DATE,
    DATABASE_NAME,
    SCHEMA_NAME,
    SERVICE_NAME,
    CONSUMPTION_TYPE,
    CREDITS,
    MODEL_NAME,
    TOKENS
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_SEARCH_DAILY_USAGE_HISTORY
WHERE USAGE_DATE >= CURRENT_DATE - 30
ORDER BY USAGE_DATE DESC, SERVICE_NAME, CONSUMPTION_TYPE;

Eine zentrale Ausgabe ist die Spalte consuption_type, die entweder embed_text_tokens oder serving enthält.

Stundenbeispiel:

-- Hourly serving credit consumption
SELECT
    START_TIME,
    DATABASE_NAME,
    SCHEMA_NAME,
    SERVICE_NAME,
    CREDITS as hourly_serving_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_SEARCH_SERVING_USAGE_HISTORY
WHERE START_TIME >= DATEADD('day', -7, CURRENT_TIMESTAMP())
ORDER BY START_TIME DESC, SERVICE_NAME;

Das ist, wie Sie sehen, eine sehr einfache Aggregation der Credits pro Stunde.

Aus der Arbeit mit Teams, die ein Kostenmonitoring für Cortex Search eingeführt haben, hier meine wichtigsten Empfehlungen:

Alerts einrichten – nicht nur Dashboards

Die oben gezeigten Monitoring-Queries bringen wenig, wenn niemand sie ausführt. Alles, was Sie in Snowflake überwachen möchten, lässt sich als SQL in einem geplanten Task mit Notification Integration verpacken – so entsteht ein eigener Monitor, der Alerts an Slack oder Teams sendet. Wenn Sie es besonders unkompliziert wollen, werfen Sie einen Blick auf die Monitors in SELECT.

Services während der Entwicklung pausieren

Anders als Warehouses, die sich automatisch suspendieren lassen, erzeugen Cortex-Search-Services rund um die Uhr Serving-Kosten. Pausieren Sie Ihre Such-Services während Entwicklung und Tests, wenn sie gerade nicht aktiv gebraucht werden. Sie sind in Minuten wieder einsatzbereit, aber die laufenden Serving-Kosten summieren sich rasch.

Indizes mit Bedacht dimensionieren

Jede Spalte, die Sie in Ihren Such-Service aufnehmen – egal ob durchsuchbar oder nur als Attribut –, erhöht Ihre Serving-Kosten. Nehmen Sie keine Spalten "auf Vorrat" mit auf. Starten Sie minimal und ergänzen Sie Spalten erst, wenn Sie sie wirklich brauchen. Der Kostenunterschied zwischen einem 10-GB- und einem 100-GB-Index ist beträchtlich.

Kosten des Embedding-Modells separat überwachen

Behalten Sie die Spalte CONSUMPTION_TYPE in der Daily-Usage-View im Auge, um Serving- und Embedding-Kosten getrennt zu sehen. Ausschläge beim Embedding sind oft ein Hinweis auf ineffiziente Refresh-Muster oder unnötige Komplett-Neuberechnungen. Sind die Embedding-Kosten dauerhaft hoch, lohnt sich ein Blick auf Ihre Daten-Update-Muster.

Ihre Cortex-Search-Services optimieren

Die Suchkosten hängen stark davon ab, wie der Service konfiguriert ist. Diese Leitlinien helfen:

Passende Target Lags wählen. Wenn sich Ihre Dokumente nicht häufig ändern, nutzen Sie längere Refresh-Intervalle:

-- For static documentation
CREATE CORTEX SEARCH SERVICE product_docs_search
  ON document_text
  TARGET_LAG = '24 hours'  -- Instead of default 1 hour
  ...

Suchbereich nach Möglichkeit einschränken. Wenn Agents nur aktuelle Dokumente brauchen, setzen Sie Filter:

CREATE CORTEX SEARCH SERVICE support_tickets_search
  ON ticket_text
  ATTRIBUTES customer_id, ticket_date, severity
  WHERE ticket_date >= DATEADD(year, -1, CURRENT_DATE())
  ...

Primary Keys für inkrementelle Updates nutzen

Wenn sich Ihre Daten häufig ändern, definieren Sie Primary Keys für Ihren Such-Service. Das ermöglicht optimierte Refresh-Pfade, die sowohl Embedding-Kosten als auch Refresh-Zeiten deutlich senken. Ohne Primary Keys löst jede Schemaänderung ein vollständiges Neu-Embedding des gesamten Datensatzes aus.

-- With primary key - only changed rows get re-embedded
CREATE OR REPLACE CORTEX SEARCH SERVICE support_tickets_search
    ON ticket_description
    PRIMARY KEY (ticket_id)  -- Must be TEXT data type
    ATTRIBUTES status, priority, created_date
    WAREHOUSE = search_wh
    TARGET_LAG = '1 hour'
    AS (
        SELECT ticket_id, ticket_description, status, priority, created_date
        FROM support_tickets
    );

Wie bei jedem Kostenmonitoring in Snowflake stützen wir uns auf das Schema ACCOUNT_USAGE, um die Cortex-Search-Ausgaben im Griff zu behalten. Nutzen Sie die oben gezeigten Monitoring-Queries als Ausgangspunkt, um festzulegen, was Sie überwachen wollen, und planen Sie anschließend Alerts oder wöchentliche Reports ein. Achten Sie auf Ausschläge bei den Serving-Credits (höheres Query-Volumen) und auf Embedding-Kosten während Daten-Refreshes.

Ziel ist nicht immer, die Kosten zu minimieren – Ziel ist, aus den Ausgaben einen echten Nutzen zu ziehen. Wer diese Muster versteht, optimiert Performance und Budget gleichermaßen.

Wenn Sie Cortex Search einführen, melden Sie sich gern. Ich bin gespannt, welche Monitoring-Ansätze in Ihrem Team funktionieren.

Jeff ist Data- and Analytics-Consultant mit über 15 Jahren Erfahrung darin, Insights zu automatisieren und Geschäftsprozesse datengetrieben zu steuern. Technologisch liegt sein Schwerpunkt auf Snowflake + dbt + Tableau. Inhaltlich kennt er sich in Versorgungswirtschaft, klinischen Studien, Publishing, CPG und Fertigung aus. Erreichbar jederzeit unter [email protected].