> I mean no slander or disrespect to anyone involved, but there was a DataDog alternative posted sometime in the last few weeks that had a docker-compose with l

> I mean no slander or disrespect to anyone involved, but there was a DataDog alternative posted sometime in the last few weeks that had a docker-compose with like 15 containers in it. If this was us [1] (an OSS Datadog alternative posted last week :D ), we do have quite a bit (11, 2 are optional) but we're working on bringing it down. We currently split our ingestion pipeline into 3 independently scalable bits, but we can probably bring it down into 1 for any small-scale deployment. Otherwise we do have the standard need for a cache (redis), db (mongo), main storage (clickhouse), and then the standard API server + frontend, and a separate task to run alerts. There's likely a few more things we can merge together, but it comes at the expense of making it unscalable to workloads typical to a company and divergence in the code base, which overall doesn't seem like the right tradeoff. Imo the real concern as someone that personally owns too many tiny VM instances is resource footprint - which can be tuned down to ~1GB of memory for us (depending on server load). Feel free to open an issue too if you think there's something we can adjust there as well. [1] https://github.com/hyperdxio/hyperdx https://github.com/hyperdxio/hyperdx