Niklas

Already implemented.

An alternative approach would be to migrate the persistence code to Hibernate instead. Looking at how much code is involved in the [`hibernate-orm`](https://github.com/quarkusio/quarkus/tree/main/extensions/hibernate-orm) extension, I'm not sure doing the same...

Another challenge with dynamic configuration is that we need a mechanism to notify services about changes that are impacting them. For example, when an API key for Snyk is changed,...

As per further discussion, Postgres' `LISTEN` / `NOTIFY` mechanism is **not** a good option, as it won't work across replicas. We specifically chose to make DB interactions of services read-only...

Another complication with the approach above: If we're assuming that database read replicas are being used, we'll run into race conditions: * User updates configuration via UI * API server...

Given there is no way to achieve a truly consistent view of configurations for all applications in the system, without: * Performing excessive database queries (i.e. at least one per...

On the Quarkus side of things, I'm thinking we should plug into the existing config framework: https://quarkus.io/guides/config-extending-support#custom-config-source By the looks of it, this can also be made to support reloads...

Tagging as good first issue since it's a purely technical task that doesn't require too much knowledge of the code base. This task involves the creation of a CLI tool...

Thanks for the suggestion @prabhu, will definitely have a look! If we end up pulling in a pre-compiled / curated database, what would be great to have is the possibility...

Apologies for the delay. The compression definitely is a good thing here, thanks for pointing it out! Regarding the `source_data_hash`, what would be even more helpful would be a `updated_at`...