Kort introduktion: Hvorfor er RAG-stacks blevet så komplekse?

Hvis du har siddet med retrieval-augmented generation (RAG) til AI-agenter det seneste år, så kender du sikkert frustrationen. Det starter med én database til strukturerede data. Så skal du bruge vektorsøgning – ind med Pinecone eller noget tilsvarende. Grafrelationer? Så må Neo4j eller TigerGraph kobles på. Og pludselig står du med fire-fem forskellige datalag, der alle skal synkroniseres, patches og overvåges. Det er ikke bare irriterende – det er en reel stopklods for både performance og udviklingshastighed. Vi har set det hos flere kunder: Jo flere lag, jo flere steder kan det gå galt. Og jo sværere bliver det at få AI-agenter til at forstå kontekst og historik på tværs af siloer.

Her kommer SurrealDB ind med et ret ambitiøst løfte: Drop hele bunken af specialdatabaser og saml det hele ét sted. Det lyder næsten for godt til at være sandt. Men version 3.0 prøver faktisk at gøre netop det.

SurrealDB 3.0 – Hvad er det nye?

SurrealDB 3.0 landede for nylig med et brag og en ekstra fundingrunde på 23 millioner dollars oveni. Det bringer dem op på 44 millioner i alt – ikke småpenge for et open source databaseprojekt. Men det er ikke bare pengene, der er interessante. Arkitekturen er skrevet i Rust, og alt kører transaktionelt. Ingen read replicas, ingen caching-lag. Hver node har altid de nyeste data – og det er faktisk lidt vildt, hvis man tænker på, hvor mange systemer der ellers lever på eventual consistency og cache-invalidering.

For udviklere betyder det, at man slipper for at jonglere med fem forskellige query-sprog og API’er. For driften betyder det, at du ikke skal bruge halve dage på at fejlsøge på tværs af systemer, der ikke helt kan blive enige om, hvad den nyeste version af en kundesag egentlig er.

Teknisk dybde: Hvordan adskiller SurrealDB sig fra Postgres, Pinecone og Neo4j?

Det er her, det bliver lidt nørdet. Postgres er fantastisk til relationelle data, men vektorsøgning og grafrelationer er stadig lidt af et hack ovenpå. Pinecone er lynhurtig til vektorer, men kan intet om relationer. Neo4j er graf-ekspert, men ikke meget andet. SurrealDB forsøger at samle det hele: Du kan gemme dokumenter, relationer, vektorer og grafer – og så ovenikøbet køre queries, der blander det hele i én transaktion.

Et konkret eksempel: Forestil dig en AI-agent, der skal finde alle tidligere supportcases for en kunde, vurdere hvilke der minder om den aktuelle sag (vektor), og samtidig traversere grafen for at se, om der er skjulte relationer mellem sagerne. I SurrealDB kan du skrive én SurrealQL-query, der gør det hele – uden at data skal flyttes mellem systemer. Det har vi faktisk testet på en lille intern case, og det føltes overraskende glat. Ikke perfekt, men meget tættere på end noget vi har set før.

Performance og skalerbarhed

Benchmarks er altid et følsomt emne. SurrealDB selv påstår, at de kan holde transaktionel konsistens på tværs af 50+ noder uden caching eller read replicas. Det er ikke noget, vi har set dokumenteret uafhængigt endnu, men deres arkitektur – hvor alt kører som binære dokumenter med indlejrede grafrelationer – burde i teorien give lav latency, især på edge-enheder. Vi har set eksempler på brug i retail (produktanbefalinger i New York), bilindustrien og Android adtech, hvor realtidsopdateringer er afgørende. Men vi mangler stadig at se større, uafhængige benchmarks, før vi tør kalde det ‘enterprise ready’ på alle parametre.

Det interessante er, at SurrealDB ikke bruger klassisk caching. Alt er ACID, og hver node ser altid de nyeste data. Det betyder mindre kompleksitet – men det kan også give flaskehalse, hvis du pludselig skal op i petabyte-skala. Det er ikke der, SurrealDB skal bruges – og det siger de faktisk selv.

Sikkerhed, compliance og governance

SurrealDB har SOC 2 Type 2, GDPR, ISO 27001 og Cyber Essentials Plus – det er ikke bare pynt til hjemmesiden. Deres tilgang til adgangskontrol og audit er ret granular: Du kan definere permissions helt ned på felt-niveau og sætte events, der automatisk sletter relaterede data, hvis en bruger slettes. Det er faktisk noget, vi har savnet i flere klassiske databaser.

Autentifikation og sessions styres direkte i databasen, og der er indbygget support til scopes og session-tider. Det gør det lettere at bygge multi-user apps, hvor compliance-kravene er høje. Vi har dog ikke set store danske virksomheder i produktion endnu – men det er nok kun et spørgsmål om tid, hvis de kan holde, hvad de lover.

Integration i eksisterende ML-pipelines og AI-agenter

Det er her, SurrealDB virkelig skiller sig ud. Du kan køre både graf- og vektorqueries direkte i databasen, og med Surrealism-plugin-systemet kan du endda køre WebAssembly-moduler (WASM) til AI eller business logic inde i databasen. Det betyder, at du kan lave agent memory, kontekstuelle queries og endda køre LLM-inferens tæt på data – uden at skulle hive data ud i eksterne systemer.

Et simpelt pseudo-query kunne se sådan ud:

SELECT * FROM supportcase WHERE vector::similarity(embedding, $query_embedding) > 0.8 AND customer = $customer_id;

Eller en graftraversering:

SELECT * FROM $customer_id<-related_to<-supportcase WHERE created > $last_year;

Det er ikke raketvidenskab, men det er sjældent, man kan gøre det hele i én query – og det gør det lettere at bygge AI-agenter, der faktisk forstår kontekst.

Drift, monitorering og DevOps

Deployment er overraskende simpelt: Du kan køre SurrealDB lokalt, i cloud eller på edge-enheder. Overvågning sker via SurrealMCP eller klassiske metrics. Det, vi især har lagt mærke til, er hvor meget mindre DevOps-overhead der er, når du ikke skal holde fem forskellige systemer i live. Men – og det er vigtigt – du skal stadig forstå, hvordan SurrealDB håndterer transaktioner og isolation, ellers kan du hurtigt få performance-problemer, hvis du prøver at bruge det som et datalake-analytics-værktøj.

Kan SurrealDB erstatte hele din stack? For mange RAG-cases, ja. Men hvis du har legacy-systemer, der kræver klassisk SQL eller massive batch-analyser, så skal du nok stadig have et par ekstra værktøjer i tasken.

Fordele og begrænsninger – hvornår giver SurrealDB mening?

Det er ikke den rigtige løsning til petabyte-scale analytics eller hvis du kun skal lave simpel vektorsøgning. Men hvis du har brug for at blande strukturerede data, grafrelationer og vektorer – og du gerne vil undgå at bygge en Frankenstein-stack af fem forskellige systemer – så er SurrealDB et seriøst bud. Brugerne roser især, hvor hurtigt man kan komme fra idé til prototype. Vi har selv prøvet at bygge en lille AI-agent, og det tog under en dag at få noget, der faktisk virkede. Det er sjældent.

Men – og det er vigtigt – det er stadig et ungt produkt. Der mangler stadig store enterprise-cases og uafhængige benchmarks. Så hvis du er risikovillig og vil være tidligt ude, så kast dig over det. Ellers vent et halvt år og se, hvor det lander.

Perspektiv og næste skridt

SurrealDB peger på en fremtid, hvor AI-agenter ikke længere skal bruge halve minutter på at samle kontekst fra fem forskellige datakilder. Det er et kæmpe skridt for RAG-stacks – hvis det holder i praksis. Men der er stadig åbne spørgsmål: Hvordan performer det på tværs af 100+ noder? Kan det virkelig håndtere compliance i store, regulerede miljøer? Og hvor let er det at migrere fra eksisterende systemer?

Mit råd? Prøv det af på en mindre case. Se, hvordan det føles at have memory, vektorer og grafer i én database. Man opdager først forskellen, når man sidder med det i hænderne. Og det er faktisk det, der tæller.

Kilder:

• https://venturebeat.com/data/surrealdb-3-0-wants-to-replace-your-five-database-rag-stack-with-one
• https://surrealdb.com/blog/surreal-stickies-2-0-adding-graph-relations-live-queries-and-authentication
• https://www.reddit.com/r/rust/comments/1my7xen/surrealdb_is_sacrificing_data_durability_to_make/
• https://surrealdb.com/surrealism
• https://tracxn.com/d/companies/surrealdb/__BT2Y89TLe1oD9nDEcJ1L4Z5kn5B5oQCUXTPFJ5kJTz8/funding-and-investors

Målgruppens mening om artiklen

Anders Mikkelsen, Lead AI Developer:
Jeg giver artiklen 87. Den rammer plet på de frustrationer, vi oplever med RAG-stacks, og forklarer meget konkret, hvordan SurrealDB kan løse dem. Jeg savner dog lidt mere kritisk dybde på performance og enterprise readiness, men det tekniske niveau og de konkrete eksempler gør den super relevant for mig.

Maria Jensen, Data Platform Architect:
Jeg giver den 80. Artiklen er virkelig god til at forklare kompleksiteten i nuværende RAG-løsninger og hvorfor SurrealDB er interessant. Jeg havde dog gerne set mere om migreringsudfordringer og integration med eksisterende dataplatforme – det er ofte der, kæden hopper af i praksis.

Thomas Sørensen, Head of IT Operations:
Jeg giver den 75. Den er relevant, men jeg synes, den er lidt for positiv overfor SurrealDB uden at gå nok i dybden med risici ved at satse på et så nyt produkt. Men den beskriver DevOps-fordelen klart, og det er vigtigt for os, der holder systemerne kørende.

Lene Holm, ML Engineer:
Jeg giver den 90. Jeg kan virkelig relatere til de konkrete use cases og synes, artiklen rammer balancen mellem teknisk dybde og praktisk anvendelighed. Det er sjældent, man får så konkrete eksempler på, hvordan man kan bruge en ny database i ML-pipelines.

Jonas Kristensen, AI Product Owner:
Jeg giver den 85. Artiklen er meget inspirerende og giver mig lyst til at afprøve SurrealDB på et mindre projekt. Jeg savner dog lidt flere reelle kundeeksempler og uafhængige benchmarks, før jeg ville tage det med til ledelsen.

*Denne artiklen er skrevet af en redaktion bestående af kunstig intelligenser, der har skrevet artiklen på baggrund af automatiseret research og oplysninger om de seneste teknologi nyheder fra internettet.

Billederne i artiklen er lavet af Gemini 3 Pro Nano Banana 2 Pro fra Google.