Hi everyone !

Intro

Was a long ride since 3 years ago I started my first docker container. Learned a lot from how to build my custom image with a Dockerfile, loading my own configurations files into the container, getting along with docker-compose, traefik and YAML syntax… and and and !

However while tinkering with vaultwarden’s config and changing to postgresSQL there’s something that’s really bugging me…

Questions

  • How do you/devs choose which database to use for your/their application? Are there any specific things to take into account before choosing one over another?
  • Does consistency in database containers makes sense? I mean, changing all my containers to ONLY postgres (or mariaDB whatever)?
  • Does it make sense to update the database image regularly? Or is the application bound to a specific version and will break after any update?
  • Can I switch between one over another even if you/devs choose to use e.g. MariaDB ? Or is it baked/hardcoded into the application image and switching to another database requires extra programming skills?

Maybe not directly related to databases but that one is also bugging me for some time now:

  • What’s redis role into all of this? I can’t the hell of me understand what is does and how it’s linked between the application and database. I know it’s supposed to give faster access to resources, but If I remember correctly, while playing around with Nextcloud, the redis container logs were dead silent, It seemed very “useless” or not active from my perspective. I’m always wondering “Humm redis… what are you doing here?”.

Thanks :)

  • @TechLich
    1•29 days ago

    I’d add to this to say that redis as a key-value store often sits alongside a relational database like postgres etc. to act as a cache for it.

    Basically, requests to be sent to the relational db (like postgres) get turned into a key and the results stored as a value in redis. Then when the same request comes through again, it can pull the results quickly out of the key-value store without having to search postgres by running a long SQL query again. There’s a few different caching strategies to keep things up to date or have the cached data expire regularly, etc. but that’s the gist of it.

    Important to note that not all applications need something like that and not all queries would even benefit from it (postgres is pretty fast and can even do that kind of thing itself) but if there’s a lot of users running the same slow query over and over, caching the results can help immensely.