Redis mit RediSearch: Vektor-Index im KV-Store für niedrige Latenz

Was ist Redis mit RediSearch?

Redis ist ein In-Memory-Key-Value-Store, der seit 2009 als Standard-Tool für Caching, Session-Storage, Rate-Limiting und Pub/Sub etabliert ist. RediSearch ist ein optionales Modul von Redis Ltd. (früher Redis Labs), das Volltext-Suche, geospatial Indexing und seit Version 2.4 (2022) Vektor-Suche per HNSW oder FLAT hinzufügt. Stand Mai 2026 ist RediSearch 2.8 aktuell, mit verbesserter HNSW-Performance und Multi-Vektor-Support pro Hash/JSON-Eintrag.

Die Lizenz-Situation ist seit 2024 unterschiedlich nach Variante. Redis Open Source bis Version 7.2 lief unter BSD; seit Version 7.4 ist Redis OS unter der dualen RSALv2/SSPL-Lizenz – eine Quell-offene, aber nicht mehr OSI-konforme Lizenz, die Cloud-Anbieter-Verwendung einschränkt. Self-Hosting innerhalb einer Anwaltskanzlei oder Treuhand ist davon nicht betroffen; ein SaaS-Repackaging von Redis ist es. Das offene Fork Valkey (Linux Foundation, seit 2024) ist eine Alternative; RediSearch läuft jedoch primär auf Redis OS.

Die Architektur ist In-Memory mit optionaler Persistenz (RDB-Snapshots, AOF-Append-Only-File). Eine Redis-Instanz hat typischerweise mehrere GB RAM; bei Vektor-Suche kommt der Vektor-Index als zusätzlicher RAM-Verbraucher dazu. Sharding via Redis Cluster ist möglich; RediSearch-Indizes lassen sich über Shards verteilen.

Das Cloud-Angebot Redis Cloud bietet EU-Regionen (Ireland, Frankfurt) und SOC2-Compliance. Self-Hosted läuft auf jeder Plattform – Hetzner, AWS, eigene Server.

Im CH-Treuhand-Kontext fällt Redis mit RediSearch in ein klares Profil: ergänzendes Werkzeug, wenn Redis bereits als Cache oder Session-Store läuft. Eine Vektor-Suche im selben Redis spart einen separaten Service. Wer ohne Redis-Setup startet und nur Vektor-Suche braucht, ist mit Qdrant oder Weaviate besser bedient – die Spezialisierung der dedizierten Vektor-DBs ist hier ein Vorteil.

Warum es wichtig ist

Treuhand- und KMU-Stacks haben Redis häufig als Cache oder Session-Store in Betrieb – Bexio-Plugins, Workflow-Tools, eigene Web-Apps. Wenn die Vektor-Last gering ist (z.B. eine interne Wissensbasis mit 50.000 Einträgen) und Redis bereits läuft, kann RediSearch eine zweite Datenbank vermeiden. Das Argument ist analog zu pgvector vs Qdrant: keine zweite DB, kein zweites Backup, kein zweites Monitoring.

Drei Eigenschaften machen Redis mit RediSearch für dieses Profil interessant. Erstens: Latenz. In-Memory-Suche liefert typisch unter 5 ms, oft unter 1 ms. Für Real-Time-Use-Cases – Live-Empfehlung, autocomplete mit Embedding-Hits, sub-10ms-RAG-Lookup – ist Redis schneller als jede andere Vektor-DB. Qdrant und Weaviate liegen bei 10-30 ms, pgvector bei 20-50 ms, Pinecone bei 30-80 ms (Cloud-Roundtrip).

Zweitens: Hybrid mit klassischen Redis-Features. Ein Vektor-Hit kann in derselben Pipeline mit Pub/Sub-Nachrichten, Rate-Limits, Counters oder Set-Operationen kombiniert werden. Für Empfehlungs-Systeme mit Echtzeit-Personalisierung sind diese Bausteine bereits vorhanden – kein Adapter zwischen Vektor-DB und Cache nötig.

Drittens: Operatives Verständnis. Wer Redis seit Jahren betreibt, weiss Backups, Failover, RBAC, Cluster-Mode. RediSearch erbt diese Werkzeuge. Eine zusätzliche Lernkurve für eine spezialisierte Vektor-DB entfällt.

Gegenargumente: RediSearch ist als Modul jünger als die Kern-Redis-Features; manche Vektor-spezifische Features (z.B. Multi-Vektor pro Eintrag mit unabhängigen Such-Konfigurationen, hybride BM25+Dense in einer Anfrage) sind weniger ausgereift als bei Qdrant oder Weaviate. Wer Vektor-Suche als Hauptzweck betreibt, hat dort die ausgereiftere Plattform.

Lizenz-Frage: SSPL/RSALv2 ist für interne Treuhand-Nutzung kein Problem. Für SaaS-Produkte, die Redis als Datenbank-Komponente weiterverkaufen, ist eine Lizenz-Prüfung nötig.

Wie es funktioniert

Installation: RediSearch ist in Redis Stack enthalten – eine Distribution, die Redis OS plus RediSearch, RedisJSON, RedisGraph und andere Module bündelt. Docker: docker run -p 6379:6379 redis/redis-stack-server. Self-Hosting via APT/YUM mit den Redis-Stack-Paketen.

Index anlegen via FT.CREATE – der RediSearch-Kommando-Präfix: FT.CREATE docs_idx ON HASH PREFIX 1 doc: SCHEMA mandant TAG datum TEXT content TEXT embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 1536 DISTANCE_METRIC COSINE

Das erstellt einen Index auf alle Hashes mit Präfix doc:; die Felder mandant, datum, content und embedding werden indexiert, embedding mit HNSW-Vektor-Index, Dimension 1536, Cosine-Distanz.

Upsert via HSET: HSET doc:1 mandant 42 datum "2026-04-01" content "Rechnung Müller" embedding <binary_blob>

Embedding wird als Binary-Blob im Float32-Format geschrieben – typisch via SDK (redis-py, ioredis, lettuce). Die Python-Variante: import redis import numpy as np r = redis.Redis() emb = np.array([0.1, 0.2, ...], dtype=np.float32).tobytes() r.hset("doc:1", mapping={"mandant": "42", "datum": "2026-04-01", "content": "Rechnung Müller", "embedding": emb})

Suche via FT.SEARCH mit KNN-Operator: FT.SEARCH docs_idx "(@mandant:{42})=>[KNN 10 @embedding $query_vec AS score]" PARAMS 2 query_vec <binary_blob> RETURN 3 content datum score DIALECT 2

Filter (@mandant:{42}) laufen vor dem KNN-Schritt – RediSearch macht das in einer Pipeline. Ergebnisse mit score und RETURN-Feldern.

Multi-Vektor pro Eintrag (seit 2.6): ein Hash kann mehrere Vektor-Felder haben (z.B. text_embedding und image_embedding) und in einer Anfrage kombiniert durchsucht werden. Praktisch für Multi-Modal-Use-Cases.

Persistenz: RDB-Snapshots (BGSAVE) und AOF (Append-Only-File) decken Backup ab. Cluster-Mode verteilt RediSearch-Indizes auf Shards; eine Suche läuft fan-out über alle Shards.

Redis mit RediSearch in 5 Schritten produktiv

1. 01Redis Stack installieren: Docker mit redis/redis-stack-server-Image oder APT-Paket auf Self-Hosted-Server. Persistenz (RDB + AOF) aktivieren.
2. 02Index-Schema planen: FT.CREATE mit allen Filter-Feldern (TAG, TEXT, NUMERIC) und dem Vektor-Feld als HNSW oder FLAT. Dimension passend zum Embedding-Modell.
3. 03Embedding-Pipeline aufsetzen: Texte werden extern vektorisiert (OpenAI, Cohere, sentence-transformers); HSET schreibt Vektor als Float32-Binary plus Filter-Felder.
4. 04Suche mit Filter und KNN: FT.SEARCH mit (@filter)=>[KNN K @vec $param AS score] DIALECT 2. Score-Schwelle optional für schlechte Treffer-Filterung.
5. 05Backup und Monitoring: RDB-Snapshots stündlich, AOF persistent; INFO-Befehl in Prometheus-Exporter; bei Cluster-Mode pro Shard separat.

Wann Redis mit RediSearch einsetzen

Redis mit RediSearch passt, wenn (a) Redis bereits im Stack als Cache oder Session-Store läuft, (b) sub-10ms-Latenz für Vektor-Suche gefordert ist, (c) Real-Time-Personalisierung mit gleichzeitigen Counter- und Set-Operationen kombiniert wird oder (d) die Datenmenge so klein ist, dass In-Memory-Storage wirtschaftlich bleibt (< 5 Mio. Vektoren bei 1536 Dim ~ 30 GB RAM).

Konkrete Fälle: ein E-Commerce-System mit Live-Empfehlung – Kunde sieht Produkt X, semantisch ähnliche Produkte aus dem 50.000-Produkt-Katalog werden in unter 5 ms angezeigt. Eine autocomplete-Funktion mit Embedding-Hits: Benutzer tippt, semantische Ergebnisse erscheinen ohne sichtbare Verzögerung. Ein Chatbot-System mit Session-Memory in Redis und Vektor-Lookup im selben Redis-Instanz für Kontextüberbruckung.

Für Multi-Modal mit Text und Bild eignet sich RediSearchs Multi-Vektor-Feature ab Version 2.6 – beide Embeddings in einem Hash, in einer Suche kombiniert. Für Treuhand-Belegerkennung mit OCR-Text und Bild-Embedding ist das eine valide Option, sofern die Datenmenge im RAM-Budget bleibt.

Redis Cloud (Managed) bietet EU-Regionen in Frankfurt und Ireland; für DACH-Kunden mit moderater Last (< 10 GB RAM, < 1000 QPS) ist die Cloud-Variante ab USD 50/Monat eine Option. Self-Hosted auf Hetzner ab CHF 30/Monat für 16 GB RAM Server.

Das Profil ist also: nicht „Redis statt Qdrant für alles", sondern „Redis für den Subset, wo niedrige Latenz und Stack-Integration mehr zählen als Vektor-DB-Tiefe".

Wann NICHT

Wenn Redis nicht bereits im Stack ist, lohnt sich die Einführung allein für Vektor-Suche selten. Eine spezialisierte Vektor-DB wie Qdrant ist einfacher zu betreiben – kein Cluster-Mode, kein RDB/AOF-Tuning, klarer fokussiertes API.

Bei Datenmengen über 10 Mio. Vektoren wird Redis als In-Memory-Lösung teuer. 10 Mio. Vektoren mit 1536 Dim brauchen ca. 60 GB RAM für den HNSW-Index plus Payload. Ein Server mit 128 GB RAM kostet wesentlich mehr als ein vergleichbarer Setup mit Qdrant Disk-Optionen oder Milvus mit DiskANN. Bei 100 Mio. Vektoren ist Redis wirtschaftlich nicht mehr vertretbar.

Für komplexe Hybrid-Suche (BM25 plus Dense in einer Anfrage mit Score-Mix) ist RediSearch weniger ausgereift als Weaviate oder Elasticsearch kNN. Volltext-Suche existiert, aber die BM25-Score-Kombination mit Vektor-Distance ist manueller.

Wenn Lizenz-Sensibilität hoch ist (z.B. für SaaS-Produkte, die Redis weiterverkaufen), ist RSALv2/SSPL ein Problem. Valkey als Open-Source-Fork löst die Lizenz-Frage, aber RediSearch-Modul-Kompatibilität ist nicht garantiert – Valkey-Pendants existieren teils, sind aber Stand Mai 2026 weniger ausgereift.

Für Use-Cases, die strikte ACID-Konsistenz mit relationalen Daten brauchen, ist Redis (eventual consistency in Cluster-Mode) keine gute Wahl. pgvector ist dort klarer überlegen.

Für Long-Term-Persistenz (Archiv-RAG über 30 Jahre Dokumente) ist Redis nicht das richtige Werkzeug – In-Memory plus Snapshots ist hier teurer und weniger sicher als Disk-basierte Systeme.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. RediSearch documentation – vector search, HNSW, FLAT · 2026-05
2. Redis Stack – bundled distribution including RediSearch 2.8 · 2026-05
3. Redis Cloud pricing and EU regions · 2026-05
4. Valkey – Linux Foundation fork of Redis under BSD-3 · 2026-04