Ask Lemmy
A Fediverse community for open-ended, thought provoking questions
Please don't post about US Politics.
Rules: (interactive)
1) Be nice and; have fun
Doxxing, trolling, sealioning, racism, and toxicity are not welcomed in AskLemmy. Remember what your mother said: if you can't say something nice, don't say anything at all. In addition, the site-wide Lemmy.world terms of service also apply here. Please familiarize yourself with them
2) All posts must end with a '?'
This is sort of like Jeopardy. Please phrase all post titles in the form of a proper question ending with ?
3) No spam
Please do not flood the community with nonsense. Actual suspected spammers will be banned on site. No astroturfing.
4) NSFW is okay, within reason
Just remember to tag posts with either a content warning or a [NSFW] tag. Overtly sexual posts are not allowed, please direct them to either [email protected] or [email protected].
NSFW comments should be restricted to posts tagged [NSFW].
5) This is not a support community.
It is not a place for 'how do I?', type questions.
If you have any questions regarding the site itself or would like to report a community, please direct them to Lemmy.world Support or email [email protected]. For other questions check our partnered communities list, or use the search function.
Reminder: The terms of service apply here too.
Partnered Communities:
Logo design credit goes to: tubbadu
view the rest of the comments
I've used sqlite for structured storage by scripts and the like. From a performance standpoint, it's not amazing, but easy to set up and doesn't have resource usage if it's not actually being used.
If I were going to use an always-active daemon, I'd probably default to PostgreSQL, mostly because decades back, the last time I looked at it, it was considered to have some technical advantages over MySQL. And at one point I did some hacking on its scheduler, so I have a bit of a warm feeling for it.
I probably wouldn't think of things as "server" hardware" and "desktop" hardware. That's really a product of vendors trying to segment the market up, which lets them engage in price discrimination, as business buyers tend to be less price sensitive. Maybe you want more memory or a faster form of storage or something.
As to performance, I mean, it depends entirely on your use case. I would guess that the vast majority of database-using software out there has performance be a non-issue.
If you're looking for potential land mines, I'd suggest making sure that your backup system is aware of the database and can take an atomic snapshot, so that you don't get a garbled, being-written copy every time you do a backup.
If you're trying to figure out whether to buy a lot of hardware, though, I can tell you that without knowing what you're doing, I would not go out and buy new hardware just over performance concerns until you've actually tried doing your project on existing stuff and found that it's inadequate. People have run useful, large databases for many decades on much weaker hardware and slower storage than is generally-available in 2024.
(•̪ o •̪)