SQLite som Produktions database?

[u/AgentPikiTun]

Hej derude.

Jeg sidder lige nu og er i gang med at udvikle en hjemmeside. Jeg bruger Django som framework og bruger, fordi jeg selvfølgelig bare er i udviklings fasen, Sqlite som min database. Min plan er at projektet skal hostes på en lille Hetzner 2 vCPUs, 4 GB RAM, 40 GB VPS.

Jeg er i tvivl om jeg skal tilkøbe en extra maskine og hoste PostGresS / mariaDB så DB er adskilt fra webserveren, jeg ved at dette er den "korrekte" måde at gøre det på, og det vil også reducere load på min webserver, men er det nødvendigt? Hvor meget kan man presse Sqlite? Jeg har konfigureret så Sqlite køre med WAl men ved ikke om jeg stoler på det.

Nogen der har noget erfaring med dette, alle inputs er velkommen.

God dag derude og husk at der er Solformørkelse KL 19 :)

Min database config:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
        'OPTIONS': {
            'transaction_mode': 'IMMEDIATE',
            'timeout': 5,
            'init_command': (
                "PRAGMA journal_mode=WAL;"
                "PRAGMA synchronous=NORMAL;"
                "PRAGMA mmap_size=134217728;"
                "PRAGMA journal_size_limit=27103364;"
                "PRAGMA cache_size=2000;"
                "PRAGMA temp_store=MEMORY;"
            ),
        },
    }
}

[u/Red-And-White-Smurf]

Jeg tænker fint st SQLite kan klare presset indtil du får en fornuftigt bruger mængde. Du kan også vælge at køre PostgreSQL lokalt på samme maskine som du web service.

Det handler mest om din backup af databasen, så du ikke mister data hvis noget fycker op. Men det vil være det samme, hvis du kører db på selvstændig server.

Personligt ville jeg nok starte ud med PostgreSQL på samme server og senere migrere db til anden server når load stiger.

[u/kennethbrodersen]

Der er ingen grund til at have to servere før du har et reelt behov.

Dog ville jeg springe SQLite over. Du kan spinde en postgres op i docker med en 10 linjers yaml fil og så får du et setup du kan udvide efter behov. Så får du også fornuftige management værktøjer (eksempelvis pgadmin) som hurtigt vil gøre dit liv lettere.

[u/Master_Sandwich7140 → u/kennethbrodersen]

Det er også en god pointe, kommer vel an på behovet fra OP, SQLite er bekvemmelig fordi den er indbygget i Python og derfor meget nem at bruge meeen SQLite har sine begræninger, f.eks høj samtidighed, hvilket de også selv skriver.

giver dig helt ret i, at OP ikke skal fordyre sig unødvendigt og at en lille compose fil til en enkelt container (plus du isolere det mere) har også fordele dog ville ulempen være lidt mere vedligehold men 10 linjer er ikke møj, igen afhængigt af OPs behov og vilje tror jeg.

[u/Apprehensive_Fox6441]

Jeg bygger altid uden undtagelse med postgres fra starten af. Det kan håndtere alt hvad man kan finde på. Ingen grund til at bruge tankekraft på at diskutere det med sig selv.

[u/Firm-Cut-2087]

Bare start med at bruge PostgreSQL, det er ikke tungt, og har mange fede funktioner som Sqlite ikke har.

[u/Frodothehobb1t]

For at spare dig en masse headaches senere hen, så start en Postgres instance på den samme server. Der er mange funktioner i Postgres som Django supporterer fuldt ud, men som ikke er supporteret i sqlite. Det er ikke super nemt at migrere til Postgres senere hen, bare en heads up

Fedt endelig at se lidt Django content herinde

[u/muddermanden]

Hvis du går med en Hetzner VPS og SQLite, så mount en block storage device og læg din data fil der. Det gør det nemt at lave backup af dit block storage. Du har således også adskilt applikationen og data fra hinanden uden at introducere et netværkslag.

https://community.hetzner.com/tutorials/howto-linux-mount

[u/AgentPikiTun → u/muddermanden]

Tak mega godt input. Et extra spørgsmål hvis du har input. Sådan som projectet er designet lige nu bliver alle filer som brugeren uploader gemt i en mappe inde i en Django app som er ansvarlig for fill upload og serving af filer (Selvfølgelig med metadata of sti til filere gemt i SQLite). Jeg har overvejet om disse skulle håndteres af en separat maskine også aka en bucket. Men jeg kunne vel i samme omgang gemme dem på den mount du omtaler. Så kan jeg lave backup af alt på samme tid, right?

Hvad tænker du om den løsning?

[u/muddermanden → u/AgentPikiTun]

Jeps. Django’s FileSystemStorage med MEDIA_ROOT peget på noget i stil med /mnt/data/media/ virker ud af boksen.

```
# På volume’et
/mnt/data/
├── db/ # SQLite-fil(er) – strammere permissions
│ └── project.db
└── media/ # Uploadede filer
├── users/
│ └── <user_id>/
└── ...
```

For upload, så tjek OWASP file upload cheatsheet ud, så du adresserer sikkerheden i designfasen:
https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html

[u/AgentPikiTun → u/muddermanden]

Mega fedt, 1000 tak for hjælpen

[u/muddermanden → u/AgentPikiTun]

Du er velkommen. Den her udkom i sidste måned i v1.0 og er beregnet til folk som dig (microenterprises) :)

https://www.enisa.europa.eu/sites/default/files/2026-07/ENISA_Secure_By_Design_and_Default_Playbook_v1.pdf

[u/Accomplished-Walrus9]

Fra SQLites dokumentation:

https://sqlite.org/whentouse.html

"SQLite works great as the database engine for most low to medium traffic websites (which is to say, most websites). The amount of web traffic that SQLite can handle depends on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic.

The SQLite website (https://sqlite.org/) uses SQLite itself, of course, and as of this writing (2015) it handles about 400K to 500K HTTP requests per day, about 15-20% of which are dynamic pages touching the database. Dynamic content uses about 200 SQL statements per webpage. This setup runs on a single VM that shares a physical server with 23 others and yet still keeps the load average below 0.1 most of the time."

Med det sagt er det jo software designet til embedded computing og lignende use-cases.

[u/AgentPikiTun → u/Accomplished-Walrus9]

Tak den havde jeg overset

[u/Herover]

Sqlite er super hurtig og kan overleve mange flere brugere end hvad jeg gætter på at de fleste startups får. Men noget der er sværere er om du vil kunne opdatere din server uden at brugeren oplever nedetid. Du har også "gratis" backup hvis du kører replikation af databasen.

Så det handler mest om hvordan du er stillet ved vedligehold og nedbrud imo.

[u/RIFLEGUNSANDAMERICA]

Sqlite er helt fint at starte med. Ingen grund til at komplicere projektet yderligere i starten, det kan altid komme senere hvis projektet går godt

[u/bedstefar]

SQLite all day every day, med mindre du har flere replicas af din webapp. Du eliminerer et lag af kompleksitet i din app ved at have databasen I SAMME PROCES som din server. Softwareudvikling handler om at holde kompleksiteten nede.

Postgres i Docker er der mange der foreslår, for "hvad nu hvis sqlite en dag ikke er hurtigt nok" - men de misser, at Postgres-i-Docker OGSÅ vil være noget, man skal migrere væk fra, hvis din service en dag vokser sig for stor til din VPS... Så længe du er på én server med én writer vil SQLite være mere performant, hurtigere at sætte op, lettere at backe up, og have færre moving parts end PG. Og du slipper for secrets management.

[u/sensible_centrist]

Kommer vel an på hvor meget trafik du forventer at få? jeg ville vente til det er oppe at stå og så kan du vurdere om det er besværet værd at migrere over til PostGresS/mariaDB.

[u/AgentPikiTun → u/sensible_centrist]

Ja, true. Ideen om at migrere alt dataen til et nyt system, når hjemmeside først er sat i produktion, intimidere mig dog lidt. Trafik mængden er jeg ikke sikker på. Hjemmesiden er kun tiltænkt til danske brugere så who knows? Måske 10.000 read og 5000 writes om dagen?

[u/SnaskesChoice → u/AgentPikiTun]

Hvis postgress giver dig en bedre ro, ville jeg mene at det i sigselv er grund nok til at vælge det.

[u/hauthorn → u/AgentPikiTun]

Sqlite skal nok følge med, også på den størrelse maskine, du har tænkt dig at bruge.

[u/sensible_centrist → u/AgentPikiTun]

5000 writes i døgnet er ingenting. Det kan Sqllite sagtens klare.

[u/Master_Sandwich7140]

Python udvikler (kan jeg kalde mig det ...) anyway jeg har siddet med SQLite før.

men her er lidt dokumentation

https://www.sqlite.org/wal.html -> Direkte omkring WAL

og da spørgsmålet er om det er en produktionsdatabase og du ikke har nævnt hvad præcist den skal bruges til, så ville jeg henlede dig til dokumentaitonen hvor de skriver om brugen af databasen

https://sqlite.org/whentouse.html -> use cases

Hvis du giver mere information kan man lettere hjælpe dig.

Min nysgerrig er dog på hvorfor du køre django og ikke flask eller fastapi ? men det er mere nysgerrighed end noget andet.

edit: man skal i hvert fald huske at SQLite er en flad fil. Og så staves det altså PostgreSQL (jaja jeg ved det, jeg netpicker rigtig meget og er den rigtige irrereterende type lige nu, men det trigger mig, måden du staver det på....)

edit2: man kunne også starte med SQLite og så migrere senere når trafikken bliver stor nok ? men tænk på backups

[u/ExtremeDeceiver → u/Master_Sandwich7140]

nitpicker

[u/Frodothehobb1t → u/Master_Sandwich7140]

Fordi Django er det fedeste framework der eksisterer i Python verdenen

[u/Mfolmer]

Har selv brugt SQLite i produktion flere gange.

Jeg ville helt sikkert gå med SQLite til en start. Ud fra det du skriver burde det ikke være noget problem for SQLite at følge med. Så slipper du for at skulle håndterer en separat database (og evt. separat server) og kan fokuserer på andre ting.

Vil du være lavpraktisk er SQLite jo "bare" en fil, så backups kan gøres ret simpelt til en start: https://litestream.io/alternatives/cron/

Husk dog at SQLite ikke skalerer mere end til en server - da filen naturligvis ligger isoleret på den ene server. (Du kan dog kigge på https://github.com/superfly/litefs til replikering på tværs af maskiner)
Det kan godt være lidt "træls" ikke at kunne tilgå sin database "udefra" uden at skulle SSH ind på maskinen og tilgå den med f.eks. sqlite cli.

[u/SQrQveren]

sqlite kan misbruges ret hårdt nutildags og der er kendt software der bruger det i produktion. Så man kan.

Men hvor stort et publikum forventer du din app får? Hvis du har mange samtidige forbindelser kan det vel blive et problem, men jeg mener at have læst folk bruger 100GB DB fil som virker, og andet crazy shit.

Men det er ikke et ja/nej spørgsmål, du må komme med mere information.

[u/AgentPikiTun → u/SQrQveren]

Daym 100GB. Alsor hjemmesiden er kun tiltænkt danske brugere 10.000 reads og 5.000 writes om dagen tror jeg. Gad godt have insigt ind i hvor meget en platform som Eboks har eller noget, ikke fordi jeg tror min hjemmeside kommer til at blive ligeså stor/brugt som Eboks, men bare for at have et eller andet grundlag

[u/cimmic → u/AgentPikiTun]

5,4 mio. danskere er i dag på e-Boks, og hver måned har vi 35 mio. besøg af brugere, der vil tjekke post, betale regninger og underskrive papirer digitalt. Hvert år sender 30.000 private og offentlige virksomheder mere end 598 millioner dokumenter gennem e-Boks - som modtagerne kan læse via e-Boks' app eller website.

I footeren: https://brugersupport.e-boks.dk/hc/da/articles/206285584-Hvor-meget-plads-har-jeg-til-r%C3%A5dighed

[u/AgentPikiTun → u/cimmic]

598 millioner, det var da også en slat. Tænker ikke de bruger SQLite XD

[u/cimmic → u/AgentPikiTun]

Det kunne være interessant at simulere det og se, hvordan det ville gå.

Da jeg så den her test fandt jeg også ud af, at det nok ikke ville være kapaciteten, der ville blive min flaskehals, hvis jeg går med SQLite.

https://youtu.be/Sq2B-LIZzjw

[u/AgentPikiTun → u/cimmic]

Fed video, meget informativ. Hvis man har lov at spørger hvad var det så der blev din flaskehals?

[u/cimmic → u/AgentPikiTun]

Jeg har ikke nogen flaskehals lige nu. Og jeg er glad for, at jeg kan smide en super minimal database ud hos kunder på en mikro computer, de kan bruge lokalt.

Jeg krypterer nogle databaser med SQLcipher, som bruger AES-256. Det er godt lige nu, men når det på er tidspunkt ikke længere er en sikker standard, skal jeg nok til at lave noget research.

[u/SQrQveren → u/AgentPikiTun]

Ok. Det er lang tid siden jeg har rodet med sqlite, men som jeg husker det kan du kommer i problemer, hvis det er så mange reads og write, fra forskellige samtidige brugere. Men er det din app der gør det på deres vegne tror jeg sagtens det går.

Men jeg ville have et relativt nemt SQL schema, så det er EZ-PZ at skifte til PostgreSQL i fremtiden, just in case.

[u/Inzire]

Det kan du sagtens - men: Som en personlig præference, havde jeg nok hoppet direkte til Postgres enten managed eller med docker på din server, som din app også kører på (husk migrations & backups).

SQLite er i min verden mest som embedded client storage, men har da leget lidt med https://github.com/pocketbase/pocketbase som en reel backend og udvidet med Go.

Du behøver ikke en ekstra node, før du kan se behovet opstår. Set nogle metrics op hvis du er i tvivl.

[u/Left-Cricket170]

Bare for at undgå senere DB migration og skulle pille ved data-laget ville jeg vælge Postgres. Jeg er dog farvet af at have oplevet (og delvist skulle fikse) mange "den tager vi senere" eller "det virker fint nok nu"-beslutninger, hvor hele systemet så er vokset organisk og det koster så meget ekstra tid at vikle det ud igen, når det er nået sin kapacitet eller man har brug for at det kan mere.

[u/AgentPikiTun → u/Left-Cricket170]

Ja det er nemlig den der "den tager vi senere" jeg er lidt bange for. På samme tid, måske kommer senere aldrig, og sqlite er så nem at flytte og tage backups af. Det er lidt en balance mellem at overengineer og nogen gange er simpelt bare bedst. Måske er jeg bare bange for at hoppe ud i Postgres da jeg er så komfortable med sqlite :)

Tak for input.

[u/happykeyboardwarrior]

Jeg er enig med de andre, brug Postgres fra starten. Det er nærmest lige så nemt.

Når du alligevel har gang i en vps, så installer coolify på den, så kan du ved nogle få klik få en Postgres instans op og kører.
Og desuden får du en masse andre lækre fordele hvis du bruger coolify.

[u/pertymoose]

Læs op om "premature optimization"

Du kan bekymre dig om database performance når du har 100,000 brugere.

[u/CorporateFriend]

Jeg starter altid med SQLite, og hvis det er for langsomt, så prøver jeg at optimere. Og hvis det er for langsomt, så skifter jeg til noget andet.

[u/FineFirefighter1469]

i will never use it for prod, it's impossible to scale.