Very happy with it. I’m running it with an SQLite database, so no extra database server is needed. And I’m using Elk as a frontend for when I don’t feel like using an app.
I’ve only run docker containers with their own db. It sounds more logical to run one db, right? My only concern would be if that db corrupts then they all do.
Ohh, SQLite isn’t “one” db. SQLite is file-based. I.e. a database in e.g. PostgreSQL (containing several tables, views, indexes, etc.) would translate to one SQLite file (e.g. mydatabase.db3 or myappdata.sqlite). And each app has its own file/database. If the file corrupts, then it’s only affecting that specific app. (However, SQLite is pretty robust.) And since these are just files, you can backup them together with the application. No need to export data or shutdown the database first.
Very happy with it. I’m running it with an SQLite database, so no extra database server is needed. And I’m using Elk as a frontend for when I don’t feel like using an app.
Oh that’s very nice! Do you use that db for other services too?
Whenever it is supported, yes. I’m a huge fan of SQLite.
I’ve only run docker containers with their own db. It sounds more logical to run one db, right? My only concern would be if that db corrupts then they all do.
Why do you like that over postgresql
Ohh, SQLite isn’t “one” db. SQLite is file-based. I.e. a database in e.g. PostgreSQL (containing several tables, views, indexes, etc.) would translate to one SQLite file (e.g.
mydatabase.db3ormyappdata.sqlite). And each app has its own file/database. If the file corrupts, then it’s only affecting that specific app. (However, SQLite is pretty robust.) And since these are just files, you can backup them together with the application. No need to export data or shutdown the database first.That’s very helpful! Thank you for taking the time to explain