Du könntest das Setup doch einfach mal in einer lokalen VM bei dir testen (VirtualBox, VMware Workstation oder so etwas in die Richtung). Da könntest du dann direkt testen, ob der Service mit 1GB RAM überhaupt läuft, ohne überhaupt ein VPS buchen zu müssen. Als Ressourcen Test sollte das ja reichen. Wenn es klappt, kannst du das Setup ja dann immer noch auf dem VPS aufsetzen. Aber so kannst du zumindest sicher sein, dass der RAM an sich ausreicht, oder eben nicht und ob du direkt auf einen größeren VPS gehen müsstest.
Netcup hat 14 Tage Widerrufsrecht wie andere Online-Angebote auch (geht bequem übers CCP, sofort wirksam). Du musst aber ggf. in Vorleistung treten und erstmal die Rechnung bezahlen und bekommst dann eine Gutschrift.
Hi, es kommt ganz auf das OS, sowie dein gesamter traffic den du durchziehen möchtest. Es hängen relativ viele Faktoren dran.
Gehen wir mal von Szenario A aus:
Selbsthosten hand voll Dienste und ab und zu aus der Ferne mal drauf zugreifen, weil willst hier und da mal was nachschauen, wird vermutlich gerade so ausreichen mit sqlite statt postgres.
Szenario B:
Sobald du mehr als eine Handvoll Dienste laufen hast und vorallem auch aktiv über die Verbindung was arbeiten willst oder Daten hin und her schieben willst, dann reicht das ganze leider nicht mehr. Auch wenn du postgres als DB möchtest, wird das ganze ganz schön knapp.
Falls du noch relativ neu bist im selfhosting Game und kaum was verstanden hast, dann nimm als einfache Empfehlung mindestens 2gb Ram 
.
Warum soll er denn PostgreSQL wollen sollen – pangolin läuft von Anfang an mit sqlite!?
Warum soll er denn PostgreSQL wollen sollen – pangolin läuft von Anfang an mit sqlite!?
Klar, und weil ein Raspberry Pi ab Werk mit SD-Karte läuft, hat noch nie jemand eine NVMe angeschlossen. 😉 Nur weil SQLite der kleinste gemeinsame Nenner für den schnellen Start ist, heißt das nicht, dass man ein Setup nicht direkt performant und produktionsreif planen darf. Solange wir sein genaues Vorhaben nicht kennen, liefere ich ihm lieber eine vernünftige Entscheidungsgrundlage, statt den Horizont künstlich bei den Werkseinstellungen enden zu lassen.
Das dauert noch ein bisschen bis die Leute begreifen das SQLite performant und produktionstauglich ist.
Das dauert noch ein bisschen bis die Leute begreifen das SQLite performant und produktionstauglich ist.
Rhetorik oder ernst gemeint? Falls ernst gemeint, kannst du das weiter ausführen, wie du zu dieser Annahme kommst?
Mein ich ernst und nein, Blödsinn (rhetorisch) wie Shopify gehört nicht zu den Use Cases.
We created a Sinatra (ruby) solution which caches production data using SQLite, and then compared it to a similar solution using Redis, using siege to stress the two systems and then compared the numbers:
| Throughput (rpm) | Response time (ms) | |
| SQLite | 1800 | 6 |
| Redis | 250 | 150 |
SQLite is best suited for production use in applications that:
These criteria describe a significant percentage of web applications, internal tools, and even customer-facing products. But teams often dismiss SQLite because it doesn’t match their mental model of what a “serious” database looks like.
In deinem eigenen Text steht völlig korrekt, wann SQLite passt: ‚read-heavy but not write-heavy‘ und wenn man kein ‚multiversion concurrency‘ (MVCC) braucht. Während das auf die in deinem Zitat genannten ‚web applications‘ aus deiner Webdesign-Bubble wunderbar zutrifft, ist ein zentraler Reverse-Proxy mit aktivem Access- und Tunnel-Logging unter Last eben kein Sinatra-Web-Cache, sondern massiv write-heavy. Genau wegen des Single-Writer-Locks von SQLite bietet Pangolin nativen Postgres-Support inklusive ausgelagerter postgres_logs-DB und Read-Replicas an.(Mal ganz abgesehen davon, dass ein Benchmark, in dem Redis angeblich nur 250 rpm bei 150 ms schafft, ohnehin unfreiwillig komisch ist). Wer natürlich nur in den Dimensionen einzelner Webseiten denkt, für den bleibt eine lokale Datei selbstverständlich der Gipfel der Enterprise-Infrastruktur.
Mein ich ernst und nein, Blödsinn (rhetorisch) wie Shopify gehört nicht zu den Use Cases.
We created a Sinatra (ruby) solution which caches production data using SQLite, and then compared it to a similar solution using Redis, using siege to stress the two systems and then compared the numbers:
Throughput (rpm) Response time (ms) SQLite 1800 6 Redis 250 150 SQLite is best suited for production use in applications that:
- Desire fast and simple setup
- Require high reliability in a small package
- Have, and want to retain, a small footprint
- Are read-heavy but not write-heavy
- Don’t need multiple user accounts or features like multiversion concurrency snapshots
These criteria describe a significant percentage of web applications, internal tools, and even customer-facing products. But teams often dismiss SQLite because it doesn’t match their mental model of what a “serious” database looks like.
Ja wie schon gesagt - SQLite ist das schnellste und beste wo gibt - aber passt nicht immer
Ja wie schon gesagt - SQLite ist das schnellste und beste wo gibt - aber passt nicht immer
Du wirst noch deinen HTML Seiten untreu, wenn du dich jetzt schon für Datenbanken interessierst.
Neu erstellte Beiträge unterliegen der Moderation und werden erst sichtbar, wenn sie durch einen Moderator geprüft und freigeschaltet wurden.
