Var databasschemat egentligen finns

Allt som den här tjänsten gör finns i versionshantering. Koden gör det i alla fall. Databasen den körs på består av 32 tabeller, och 15 av dem har ingen definition någonstans i repositoriet — ingen CREATE TABLE, ingen schemafil, ingenting. En dump återställer alla 32 med strukturen intakt; det repositoriet inte innehåller är en andra, oberoende kopia av den strukturen.

Siffrorna kommer från en jämförelse av den körande databasen mot 736 filer och 5 671 710 tecken i repositoriet. De är ingen uppskattning.

Hur halva schemat försvinner

Det är inte slarv, och det är just därför det är värt att skriva ner. Varje enskilt steg var rimligt.

Tabeller som skapades innan den nuvarande kodbasen fanns skrevs aldrig ner, eftersom de vid den tiden helt enkelt fanns där. Tabeller som lagts till sedan dess kom via migreringsskript, och de skripten finns i repositoriet — det är därifrån de 17 definitionerna kommer. Kolumner som lades till senare lades till med en enradig ALTER TABLE inskriven direkt vid en prompt, eftersom det gick snabbare att skriva den än att skriva ett skript för en ändring som tog en sekund.

Index är det värsta fallet. Ett index läggs till när något är långsamt, i samma ögonblick som det är långsamt, och det löser problemet direkt. Inget spår lämnas kvar, inget att granska, inget som fallerar när det glöms bort. Elva av de trettiotvå sekundära indexen här finns av exakt det skälet och är inte dokumenterade någonstans.

Tabellen som innehåller själva räknarna, 166 438 rader, hör till de femton som saknar definition i repositoriet.

Vad som faktiskt går sönder

Inte mycket, fram till ett visst ögonblick: när databasen återställs från en dump.

En dump innehåller strukturen, så en rak återställning går bra. Faran är varje väg som bygger upp en tabell på nytt i stället för att återställa den — flytt till en annan maskin, import av utvalda tabeller, återskapande av en tabell från ett skript. Datan kommer tillbaka, men indexen gör det i tysthet inte. Ingenting fallerar. Frågorna ger rätt svar. De tar bara längre tid, och orsaken syns inte, eftersom den enda dokumentationen av vad indexet var är maskinen som inte längre har det.

Det är det felmönster som är värt att sätta namn på: ett saknat index ger inget fel, det ger ett långsammare korrekt svar. Det finns inget test för det, eftersom testerna går igenom.

Vad vi gör åt det under tiden

Schemat finns inte i repositoriet i dag, och det är den korrekta beskrivningen av läget. Det som finns på plats är snävare än en fullständig lösning, och det täcker det fall som faktiskt kostar något:

En dump före allt som är destruktivt, förvarad utanför webbroten. En återställning som faktiskt har genomförts minst en gång, i stället för att bara antas fungera. Och en kort lista, som kontrolleras efter varje återställning, över de index som man vet bara finns i den körande databasen — eftersom man kan fråga maskinen vilka index den har och jämföra svaret med förra gången man frågade.

Den allmänna versionen gäller mer än databaser. Om en del av ett system bara finns i det körande systemet, finns det ingen andra kopia av den. Frågan som är värd att ställa om varje del av infrastrukturen är inte om den säkerhetskopieras, utan vad som inte skulle gå att bygga upp igen från repositoriet om maskinen försvann. Här är svaret femton tabeller och elva index, det tog en eftermiddag att fastställa, och det är en lista snarare än en okänd storhet.

Uppdatering: september 2026

Fem dagar efter att det här inlägget publicerades checkades arbetskatalogen in: 26 filer och 4 058 rader, bland dem elva migreringsskript skrivna mellan 28 augusti och 1 september som fram till dess bara fanns på den körande maskinen. Det var den enkla halvan — kod som hade skrivits men aldrig registrerats.

Mätningen upprepades den 1 september 2026 på samma sätt: den körande databasen mot allt som git spårar.

Tabeller	46	30 med en CREATE TABLE i repositoriet, 16 utan
Sekundära index	43	32 skapade av kod i repositoriet, 11 bara i den körande databasen
Migreringsskript	109	i versionshantering

Den siffra som spelar roll rörde sig inte. Den 27 augusti fanns elva sekundära index ingen annanstans än i den körande databasen. Den 1 september är de fortfarande elva. Elva ytterligare index lades till däremellan, och vart och ett av dem kom med ett migreringsskript: vanan ändrades, skulden gjorde det inte.

De elva sitter på fem tabeller — räknarna, språken, hänvisande sidor, uteslutningslistan och händelseloggen. Alla fem är äldre än den nuvarande kodbasen, vilket är precis varför ingenting någonsin skrevs ner för dem. Att skriva en fil nu skulle innebära att från en körande server rekonstruera vad som skrevs in vid en prompt för flera år sedan.

Läget från augusti står sig alltså. Schemat finns fortfarande inte i repositoriet, och en återställning som bygger upp en tabell på nytt i stället för att återställa den skulle fortfarande tappa elva index utan ett ljud. Det som har ändrats är snävare: allt som lagts till sedan dess har lämnat en fil efter sig.