Promscale is the open source observability backend for metrics and traces powered by SQL.
Whereas Mimir/Cortex is designed only for metrics.
Key differences:
1. Promscale is light in architecture as all you need is Promscale connector + TimescaleDB to store and analyse metrics, traces where as Cortex comes with highly scalable micro-services architecture this requires deploying 10's of services like ingestor, distributor, querier, etc.
2. Promscale offers storage for metrics, traces and logs (in future). One system for all observability data. whereas the Mimir/Cortex is purpose built for metrics.
3. Promscale supports querying the metrics using PromQL, SQL and traces using Jaeger query and SQL. whereas in Cortex/Mimir all you can use is PromQL for metrics querying.
4. The Observability data in Cortex/Mimir is stored in object store like S3, GCS whereas in Promscale the data is stored in relational database i.e. TimescaleDB. This means that Promscale can support more complex analytics via SQL but Cortex is better for horizontal scalability at really large scales.
5. Promscale offers per metric retention, whereas Cortex/Mimir offers a global retention policy across the metrics.
Hi. I'm a Mimir maintainer. I don't have hands-on/production experience with Promscale, so I can't speak about it. I'm chiming in just to add a note about the Mimir deployment modes.
> Cortex comes with highly scalable micro-services architecture this requires deploying 10's of services like ingestor, distributor, querier, etc.
Mimir also supports the monolithic deployment mode. It's about deploying the whole Mimir as a single unit (eg. a Kubernetes StatefulSet) which you then scale out adding more replicas.
Promscale supports reporting/ingestion of data using Prometheus remote-write for metrics, OTLP (OpenTelemetry Line Protocol) for traces.
Dashboards you can use Promscale as Prometheus datasource for PromQL based querying, visualising, as Jaeger datasource for querying, visualising traces and as PostgreSQL datasource to query both metrics and traces using SQL. If you are interested in visualising data using SQL, we recently published a blog on visualising traces using SQL (https://www.timescale.com/blog/learn-opentelemetry-tracing-w...)
Alerts needs to be configured on the Prometheus end, Promscale doesn't support alerting at the moment. But expect the native alerting from Promscale in the upcoming releases.
If you are interested in evaluating, setting up Promscale reach out to us in Timescale community slack(http://slack.timescale.com/) in #promscale channel.
I’m looking into choosing a backend for my metrics and always open for suggestions.