Author: René Wagner <email@example.com>
Date: Sat, 9 Jan 2021 17:04:13 +0100
database choice in hosting.gmi
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/hosting.gmi b/hosting.gmi
@@ -17,10 +17,10 @@ I prefer the KISS principle, thus i use a very simple partitioning scheme with e
-=> https://debian.org Debian Buster with Backports
-=> https://apache.org Web & Reverse proxy: Apache 2 (PHP-FPM)
-=> https://mmonit.com/monit Monitoring: monit
-=> https://git.sr.ht/~sircmpwn/gmnisrv Gemini: gmnisrv
+* Debian Buster with Backports
+* Web & Reverse proxy: Apache 2 (PHP-FPM)
+* Monitoring: monit
+* Gemini: gmnisrv
@@ -33,8 +33,15 @@ I prefer the KISS principle, thus i use a very simple partitioning scheme with e
-=> https://nextcloud.com private Nextcloud instance including TURN server
-=> https://selfoss.aditu.de private selfoss instance
+* private Nextcloud instance including TURN server
+* private selfoss instance
+When running services anyone will eventually come to the point to persist data and therefor needs some kind of database.
+For the services mentioned above i've opted for the serverless, light weight SQLite option. I think this database is a great way for small or medium traffic services with mostly read access. It does not require any additional server software to be set up and can be backed up liked any other file.
+There are obviously some shortcomings to this concept. Write-intense use cases with heavy concurrent writes won't be suitable. You can't have advanced features like "point in time" restore or a high availability setup.
+But all of this feature have absolutely no meaning for my small-sized private hosting. For this use case, the additional complexity of running an entire DBMS is much more burden then the restrictions of SQLite.