Sunshine: use sqlite db for persistent data #87

Activity

1. ReenigneArcher

   added

   plannedThis work is plannedThis work is planned

   on Jun 28, 2025
2. ReenigneArcher

   added the

   Task

   issue type on Jun 28, 2025
3. github-project-automation

   added this to roadmapon Jun 28, 2025
4. github-project-automation

   moved this to Todo in roadmapon Jun 28, 2025
5. LizardByte-bot

   added

   LizardByte/Sunshine

   C++

   SQL

   effort:Large

   priority:Medium

   6+ monthsEstimated completion in 6+ monthsEstimated completion in 6+ months

   on Jun 28, 2025
6. jorys-paulin commented on Aug 11, 2026

   

   jorys-paulin

   on Aug 11, 2026

   More actions

   Honestly for a project like Sunshine I don't think you need to bother. SQL is very powerful, especially at scale, but it also comes with a lot of overhead. Just making all the data structures fit in columns can be additional work, like prep commands would need their own table in addition to the applications table, and of course a third table to link the other two.
   I think you can still get away with regular config/data files, that's what most of the self-hosted apps I know use as well. You can use version fields for breaking changes if need be, and for testing you can have "golden" files for reference.
   It is a shame that not everything is stored in the one file, but I feel like it's too late to change this now, the opportunity for it was about five years ago now.
7. Kishi85 commented on Oct 18, 2026

   

   Kishi85

   on Oct 18, 2026

   Last edited by Kishi85

   More actions

   I can see merit in @jorys-paulin mentions here as using SQLite would make things much more complex. This is especially true if you want to manually tinker during development where just editing a simple text file is just so much easier to control and restore compared to having to deal with SQL. An easily human-readable format (JSON/YAML/TOML/etc.) for configuration files is likely always better for issue reporting as well where the end-user can (be asked to) just upload a possible redacted configuration file instead of having to deal with SQL which would likely overwhelm them (and uploading the whole sqlite-DB with a report would likely cause privacy/security issues).

   IMHO the current situation can be easily improved by switching to a well-defined file/directory structure below sunshine's config directory root instead of throwing everything into one state file as it is now. Example (assuming JSON-based config files):

   <sunshine_configuration_root>
   |-> config.json
   |-> global.json  (containing things like salt, web-ui passwords, etc.)
   |--> apps
   | |-> desktop.json  (containing app specific settings, named for default entries, one file per app)
   | |-> steam.json
   | |-> 5b70a28b-0fd7-427d-a882-6292e69c92c0.json (using UUID4 here would allow for unique user entries).
   | ...
   |--> clients
   | |-> 0ed4baff-0e32-4721-882a-cfa76504fac9.json (using UUID4 here to make client files unique, one file per client)
   |  ...
   ...
   

   This should follow the configuration format picked for #25 to keep things persistent.
   As for the app-id's mentioned I'd say it be as good to just go with standard UUID4 instead of an auto-incrementing integer.

   EDIT: You could even go as far as using a separate subdirectory per client/app and just put different files into each of those directores (e.g. separate,proper certificate files for client certificates)