By Tiger Data Team
Updated at Jun 1, 2026
Prometheus does a lot of things well. Its pull-based scraping model is lightweight, its Alertmanager ecosystem handles complex routing, and its Kubernetes integration is tight enough that it ships as the default metrics backend for most clusters. If you're running a small to mid-size infrastructure with Grafana dashboards and PromQL alert rules, Prometheus works exactly as advertised.
But teams hit ceilings with Prometheus. High-cardinality workloads chew through RAM faster than most platform teams can provision it. Extending retention past the 15-day local default requires adding Thanos or Mimir, which turns a simple scraping tool into a multi-component platform. And PromQL, while purpose-built for dashboard queries and alert evaluation, cannot join metrics against application data or run arbitrary SQL aggregations.
When those ceilings get close, teams start evaluating alternatives.
Prometheus alternatives are tools that replace or extend Prometheus for long-term metrics storage, high-cardinality workloads, SQL-based analytics, or fully managed observability. The right choice depends on whether your team needs PromQL compatibility, SQL querying, managed operations, or unified metrics and traces in one platform.
This guide covers nine alternatives: open-source drop-ins, enterprise-scale backends, managed SaaS options, and the SQL-native path for teams already on PostgreSQL. One of those nine is Tiger Data's own products, TimescaleDB and Tiger Cloud. We'll say that upfront and cover each option fairly, including cases where our product is not the right fit.
The guide covers why engineers look for Prometheus alternatives, how to evaluate them, per-tool analysis of all nine options, a full comparison table, a decision framework, and a technical deep-dive on using TimescaleDB as a Prometheus long-term storage backend.
For more context on how Prometheus fits into the broader metrics landscape, see our guide on Prometheus vs. OpenTelemetry metrics and the four types of Prometheus metrics.
Prometheus was designed for real-time scraping and alerting, not long-term metrics storage or analytical queries. Teams who hit its limits are not using it wrong. They're using it at a scale or for a purpose it wasn't optimized for.
Single-node Prometheus reliably struggles past roughly 10 million active series. This is not a theoretical threshold. Community reports consistently show RAM climbing from 8 GB to 32 GB or more when a single high-cardinality label - a per-request trace ID, for example - gets added in a Kubernetes environment.
Kubernetes accelerates the problem. Pod labels, namespace labels, and rolling deployments multiply active series counts faster than traditional infrastructure monitoring. A deployment that looks fine at 100 nodes can tip past the cardinality limit at 300 with the same labeling strategy.
This is an architectural constraint of Prometheus's local TSDB design, which optimizes for query speed over cardinality breadth. It's not a bug, and it's not something you tune your way out of past a certain point.
Prometheus stores data locally for 15 days by default. Extending retention to 90 days, a year, or longer requires one of two approaches: significantly more local disk and RAM, or adding a remote storage backend.
Thanos, Mimir, Cortex, and TimescaleDB all enter here as remote storage options. The "add Thanos" path is common enough that it has a well-documented cost profile: community estimates for the SRE headcount cost of operating a production Thanos or Mimir cluster with a dedicated platform team range into the hundreds of thousands of dollars annually. That's the ops tax of long-term retention.
For teams already running PostgreSQL, routing metrics to TimescaleDB via remote_write eliminates the need for a separate long-term storage layer entirely. More on this in the TimescaleDB section below.
PromQL is purpose-built for time-series dashboards and alert rule evaluation. It cannot join metrics against application data. If you want to ask "did revenue drop when p99 latency spiked?" across two data sources, PromQL cannot answer that question. You need a backend with SQL support.
This is not a use case Prometheus was designed to serve. Engineers who need SQL analytics on metrics need a different backend, not a Prometheus workaround.
Federation and remote_write at scale require significant tuning. High-availability Prometheus setups - two scrape nodes, deduplication across them - add operational complexity that grows quickly with team size. Many teams start with Prometheus because it's easy to deploy and end up with a homebuilt HA setup that a dedicated alternative would handle natively.
These are the criteria worth evaluating before committing to a backend. For most teams, Prometheus compatibility and long-term storage model are the two most important. The others follow from those decisions.
Criterion | Why it matters |
Prometheus compatibility | Does it support |
Long-term storage model | How does the system handle data older than the scrape window? Is it native, or does it require a separate component? |
SQL support | Can you query metrics with standard SQL, or is a proprietary query language required? |
Cardinality handling | What is the practical upper bound on active series before performance degrades? |
Operational complexity | How many components does a production deployment require? What does failure recovery look like? |
Pricing model | OSS vs. managed service vs. per-host vs. per-series. At what scale does cost become prohibitive? |
Grafana compatibility | Does it work as a Grafana data source natively? Most Prometheus shops use Grafana for dashboards. |
Nine alternatives follow: three open-source Prometheus-compatible backends, one predecessor, one unified observability platform, two managed SaaS options, one purpose-built time-series database, and one SQL-native storage backend.
Promscale, Tiger Data's previous first-party Prometheus connector, was deprecated in February 2023. The current integration path uses the open-source community prometheus-postgresql-adapter. The TimescaleDB section below covers this in full, including why the deprecation is not a gap in the integration story.
VictoriaMetrics is an open-source, single-binary time-series database designed as a Prometheus-compatible drop-in. Apache 2.0 licensed.
Pricing: Free for self-hosted. VictoriaMetrics Cloud is the managed offering.
Query language: MetricsQL, a PromQL superset. All existing Prometheus queries work. VictoriaMetrics adds functions Prometheus doesn't have.
Best for: Teams that want to keep their PromQL dashboards and alert rules, fix cardinality and retention problems, and minimize operational complexity.
Strengths: Community benchmarks have reported 10-20x better RAM efficiency versus Prometheus at equivalent series counts. Handles hundreds of millions of active series. Single binary for single-node deployments. The vmagent component can replace Prometheus scraping entirely. Documentation is thorough and community support is active.
Limitations: MetricsQL is not identical to PromQL. Edge cases differ around native histograms and specific PromQL functions. No SQL support. Multi-tenancy requires VictoriaMetrics Cluster, which adds components.
Deployment: Single binary (single-node) or cluster mode. Docker, Kubernetes via Helm chart, or binary install.
VictoriaMetrics is often compared to Grafana Mimir for large-scale deployments. For teams with a dedicated platform team, Mimir v3.0 (November 2025) is the more enterprise-capable option. For most other teams, VictoriaMetrics is the simpler, lower-overhead choice.
Grafana Mimir is a horizontally scalable, multi-tenant Prometheus backend. Open source under AGPL-3.0. The reference enterprise open-source Prometheus alternative.
Pricing: Free for self-hosted. Grafana Cloud includes a managed Mimir offering.
Query language: PromQL native. Full compatibility.
Best for: Large engineering organizations with a platform team that needs multi-tenant, horizontally scalable Prometheus storage.
Strengths: Unlimited cardinality in the cluster design. Native multi-tenancy. Mimir v3.0 (November 2025) introduced two major changes: a decoupled architecture with Apache Kafka as an async buffer between ingestion and query paths, and a new Mimir Query Engine (MQE) that streams query results rather than loading full datasets into memory, reducing peak query memory usage by up to 92%. Together, these changes cut resource usage by around 15% at large cluster sizes. Integrates natively with the full Grafana stack, including Loki and Tempo.
Limitations: Operationally complex. A production Mimir deployment requires multiple components: ingesters, queriers, compactors, store-gateways, and distributors. Recommended only for teams with SRE capacity to operate it properly. No SQL support.
Deployment: Kubernetes via Helm chart. Not designed for single-binary deployment.
Mimir evolved from Cortex, covered below. Teams currently on Cortex should evaluate Mimir v3.0 as a migration target.
Thanos is an open-source sidecar layer for Prometheus that adds long-term storage, global querying across multiple Prometheus instances, and high availability. It sits on top of Prometheus, not replacing it.
Pricing: Free. Community open source.
Query language: PromQL via Thanos Querier, which queries across Prometheus instances and object storage.
Best for: Teams that want to keep their existing Prometheus setup and add long-term retention without migrating to a new storage engine.
Strengths: Minimal migration risk. Prometheus keeps running as-is. Adds object storage (S3, GCS, Azure Blob) as a long-term backend. Provides a global query view across federated Prometheus instances. Strong community.
Limitations: Adds operational components: Sidecar, Store Gateway, Compactor, Querier, Ruler. Not a simplification - it extends the Prometheus stack with more moving parts. Query latency from object storage is higher than in-memory. No SQL support.
Deployment: Runs alongside Prometheus. Kubernetes typically required for production.
Thanos is the most common first step away from single-node Prometheus limitations. Mimir v3.0 and VictoriaMetrics are where teams often end up after outgrowing Thanos.
Cortex is the predecessor to Grafana Mimir: an open-source, horizontally scalable Prometheus backend and a CNCF Incubating project.
Pricing: Free. Community open source.
Query language: PromQL native.
Best for: Teams already running Cortex who are evaluating migration to Mimir. Net-new deployments should start with Mimir v3.0 instead.
Strengths: Battle-tested. Large existing user base. Supported by an active Cortex community.
Limitations: Mimir v3.0 has superseded Cortex on most dimensions - better query performance, simpler operations, and active development investment from Grafana Labs. New teams evaluating these options should start with Mimir.
Deployment: Kubernetes.
Cortex is included here for completeness, for teams with existing Cortex deployments weighing their migration options. Net-new deployments should evaluate Mimir first.
SigNoz is an open-source observability platform built on OpenTelemetry. It covers metrics, traces, and logs in a single product. MIT licensed for the community edition; enterprise features (SSO, RBAC) are under a proprietary Enterprise Edition license.
Pricing: Free for self-hosted. SigNoz Cloud is the managed offering.
Query language: PromQL-compatible for metrics. Custom UI for traces and logs.
Best for: Teams that want to replace Prometheus and their tracing and logging tooling in a single move. Best fit for greenfield observability stacks or teams adopting OpenTelemetry.
Strengths: Unified observability - metrics, traces, and logs - in one tool. OTel-native from the ground up. Growing community. ClickHouse-based storage provides strong cardinality handling.
Limitations: Prometheus compatibility is partial. remote_write is supported, but SigNoz is architecturally OTel-first, not Prometheus-first. Teams with deep Prometheus instrumentation face re-instrumentation effort. No SQL query interface.
Deployment: Docker Compose for development, Kubernetes for production. Requires ClickHouse.
Datadog is a fully managed commercial observability SaaS covering infrastructure metrics, APM, logs, synthetics, and more.
Pricing: Per-host pricing for infrastructure metrics, with add-ons per product. Custom pricing for enterprise.
Query language: Proprietary. Not PromQL native. Accepts Prometheus remote_write.
Best for: Teams that want a fully managed observability platform with zero operational overhead and have the budget to support per-host pricing at scale.
Strengths: Zero operations. Strong agent ecosystem. Best-in-class UX and dashboarding. Tight Kubernetes integration via DaemonSet agent. Extensive integrations.
Limitations: Cost scales with host count and can become prohibitive at large infrastructure footprints. At under 50 million active series, AWS Managed Prometheus or Google Cloud Managed Prometheus may be cheaper. Not open source - no data portability beyond export APIs.
Deployment: Managed SaaS. Agent-based collection.
New Relic is a commercial observability SaaS with a free tier. It covers APM, infrastructure metrics, logs, browser monitoring, and more.
Pricing: Data ingest-based (GB/month) rather than per-host. Free tier includes 100 GB/month.
Query language: NRQL (proprietary). Accepts Prometheus remote_write.
Best for: Teams evaluating managed observability who want consumption-based rather than per-host pricing. The ingest-based model is friendlier at high host count with lower data volumes.
Strengths: Ingest-based pricing can be more predictable than per-host at large fleet sizes. Strong APM capabilities. Broad integration ecosystem. Generous free tier.
Limitations: NRQL is proprietary, which creates lock-in risk if migration becomes necessary. Not open source.
Deployment: Managed SaaS.
InfluxDB is a purpose-built time-series database. Multiple versions are in active use: 1.x with InfluxQL (SQL-like), 2.x with Flux, and 3.0 with Apache Arrow-based storage and InfluxQL returning as the primary query language.
Pricing: Open source plus managed Cloud tiers. Cloud Serverless is usage-based. Cloud Dedicated is contract-based.
Query language: InfluxQL (1.x and 3.0), Flux (2.x, being deprecated in 3.0). Not PromQL native. remote_write is accepted in some configurations.
Best for: Teams with existing InfluxDB deployments evaluating a move from Prometheus. IoT and sensor data use cases.
Strengths: Purpose-built for time-series. Strong retention policy management. InfluxDB 3.0 significantly improved query performance compared to previous versions.
Limitations: Version fragmentation is a well-documented community pain point. InfluxDB 1.x, 2.x, and 3.0 are architecturally different products with different query languages - evaluating InfluxDB means deciding which version you're actually adopting. Flux, the 2.x query language, is a significant context switch from both InfluxQL and SQL, and it's being deprecated in 3.0. Prometheus compatibility is partial and configuration-dependent.
Deployment: Self-hosted or Cloud managed.
For teams considering InfluxDB, Tiger Data's guide to InfluxDB alternatives covers the migration landscape in detail.
TimescaleDB is Tiger Data's open-source PostgreSQL extension for time-series data. Tiger Cloud is the fully managed deployment. This is not a replacement for Prometheus's scraping and alerting layer. It's a long-term storage backend and SQL analytics layer for teams already on PostgreSQL.
Promscale note: Promscale, Tiger Data's previous first-party Prometheus connector, was deprecated in February 2023. See the Promscale deprecation announcement for details. The current integration path uses the open-source community prometheus-postgresql-adapter. The adapter is actively maintained and this is addressed in full in the technical section below.
Pricing: TimescaleDB core is Apache 2.0 licensed - free, self-hosted. Advanced features (compression, continuous aggregates) are under the Timescale License (TSL), which is also free for self-hosting. Tiger Cloud is usage-based managed PostgreSQL.
Query language: Standard SQL plus time-series extensions (time_bucket(), continuous aggregates). Not PromQL. Prometheus continues to handle scraping and alerting. TimescaleDB handles storage and analytical queries.
Best for: Engineering teams already running PostgreSQL that want to query Prometheus metrics with SQL, retain data for years without operational overhead, and join metrics against application data - orders, users, events, deployments.
Strengths:
Full SQL on metrics: join Prometheus data against any application table, run arbitrary aggregations, use existing PostgreSQL tooling
Hypercore columnstore compression delivers 90-98% storage savings on time-series data, enabling years-long retention at low cost
Grafana natively supports PostgreSQL and TimescaleDB as a data source - no plugin required
Tiger Cloud, the managed option, includes a free trial and eliminates database operational overhead
Continuous aggregates pre-compute rollups without a separate process
Data consolidation: application events, IoT data, and Prometheus metrics all live in the same PostgreSQL database, queryable together
On the "TimescaleDB is only for IoT" objection: TimescaleDB is in production for metrics, financial data, observability, and application event data. FlightAware reduced Prometheus metrics query times from 6.4 seconds to 30 milliseconds using TimescaleDB continuous aggregates. Time-series is a workload pattern, not a vertical.
Limitations: Not PromQL-compatible. Existing Prometheus dashboards continue to query Prometheus for real-time data. TimescaleDB handles the long-term analytical layer. Engineers who need PromQL for everything should use VictoriaMetrics or Mimir. The prometheus-postgresql-adapter adds a component to the write path that must be operated and monitored.
Deployment: Self-hosted PostgreSQL with TimescaleDB (Docker, Kubernetes, binary), or Tiger Cloud (fully managed, no operational overhead).
See also: The Best Time-Series Databases Compared (2026) and 5 Ways to Monitor Your PostgreSQL Database.
Tool | Open source | remote_write | PromQL support | SQL support | Multi-tenancy | Long-term storage | Managed option | Best for |
VictoriaMetrics | Yes (Apache 2.0) | Yes | MetricsQL (superset) | No | Cluster mode only | Native (disk-based) | VictoriaMetrics Cloud | PromQL compatibility at lower ops overhead |
Grafana Mimir | Yes (AGPL-3.0) | Yes | Native | No | Yes (native) | Native (object storage) | Grafana Cloud | Large-scale multi-tenant enterprise |
Thanos | Yes (Apache 2.0) | Via sidecar | Native | No | Partial | Object storage add-on | No | Least-disruptive Prometheus extension |
Cortex | Yes (Apache 2.0) | Yes | Native | No | Yes (native) | Native (object storage) | No | Existing Cortex deployments only |
SigNoz | Yes (MIT community) | Partial | Partial | No | Yes | ClickHouse-based | SigNoz Cloud | Unified metrics + traces + logs (OTel) |
Datadog | No | Yes | No (proprietary) | No | Yes | Managed | Datadog (SaaS) | Zero-ops managed observability |
New Relic | No | Yes | No (NRQL) | No | Yes | Managed | New Relic (SaaS) | Ingest-based pricing at high host count |
InfluxDB | Yes (MIT or Apache 2.0) | Partial | No (InfluxQL/Flux) | Partial | Yes (Cloud) | Native | InfluxDB Cloud | Existing InfluxDB deployments, IoT |
TimescaleDB / Tiger Cloud | Yes (Apache 2.0 core / TSL for advanced features) | Via adapter | No | Yes (full SQL) | Via PostgreSQL schemas | Native (PostgreSQL + Hypercore) | Tiger Cloud | SQL analytics on metrics, PostgreSQL teams |
Your answer depends on the team's priorities and constraints. This is a decision framework, not a ranking.
Choose VictoriaMetrics if simplicity and lower operational overhead are priorities. Single binary for small deployments. Handles cardinality and retention without adding components. The right choice for most teams with this requirement.
Choose Grafana Mimir v3.0 if the organization has SRE capacity to operate a multi-component system and needs enterprise-grade horizontal scale with multi-tenancy. Mimir's November 2025 release is a meaningful improvement over earlier versions.
Choose Thanos if migration risk is the primary concern and the existing Prometheus setup must stay in place. Thanos extends rather than replaces, which keeps rollback options open.
Choose Datadog if the requirement is zero operational overhead and budget accommodates per-host pricing. Datadog's UX and ecosystem lead the managed SaaS category.
Choose New Relic if ingest-based pricing is a better model for the fleet - high host count with manageable data volumes tends to favor New Relic's pricing structure over Datadog's.
Choose Grafana Cloud (managed Mimir) if the organization is committed to the open-source ecosystem and wants a managed option that keeps data in a format you understand.
Note the cost crossover: AWS Managed Prometheus and Google Cloud Managed Prometheus can be cheaper than Datadog at under 50 million active series, for teams already committed to those cloud providers.
Choose TimescaleDB (self-hosted) or Tiger Cloud (managed) when:
The team already runs PostgreSQL
Joining metrics against application data is a real requirement, not a theoretical one
Years-long retention is needed and the cost of Thanos/Mimir infrastructure is a concern
Data consolidation - metrics, events, application data in one queryable store - matters
Prometheus continues to handle scraping and real-time alerting. TimescaleDB is the long-term storage and analytics layer, not a full replacement.
One honest constraint: if PromQL dashboards are the primary interface and SQL analytics is not a real requirement, VictoriaMetrics is a better fit. TimescaleDB's SQL advantage matters most when analysts, application developers, and operations teams all need to query the same metrics data in ways PromQL cannot support.
Choose SigNoz for the open-source, OTel-native answer. Built on ClickHouse. Strong fit for teams going all-in on OpenTelemetry from a greenfield starting point.
Choose Datadog or New Relic for the managed answer with a broader feature set and more mature tooling.
This section covers the architecture, capabilities, and limitations in detail. If this isn't relevant to your setup, skip to the comparison table above.
The component topology looks like this:
Prometheus scrapes metrics and evaluates alert rules as normal. Via remote_write, it sends metrics to the prometheus-postgresql-adapter, an open-source community project (GitHub) that writes them into a TimescaleDB hypertable. Grafana connects to both Prometheus (for real-time data within the retention window) and TimescaleDB or Tiger Cloud (for historical data and SQL-based dashboards). For step-by-step setup instructions, see the Tiger Data Prometheus integration docs.
Each metric lands in a TimescaleDB hypertable with a time column, a name column, a labels JSONB column, and a value column. The hypertable is partitioned by time automatically - no manual partition management required. Grafana's PostgreSQL data source supports TimescaleDB natively, so SQL queries in Grafana's query editor target the hypertable directly. No plugin is required.
SQL joins on metrics. Join Prometheus metrics against application tables. For example:
SELECT
time_bucket('1 hour', m.time) AS hour,
avg(m.value) AS avg_latency,
sum(o.revenue) AS hourly_revenue
FROM metrics m
JOIN orders o
ON time_bucket('1 hour', m.time) = time_bucket('1 hour', o.created_at)
WHERE m.name = 'http_request_duration_seconds'
GROUP BY hour
ORDER BY hour DESC;This query type is not possible in PromQL.
Long-term retention with compression. Hypercore columnstore compression activates automatically on time-series data beyond the compression policy threshold, delivering 90-98% storage savings. Metrics stored for years rather than 15 days, at low per-GB cost.
Continuous aggregates. Pre-compute hourly or daily rollups of Prometheus metrics without a separate aggregation job. Query the rollup table instead of the raw hypertable for dashboard performance. This is how FlightAware reduced query times from 6.4 seconds to 30 milliseconds - continuous aggregates doing the work at ingest time rather than query time.
Data consolidation. Application events, IoT telemetry, and Prometheus metrics all live in the same PostgreSQL database, queryable together with standard SQL. No ETL, no separate analytics system, no staleness from pipeline lag.
For more on monitoring PostgreSQL itself, see 5 Ways to Monitor Your PostgreSQL Database. For a broader comparison of time-series storage options, see The Best Time-Series Databases Compared (2026).
No PromQL on historical data. The integration does not give you PromQL on TimescaleDB. Existing Grafana dashboards using PromQL continue to query Prometheus (for data within its retention window) or a backend like VictoriaMetrics or Mimir if you've migrated there. TimescaleDB is the SQL layer.
Adapter operations. The prometheus-postgresql-adapter must be deployed, monitored, and maintained. It adds a network hop between Prometheus and TimescaleDB. Tiger Cloud eliminates database operations, but not adapter operations.
Write throughput at extreme scale. At very high metric ingestion rates - hundreds of thousands of metrics per second - benchmark the adapter and TimescaleDB write path before committing to this architecture. VictoriaMetrics' write path is more directly optimized for Prometheus-native ingestion at extreme scale.
Who this is for. This architecture fits teams where SQL analytics, PostgreSQL familiarity, and long-term data consolidation matter more than maximizing PromQL compatibility. If that's not the profile, VictoriaMetrics or Mimir will serve better.
Single-node Prometheus reliably hits performance limits past roughly 10 million active series. Community reports consistently show RAM climbing from 8 GB to 32 GB or more when a single high-cardinality label is added in a Kubernetes environment. This is the practical threshold, not a theoretical one - plan for it before you hit it, not after.
For the storage layer and most PromQL queries, yes. VictoriaMetrics supports Prometheus remote_write and MetricsQL, a PromQL superset where all standard Prometheus queries work. Edge cases exist around native histograms and specific PromQL functions that behave differently in MetricsQL. Test critical alert rules before fully migrating.
General guidance: Thanos if you want minimal migration risk and can keep Prometheus running as-is. Mimir v3.0 for large enterprises with a platform team and multi-tenancy requirements. VictoriaMetrics for most other teams - lower operational complexity than Thanos, comparable or better performance, and a single binary for smaller deployments. Cortex is not recommended for net-new deployments.
Yes. The open-source prometheus-postgresql-adapter handles the remote_write connection from Prometheus to TimescaleDB. Promscale, Tiger Data's previous first-party connector, was deprecated in February 2023. The community adapter remains actively maintained. The integration gives you SQL querying of metrics and long-term retention, not PromQL compatibility.
Prometheus scrapes (pull-based); InfluxDB accepts pushes (push-based). Prometheus has a stronger alerting ecosystem with Alertmanager and recording rules. InfluxDB has stronger built-in retention policy management. InfluxDB version fragmentation - 1.x, 2.x, and 3.0 each with different query languages - is a significant consideration. For Prometheus users, VictoriaMetrics or Mimir is a more natural migration path than InfluxDB.
Route Prometheus metrics to TimescaleDB via remote_write and the prometheus-postgresql-adapter. Metrics land in a TimescaleDB hypertable queryable with standard SQL. Grafana's PostgreSQL data source supports TimescaleDB natively - no plugin required. This is the only architecture in this guide that enables SQL on Prometheus metrics.
It depends on team size and cardinality profile. At under 50 million active series, AWS Managed Prometheus, Google Cloud Managed Prometheus, or VictoriaMetrics typically costs less than Datadog. If zero operational overhead is the requirement and budget is available, Datadog's UX and ecosystem justify the cost. If budget is the constraint, VictoriaMetrics on EC2 or Kubernetes is the benchmark self-hosted alternative.
VictoriaMetrics for simplicity and low operational overhead. Grafana Mimir v3.0 for enterprise-grade horizontal scale and multi-tenancy. TimescaleDB if the requirement is SQL analytics on metrics data and the team is already running PostgreSQL. Each is the right answer for a different set of constraints.
Short-term: drop unused labels at the scrape level using metric_relabel_configs, and use recording rules to pre-aggregate high-cardinality series. Long-term: migrate to a backend designed for high cardinality - VictoriaMetrics handles hundreds of millions of active series, and Grafana Mimir scales horizontally. Managing cardinality problems within Prometheus past roughly 10 million active series is a diminishing-returns strategy.
For PromQL compatibility at scale: VictoriaMetrics (simpler) or Grafana Mimir (enterprise). For SQL-based long-term analysis and data consolidation alongside application data: TimescaleDB or Tiger Cloud. PromQL compatibility and SQL analytics are rarely the same team's top priority at the same time.