Det finnes en uskreven regel i utviklerverdenen: Du skal ikke skrive din egen database. Den står rett ved siden av «du skal ikke skrive din egen kryptering» og «du skal ikke parse HTML med regex». Fornuftige regler, laget av fornuftige folk.
Jeg har brutt den. Med vilje. Over lang tid. Og nå er den sluppet: Elyra SQL Server — en MySQL-kompatibel SQL-server skrevet i Rust, der hele databasen bor i én eneste krasjsikker fil.
La meg forklare hvordan en ellers noenlunde oppegående mann fra Bergen endte opp her.
Jeg har brukt databaser i alle år. Og jeg har vært innom hele buffeten:
MySQL er som en gammel arbeidshest. Trofast, kjent, står i alle stallene. Men den har begrensninger som begynner å merkes godt i 2026. Den ble designet for en verden der «søk» betydde LIKE '%noe%' og ingen hadde hørt om embeddings.
Postgres er hakket bedre — la det være sagt, Postgres er et solid stykke håndverk. Men også der støter jeg på funksjonelle begrensninger, og skal du ha moderne ting som skikkelig vektorsøk, ender du fort opp med å skru på extensions, tredjepartskomponenter og en liten hage av tilleggsverktøy som alle skal vedlikeholdes, oppgraderes og krangles med.
MS SQL Server er teknisk sett helt ok. Men lisensmodellen? Den er omtrent like vennlig som en parkeringsvakt på overtid. Og Oracle — vel, Oracle er selskapet som fant opp konseptet «du eier ingenting, du leier alt, og revisoren vår kommer på besøk».
Fellesnevneren for de kommersielle er at du havner i lommen på storebror. Big Tech bestemmer prisen, betingelsene og retningen. Jeg har bygget hele Elyra-familien på det motsatte prinsippet: dine nøkler, dine data, din maskin, ingen telemetri, ingen som ringer og vil «snakke om lisensieringen din».
Da ble spørsmålet ubehagelig enkelt: Hvis ingen av databasene passer — hva gjør man da?
Så det gjorde jeg. Ikke over natten — dette er ikke et helgeprosjekt som ble litt ute av kontroll (ok, det er teknisk sett et prosjekt som ble litt ute av kontroll). Dette er bygget opp stein for stein over lang tid, slik man bygger noe man faktisk skal stole på.
Og her er poenget som gjorde at jeg turte: De etablerte databasene har vært på markedet i tiår. Det er både deres styrke og deres forbannelse. De drar på tiår med arkitekturbeslutninger tatt i en helt annen tid, og sliter med å holde seg i toppform med tanke på hvor vi faktisk er i 2026. Vektorsøk, embeddings, hybrid retrieval — alt dette er skrudd på i etterkant, som en spoiler på en Volvo 240.
Jeg fikk starte med blanke ark. Og med blanke ark kan man bygge inn det moderne fra dag én.
Kort fortalt:
Hele databasen er én fil. Én krasjsikker ACID-fil (.edb) med multi-version concurrency. Ingen datakatalog med 400 mystiske filer. Backup? Kopier filen. Ferdig.
Den snakker MySQL wire protocol. Det betyr at mysql-klienten, DBeaver, Workbench og hvilken som helst MySQL-driver i hvilket som helst språk fungerer rett ut av boksen. Du trenger ikke lære noe nytt for å koble til.
Skrevet i Rust. Ingen garbage collector som tar seg en pust i bakken midt i en spørring. Sub-millisekund point lookups.
Full SQL. Joins, korrelerte subqueries, CTE-er med WITH RECURSIVE, window functions, set operations, serializable transactions. Dette er ikke en lekedatabase.
Replikering og HA er innebygd, for de som vil skalere lesing eller sove godt om natten.
Og så kommer godbitene — tingene som var hele grunnen til at jeg begynte.
Her er hvor 2026-delen kommer inn:
Vektorsøk er førsteklasses borger. VECTOR(n)-kolonner med både eksakt og HNSW-basert approksimativt nærmeste nabo-søk. Semantisk søk bor i databasen, ikke i en separat tjeneste du må drifte ved siden av.
Hybrid search i én spørring. HYBRID(text, 'query', vec, vector) fusjonerer fulltekst og vektorsøk med Reciprocal Rank Fusion — og respekterer WHERE-filteret ditt. Det er hele RAG-retrieval-stacken i én SQL-setning. Ingen Elasticsearch. Ingen reranker. Ingen tre ekstra Docker-containere som skal mates og stelles.
Embeddings rett i SQL. ai_embed('tekst') kaller et OpenAI-kompatibelt endepunkt — i skyen eller mot en lokal Ollama/vLLM-server — og returnerer vektoren. Du genererer query-vektorer og lagrede verdier direkte i SQL. (Og ja, selvsagt kan du kjøre alt lokalt. Dette er fortsatt Elyra.)
Parallell OLAP. Store aggregeringer kjører gjennom en parallell, strømmende motor. Analytiske spørringer uten et eget datavarehus ved siden av.
Slik ser det ut i praksis:
# Start serveren på én fil
$ elyrasql serve --data mydb.edb
✓ MySQL protocol on 127.0.0.1:3306
# Koble til med helt vanlig mysql-klient
$ mysql -h127.0.0.1 -P3306
mysql> SELECT id FROM docs
-> ORDER BY embedding <-> VECTOR '[…]' LIMIT 5;
Det er hele oppsettet. Ingen konfigurasjonsfiler på 900 linjer. Ingen tuning-guide du må lese før du tør å starte den.
Gratis. Åpen kildekode. Ligger på GitHub.
Ingen lisensrevisjon. Ingen «per core»-matematikk. Ingen selger som ringer i februar. Du laster ned en tarball for Linux (x86_64 eller ARM64), eller bygger fra kildekode hvis du er den typen. Versjon 0.9.3 er ute nå, stemplet stabil.
Å bygge en database er litt som å bygge sin egen båt. Alle sier du burde kjøpt en ferdig. Alle har rett, statistisk sett. Men så står du der en dag med noe som flyter, som er bygget nøyaktig slik du vil ha det, uten en eneste kompromiss du ikke selv har valgt — og da forstår du hvorfor folk gjør det likevel.
Elyra SQL Server har alt jeg vil ha i en moderne SQL-server. Ikke alt alle andre vil ha — alt jeg vil ha. Og det viser seg at når man bygger for seg selv med ærlige prinsipper, ender man ofte opp med noe andre også vil ha.
Ta en titt på elyracode.com/sql/server, eller gå rett på koden på GitHub. Og hvis du finner noe rart — det heter issues, ikke kritikk. Jeg tåler begge deler.