Comment on 18% of people running Nextcloud don't know what database they are using
Ajen@sh.itjust.works 21 hours ago
I write software for a living, and have worked with all 3 database options in the past. I don’t know what DB backend my nextcloud server is using, nor do I care.
dustyData@lemmy.world 21 hours ago
Yeah, that is the kind of concern for the service developer or a very opinionated sys admin. For self-hosting, few people will reach the workload where such a decision has any material or measurable impact.
stardreamer@lemmy.blahaj.zone 20 hours ago
Exactly. Unless you are actively doing maintenance, there is no need to remember what DB you are using. It took me 3 minutes just to remember my nextcloud setup since it’s fully automated.
It’s the whole point of using tiered services. Do you also worry about your wifi link-level retransmissions when you are running curl?
IncogCyberspaceUser@lemmy.world 10 hours ago
Sorry for the newbie question, but how is your nextcloud setup automated? Is that like a compose/yaml file?
u_tamtam@programming.dev 21 hours ago
Self hosting doesn’t mean “being wasteful and letting containers duplicate services”. I want to know which DB application X is using, so I pool it for applications Y and Z.
Ajen@sh.itjust.works 20 hours ago
For most applications the overhead of running a second DB server is negligible.
absentbird@lemmy.world 19 hours ago
And if it’s SQLite (which I believe is the default) it’s really just reading and writing a file on the file system.
tburkhol@lemmy.world 8 hours ago
This is one of my pet peeves with containerized services, like why would I want to run three or four instances of mariadb? I get it, from the perspective of the packagers, who want a ‘just works’ solution to distribute, but if I’m trying to run simple services on a 4 GB RPi or a 2 GB VPS, then replicating dbs makes a difference. It took a while, but I did, eventually, get those dockers configured to use a single db backend, but I feel like that completely negated the ‘easy to set up and maintain’ rationale for containers.
u_tamtam@programming.dev 5 hours ago
Precisely what pre-devops sysadmins were saying when containers were becoming trendy. You are just pushing the complexity elsewhere, and creating novel classes of problems for yourself (keeping your BoM in control and minimal is one of many others that got thrown away)