commit 577142d76fb61b3344e3bad9492746c59f200cc7
parent 4f4e2848abe4ca0486b8c13a0b9685c2563736e9
Author: René Wagner <rwagner@rw-net.de>
Date: Sat, 9 Jan 2021 17:04:13 +0100
database choice in hosting.gmi
Diffstat:
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
## tooling
-=> 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
## services
@@ -33,8 +33,15 @@ I prefer the KISS principle, thus i use a very simple partitioning scheme with e
### web
-=> https://nextcloud.com private Nextcloud instance including TURN server
-=> https://selfoss.aditu.de private selfoss instance
+* Gitea
+* private Nextcloud instance including TURN server
+* private selfoss instance
+
+Database choice
+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.
### other
