KineDB rejser 850.000 euro til en database, der kan køre offline

Københavnske KineDB har rejst 850.000 euro i en pre-seed-runde omtalt 29. oktober 2026. Selskabet vil udvikle en database, der kan gemme ændringer på en lokal enhed uden internetforbindelse og senere synkronisere dem med en server. Pengene skal gå til produktudvikling og til at ansætte ingeniører med speciale i databaser, lagring og forespørgsler.

Superhero Capital førte runden. NGL Ventures og investorerne Jussi Pyörre, Kristoffer Abell og Jakob Lilholm deltog også, fremgår det af Vestbees omtale af runden. KineDB, som er registreret som dansk ApS, angiver på sin produktside fortsat adgang som early access med designpartnere. Finansieringen skal altså udvikle og afprøve produktet videre; den markerer ikke en bred lancering.

Investorerne finansierer en fælles databasemotor

KineDBs mål er at samle arbejde, som udviklere ofte må fordele mellem flere systemer. Hvis en applikation skal virke uden forbindelse, skal den kunne læse og skrive data lokalt. En central database skal samtidig modtage ændringerne, når forbindelsen vender tilbage, og applikationen skal håndtere tilfælde, hvor de samme oplysninger er ændret flere steder.

En mulig opbygning er en lokal database på enheden, en cloud-database på serveren og særskilt software til synkronisering mellem dem. Hvert led har sin egen måde at gemme og opdatere data på. Udviklerholdet skal derfor få ændringer, fejl og genforsøg til at hænge sammen på tværs af systemerne. Det er den integrationsopgave, KineDB vil flytte ind i selve databasemotoren.

Selskabets plan er, at den samme motor skal kunne indlejres i en applikation og køre på servere. Replikering, sammenfletning af ændringer og versionshistorik indgår i produktets arkitektur frem for at blive tilføjet som separate lag. Det kan give udvikleren færre forbindelser mellem forskellige produkter at vedligeholde. Selve applikationen må stadig afgøre, hvad en konflikt betyder for brugeren: To ændringer af samme registrering kan ikke altid forenes meningsfuldt alene af en database.

Stifterne Axel Löwenhoff og Allan Zimmermann retter dermed arbejdet mod både lagringsmotoren og dens anvendelse på tværs af miljøer. De varslede ansættelser inden for lagring og forespørgsler passer til den opgave. En motor, som skal arbejde på en lokal enhed og i en serverinstallation, skal fungere under forskellige vilkår for hukommelse, diskplads, netværk og belastning.

Hvad der adskiller planen fra en cloud-database

En cloud-database kan godt indgå i en applikation, der fungerer offline. Forskellen ligger i, hvor den lokale lagring og synkroniseringen hører hjemme. Med et særskilt synkroniseringslag skal applikationen eller et ekstra produkt omsætte lokale ændringer til opdateringer på serveren. KineDB vil lade lokale instanser og servere arbejde med samme databasemotor.

Det giver to forskellige tekniske opgaver. På en enhed skal læsning og skrivning kunne fortsætte, når serveren ikke kan nås; efter genopkobling skal ændringerne overføres. I en serverklynge handler det om at fordele data og holde kopier på flere maskiner ajour. At motoren er fælles, gør ikke de to former for synkronisering identiske. En telefon kan være afkoblet længe, mens servere i en klynge normalt koordinerer deres ændringer løbende.

Versionshistorik er en anden del af KineDBs tilgang. Tidligere tilstande kan være relevante, når ændringer skal spores eller sammenholdes efter en afbrydelse. Den mulige gevinst er et mindre behov for selv at bygge historik og synkronisering oven på en anden database. Hvor stor gevinsten bliver ved almindelig drift, kræver erfaring med konkrete applikationer, især når forbindelser afbrydes, og flere brugere ændrer de samme data.

Lokalt, i en klynge og i browseren

KineDB beskriver en motor med flere driftsformer. De bør læses sammen med selskabets early access-status: Funktioner og demonstrationer viser, hvad produktet kan afprøves med, mens erfaringer fra designpartnere skal vise, hvordan delene fungerer samlet i længere tids drift.

• Lokalt: Motoren kan indlejres i en applikation og gemme data på disk eller i hukommelsen uden en separat server. Applikationen kan dermed fortsætte med lokale læsninger og skrivninger under en afbrydelse. Synkronisering bliver relevant, når forbindelsen til en server er tilbage.
• I en klynge: Servere kan indgå i én database, hvor data fordeles mellem maskiner og opbevares i flere kopier. Den driftsform skal give plads til mere data og flere forespørgsler på serversiden. Den løser en anden opgave end den lokale enheds behov for at arbejde uden net.
• I browseren: Den indlejrede JavaScript-udgave bruger WebAssembly og kan køre i en Web Worker. Det gør lokal databasekørsel mulig i en browser, men vedvarende lagring afhænger af browserens egne muligheder. En browserdemonstration viser derfor ikke i sig selv, hvordan en kundes samlede løsning opfører sig under længerevarende brug.

Den fælles motor er det afgørende produktløfte. Udvikleren skal kunne arbejde med data lokalt og på serveren uden at forbinde forskellige databasetyper med et selvbygget lag. For selskabet er den svære prøve hele forløbet: En ændring skal overleve en afbrudt forbindelse, nå frem efter genopkobling og indgå korrekt sammen med ændringer fra andre instanser.

Designpartnerne skal vise, hvad løsningen kan bære

KineDB bruger arbejde under jorden som eksempel på et miljø med ustabil forbindelse. En medarbejder kunne registrere et udstyrs tilstand på en mobil enhed i en mine og sende registreringen til en central database senere. Det er et tænkt anvendelsesforløb, ikke en offentliggjort kundeinstallation. Eksemplet viser, hvorfor lokal lagring alene ikke er nok: Oplysningen skal også kunne overføres og bruges sammen med resten af virksomhedens data.

Early access giver KineDB mulighed for at arbejde med netop sådanne forløb sammen med designpartnere. Den næste væsentlige oplysning for potentielle brugere bliver erfaringer fra drift: hvordan ændringer håndteres efter afbrydelser, hvilke konflikter der kræver beslutninger i applikationen, og om samme motor kan fungere stabilt både tæt på brugeren og på serverne.

Læs også:

• Schneider køber PTC – ny gæld skal finansiere op til 17 mia. euro
• Pandektes rejser 13,5 mio. euro – vil være datalaget under juridisk AI
• Anthropic lukker seks kontrollører ind – men bestemmer, hvad der skjules