---
title: "OpenTelemetry Backend Without Lock-In"
description: "OpenTelemetry doesn't ship a backend. Compare ClickHouse, SigNoz, Last9, Mimir, and Postgres with Tiger Data on what won't lock you in."
section: "Data Center & Infrastructure Telemetry"
published: 2026-10-01T00:47:08.198Z
updated: 2026-10-01T00:00:00.000Z
---

*Updated at Oct 1, 2026*

> **TimescaleDB is now Tiger Data.**

[<u>OpenTelemetry</u>](https://opentelemetry.io/) defines how telemetry gets collected and exported: the SDKs instrument your application code, the Collector receives and processes that data, and OTLP (the OpenTelemetry Protocol) is the wire format it all travels over. None of that is a database. OpenTelemetry deliberately doesn't ship a storage engine, which is why choosing an OpenTelemetry backend, the system that actually receives your exported metrics and makes them queryable over time, is a decision every team adopting OTel eventually has to make on its own.

That decision matters more than it looks. The backend you pick determines your query language, your operational footprint, and, more than either of those, how easily you can leave later.

The field breaks into a few camps. Purpose-built OLAP engines like ClickHouse, and ClickHouse-backed platforms like SigNoz, lead on raw throughput at high cardinality. SaaS-only platforms like Last9 trade infrastructure ownership for a proprietary data store. The Prometheus-ecosystem long-term storage layers, Grafana Mimir, Thanos, and VictoriaMetrics, extend an existing scraping and alerting stack. And general-purpose PostgreSQL, extended with Tiger Data's time-series capabilities, treats metrics as just another table you can join against the rest of your data.

One disclosure upfront: Tiger Data sells a Postgres-based database, and Postgres is one of the seven options evaluated below. The bar is the same for every option here, including the sections where Tiger Data is not the right fit.

Every backend below locks you into something: a query language, a proprietary storage format, a SaaS pricing model, or an operational stack you now have to run. None of them are lock-in-free. The real question isn't which one is fastest. It's which lock-in you can actually live with.

## What is an OpenTelemetry backend, and why doesn't OTel ship one?

An OpenTelemetry backend is whatever system receives your exported metrics and makes them queryable over time, whether that's a columnar OLAP database, a Prometheus-compatible store, a SaaS platform, or Postgres. OpenTelemetry itself ships none of that: the SDKs instrument application code, the Collector batches and routes the data, and OTLP is the wire format everything speaks. None of those three pieces is a database, and OpenTelemetry has no opinion about what that system should be.

That's a deliberate design choice. OpenTelemetry is vendor-neutral by design: the project's job ends at "here's your data, in a consistent format," and the surrounding ecosystem's job is to offer many valid places to send it. That's why the "which backend" question exists at all, and why the honest answer is: it depends.

The mechanical reason backend choice stays modular is the Collector's exporter model. Because the Collector supports multiple exporters, OTLP-native, Prometheus remote-write-compatible, and a long list of vendor-specific options, a team can point the same instrumented application at a different backend without touching a line of application code. Swap the exporter configuration, not the instrumentation.

One scoping note before going further: OpenTelemetry covers three stable signal types, metrics, traces, and logs, and this page is scoped to metrics storage specifically. The backend calculus for metrics, cardinality, retention windows, downsampling strategy, query pattern, differs meaningfully from how you'd think about trace or log storage, which tend to be dominated by different access patterns and retention economics.

If you need the fundamentals first, temporality, gauges versus counters versus histograms, how the SDK actually builds a metric, [<u>what are OpenTelemetry metrics</u>](https://www.tigerdata.com/blog/a-deep-dive-into-open-telemetry-metrics) covers that ground in depth.

Since OTel won't make this decision for you, the next section lays out the axes that separate one backend from another, before getting into a full comparison and a decision framework.

## The decision axes: what actually separates OpenTelemetry metrics backends

Every backend in this comparison gets evaluated against the same six axes, in the same order, throughout the rest of this page:

- **Storage model.** Columnar OLAP, relational, or a proprietary time-series format. This determines compression characteristics and how well a system handles high-cardinality label sets.
- **Query language.** PromQL or MetricsQL (Prometheus-ecosystem native), SQL, or a proprietary query interface. This is the single biggest portability factor on this list: SQL skills transfer everywhere, while a proprietary query language is a skill investment that only pays off inside that one system.
- **Deployment model.** Self-hosted, SaaS-only, or both. SaaS-only options trade operational burden for platform dependency.
- **Operational complexity.** How many components need to be run, tuned, and kept healthy, a single binary versus a distributed system with half a dozen moving parts.
- **Lock-in risk.** How hard it is to get your data, and your query logic, back out if you switch later. This is the axis most vendor comparison pages skip entirely.
- **Best-fit use case.** The honest answer to "who is this actually right for," not "who should buy this."

Here's the point that matters more than any individual axis: every backend below locks a team into something on one or more of these six dimensions. A query language. A storage format. A pricing model. An operational stack you now have to run. None of the seven options are lock-in-free. The goal isn't finding the one that avoids lock-in. It's picking the lock-in you can live with, deliberately, instead of discovering it eighteen months in.

This is a framework, not a preview of conclusions. Rankings and recommendations come later, in the decision framework further down this page.

## Comparing the major OpenTelemetry metrics backends

Each backend below accepts OpenTelemetry-exported metrics, either natively over OTLP or through the Collector's Prometheus remote-write-compatible exporter, but the seven differ fundamentally across the six axes above. The full comparison table comes first, then a profile of each.

### Comparison table

| **Backend** | **Storage model** | **Query language** | **Deployment model** | **Operational complexity** | **Lock-in risk** | **Best-fit use case** |
| --- | --- | --- | --- | --- | --- | --- |
| ClickHouse | Columnar OLAP | SQL (ClickHouse dialect) | Self-hosted or ClickHouse Cloud | Medium-high (cluster sizing and tuning at scale) | Medium (SQL-like, but ClickHouse-specific dialect and storage format) | Teams that need raw high-cardinality scale and are willing to run and tune a dedicated analytics cluster |
| SigNoz | Columnar OLAP (ClickHouse under the hood) | Query Builder, PromQL, and ClickHouse SQL | Self-hosted or SigNoz Cloud | Medium-high (inherits ClickHouse's operational model) | Medium-high (tied to ClickHouse's storage format; SigNoz doesn't own its own storage layer) | Teams that want an OTel-native UI and platform and are comfortable owning a ClickHouse cluster underneath it |
| Last9 | Proprietary (events and time-series store) | PromQL (Prometheus-compatible), plus Last9's own UI | SaaS-only (managed BYOC in your own cloud account available) | Low (fully managed) | High (no self-serve self-hosted option; data lives in a proprietary SaaS store) | Teams that want a fully managed platform and are comfortable without a self-hosted or exportable-by-default option |
| Grafana Mimir | Object storage plus Kafka between the write and read paths  (3.0+) | PromQL only | Self-hosted or Grafana Cloud | Very high (ingester, querier, compactor, store-gateway, distributor, Kafka) | Medium (open storage format, but PromQL-only query surface) | Large, multi-tenant Prometheus deployments already invested in the Grafana ecosystem |
| Thanos | Object storage (S3, GCS, Azure) | PromQL only | Self-hosted only | High (Sidecar, Store Gateway, Querier, Compactor as separate processes) | Medium (open storage format, but PromQL-only query surface) | Existing Prometheus fleets that want long-term storage without changing scrape configuration |
| VictoriaMetrics | Custom columnar (open source) | MetricsQL (PromQL superset) | Self-hosted (single binary or cluster) or VictoriaMetrics Cloud | Low (single-node) or high (cluster mode) | Medium (open-ish format, but MetricsQL is not pure PromQL) | Cost-conscious teams that want the simplest possible single-binary deployment and don't need SQL |
| PostgreSQL + Tiger Data | Relational (hypertables) with columnstore compression | SQL (native); Prometheus remote-write data ingested via Telegraf | Self-hosted (TimescaleDB Community or TimescaleDB Enterprise) or Tiger Cloud (managed) | Medium (standard Postgres operations; no separate analytics cluster) | Low (data lives in standard Postgres tables, exportable with pg_dump; TimescaleDB features need a host that supports the extension) | Teams already running Postgres who want SQL joins between metrics and application or business data in one system |

### ClickHouse

[<u>ClickHouse</u>](https://clickhouse.com/) is an open-source columnar OLAP database built for high-throughput analytical queries. ClickHouse Cloud and the ClickStack observability bundle package it as a full backend for OpenTelemetry-exported telemetry, including metrics.

The open-source core is free and self-hostable; ClickHouse Cloud is priced on usage (compute plus storage). Query language is SQL, in ClickHouse's own dialect: familiar syntax, but with ClickHouse-specific functions and table engines that don't transfer directly to a standard SQL database.

Directionally, ClickHouse tends to lead this category on raw compression ratio and query throughput at very high cardinality, and its adoption momentum in observability is real and still growing. The tradeoff shows up operationally: running it well at scale means owning cluster sizing, sharding, and replication as a dedicated surface, a second specialized system alongside whatever you already run for application data.

Best fit: teams whose primary constraint is raw scale and who are willing, or already staffed, to run a dedicated analytics cluster for it. Deployment options: self-hosted or ClickHouse Cloud.

### SigNoz

[<u>SigNoz</u>](https://signoz.io/) is an open-source, OpenTelemetry-native observability platform covering metrics, traces, logs, and dashboards, with ClickHouse as its underlying storage engine. The open-source core is free and self-hostable; SigNoz Cloud is priced on usage.

Queries run through SigNoz's Query Builder, PromQL, or ClickHouse SQL against the ClickHouse store underneath. The strength is purpose-built OTel-native UX: SigNoz is built around OpenTelemetry's data model from the ground up, not retrofitted onto it, and adoption here is growing fast.

The limitation is that SigNoz doesn't own its own storage story. Choosing it means inheriting ClickHouse's cluster-sizing and tuning burden underneath the platform layer, not avoiding it.

Best fit: teams that want an OTel-native UI out of the box and are comfortable operating, or paying SigNoz Cloud to operate, a ClickHouse cluster underneath it. Deployment options: self-hosted or SigNoz Cloud.

### Last9

[<u>Last9</u>](https://last9.io/) is a SaaS observability platform for OpenTelemetry and Prometheus-format metrics, priced on events and cardinality rather than raw storage volume. It's SaaS-only on standard plans; an Enterprise BYOC option lets the workload run inside a customer's own cloud account, but that requires a custom contract rather than a self-serve deployment.

Querying is Prometheus-compatible, so existing PromQL dashboards and alert rules carry over from Prometheus and Grafana, and Grafana can stay as the UI. 

The limitation is data portability. There's no self-hosted option (BYOC is still Last9-managed), so leaving means an export and migration project, not a config change.

Best fit: teams that want a fully managed platform and prioritize not running infrastructure over data portability. Deployment options: SaaS-only, with managed BYOC available. 

### Grafana Mimir

[<u>Grafana Mimir</u>](https://grafana.com/oss/mimir/) is a horizontally scalable, multi-tenant, Prometheus-compatible long-term storage backend, and the successor to Cortex. [<u>Mimir 3.0 introduced a Kafka-based</u> architecture](https://grafana.com/blog/grafana-mimir-3-0-release-all-the-latest-updates/) that decouples the read and write paths, so heavy query load doesn't slow ingestion. 

It's open-source and self-hostable, with Grafana Cloud offering it as a managed, usage-priced service. Query language is PromQL only. The strength is genuine multi-tenant, SaaS-scale Prometheus deployments with first-class Grafana Cloud integration.

The limitation is real: ingester, querier, compactor, store-gateway, distributor, and now Kafka in 3.0 and later are all separate components to deploy and keep healthy, substantial overhead for a small-to-mid deployment that doesn't need it.

Best fit: large organizations running Prometheus-format metrics at genuine multi-tenant scale, or teams already committed to Grafana Cloud. Deployment options: self-hosted or Grafana Cloud.

### Thanos

[<u>Thanos</u>](https://thanos.io/) is a set of open-source CNCF components, Sidecar, Store Gateway, Querier, Compactor, and Ruler, that add long-term storage and a global query view on top of an existing Prometheus fleet.

It's fully open-source with no vendor SaaS tier; cost is object storage plus the operational headcount to run it. Query language is PromQL only. The strength: no change to existing Prometheus scrape configuration and broad support for any S3-compatible object storage.

The limitation is four-plus separate processes to manage, query fanout latency that grows with data volume, and no SaaS option if you'd rather offload operations.

Best fit: teams with an existing Prometheus fleet who want long-term storage without disrupting how Prometheus already scrapes and writes. Deployment options: self-hosted only.

### VictoriaMetrics

[<u>VictoriaMetrics</u>](https://victoriametrics.com/) is a ground-up, Go-based time-series database, not built on Prometheus's own TSDB, that accepts Prometheus remote_write and OTLP metrics natively. It's available as a single binary or a horizontally scalable cluster.

It's open-source and self-hostable (the single binary is free), with VictoriaMetrics Cloud and Enterprise licensing available for managed or advanced features. Query language is MetricsQL, a PromQL superset; most queries behave identically, though some PromQL edge cases run differently under its extensions.

The strength is real: community benchmarks point to meaningfully better compression than Prometheus's own TSDB, and single-node deployment is simple by design, one binary, no external dependencies. The limitation is no SQL support, and cluster mode, needed for horizontal scale, reintroduces real operational complexity.

Best fit: cost-conscious teams that want the simplest possible operational footprint for a standalone metrics store and don't need SQL joins to other data. Deployment options: self-hosted (single-node or cluster) or VictoriaMetrics Cloud.

### PostgreSQL + Tiger Data

PostgreSQL, extended with Tiger Data's time-series capabilities, hypertables, columnstore compression, continuous aggregates, receiving OpenTelemetry-exported metrics through the OTel Collector's Prometheus remote-write-compatible exporter and a Telegraf relay that writes them into hypertables. Covered in depth two sections below.

It's free to self-host with TimescaleDB Community Edition; [<u>Tiger Cloud</u>](https://www.tigerdata.com/cloud) is the managed option, priced on compute plus storage, and [<u>TimescaleDB Enterprise</u>](https://www.tigerdata.com/timescaledb-enterprise) is the self-managed option for on-prem, edge, and private cloud, built to run reliably across sites, fleets, and infrastructure you control. Query language is standard SQL. Prometheus remote-write data can land in it through Telegraf, so existing Prometheus pipelines can keep feeding it. 

The strength is consolidation: SQL joins between metrics and application or business data in the same database, standard Postgres tooling (backups, roles, extensions, whatever ORM you already run) that a team likely already operates, and no separate analytics cluster to stand up.

The limitation, stated plainly: teams that need ClickHouse-tier raw OLAP throughput at very large cardinality may be better served by ClickHouse or a ClickHouse-backed platform. This page isn't arguing scale parity that doesn't exist.

Best fit: teams already running Postgres who want metrics queryable alongside deployment records, customer or tenant data, or other relational business data, without adding a second database system. Deployment options: self-hosted or Tiger Cloud.

For a closer look at how this plays out specifically for facilities and infrastructure telemetry, see [<u>Postgres for data center telemetry</u>](https://www.tigerdata.com/learn/data-center-telemetry-database).

## ClickHouse vs. Postgres for infrastructure observability: the real tradeoffs

This is the single most-asked question in this space, so it deserves a direct answer, not just a table cell.

ClickHouse's strength is raw columnar OLAP throughput and compression at very high cardinality and volume. For teams whose primary bottleneck is ingest or query speed at scale, ClickHouse, or a ClickHouse-backed platform like SigNoz, tends to be the stronger fit, and that gap is real.

Where the tradeoff flips is operational simplicity and data consolidation. Running ClickHouse well means sizing, sharding, and tuning a dedicated analytics cluster as its own operational surface, a second system with its own on-call rotation and upgrade cadence. Running Postgres with Tiger Data means extending a database most teams already operate. No second cluster, no second set of backup, access, or monitoring tooling to maintain.

The data-consolidation angle is concrete: SQL joins let a team query OTel metrics directly against deployment events, customer or tenant records, or other application data in the same query. PromQL-only backends can't join at all, and ClickHouse-based backends can join only against data that's been copied or federated into them first. 

Choose ClickHouse, or SigNoz, when raw scale is the binding constraint and a dedicated analytics cluster is an acceptable, or already-staffed, cost. Choose Postgres with Tiger Data when the workload fits comfortably in a well-tuned relational database and the priority is one operational surface plus SQL joins against the rest of the business. Neither one is worse. They're two different bets on what you're optimizing for.

## Using Postgres as an OpenTelemetry metrics backend

Here's the actual data path. [<u>Prometheus</u>](https://prometheus.io/), or the OTel Collector's own Prometheus receiver, continues scraping targets as it does today. The Collector's Prometheus remote-write-compatible exporter, a widely used component in the Collector's core and contrib distributions, ships those samples onward. On the Postgres side, Telegraf receives that stream (its http_listener_v2 input with the prometheusremotewrite parser), and its PostgreSQL output plugin turns it  into inserts against a [<u>hypertable</u>](https://www.tigerdata.com/docs/learn/hypertables/understand-hypertables), a time-partitioned PostgreSQL table purpose-built for append-heavy, time-ordered writes. Telegraf is an open-source InfluxData project, not a Tiger Data component; Tiger Data's docs cover the [<u>Telegraf-to-hypertable setup</u>](https://www.tigerdata.com/docs/integrate/observability-alerting/telegraf). Tiger Data's own first-party adapter for this path, Promscale, was discontinued in 2023; see the section below. 

A more direct route is also emerging: a dedicated Postgres exporter for the Collector, one that would write OTLP metrics straight into a Postgres-compatible database without a remote-write hop, was [<u>proposed as a component donation</u>](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/46501) to the Collector's contrib repository in February 2026. It's still working through review rather than shipping as a maintained, supported component, so treat it as a direction worth watching, not something to build a production pipeline on today.

[<u>Columnstore compression</u>](https://www.tigerdata.com/docs/learn/columnar-storage/understand-hypercore), Tiger Data calls the engine Hypercore, keeps that pipeline affordable over time. Infrastructure metrics compress well because adjacent readings from the same host or service are highly repetitive, and Hypercore exploits that pattern automatically, so storage grows at a fraction of the raw rate as you extend retention. 

[<u>Continuous aggregates</u>](https://www.tigerdata.com/docs/learn/continuous-aggregates) handle downsampling and rollups. A dashboard asking for average CPU utilization per host per hour over 90 days shouldn't rescan raw per-second metrics on every page load, so continuous aggregates precompute those rollups and refresh them incrementally on a policy you set once, instead of a hand-rolled batch job. 

The SQL-joins point is where this gets concrete: joining a metrics table against a deployments or hosts table answers "show me error-rate metrics for every host running build X" in one query, against the deployment data where it already lives. PromQL-only backends can't do that, and ClickHouse-based ones need that data copied or federated in first. 

Deployment comes down to two options: self-hosted PostgreSQL with Tiger Data for teams that want to run it themselves, or Tiger Cloud for teams that want the managed version without owning backups, upgrades, and scaling.

One misconception worth rebutting directly: Postgres, or TimescaleDB specifically, is not just for IoT. The same hypertable, compression, and continuous-aggregate pattern that works for sensor data works identically for infrastructure and observability metrics. The underlying workload shape, timestamped, high-cardinality, queried over time ranges, is the same whether the source is a factory floor or a Kubernetes cluster.

For more on why SQL specifically holds up well against the alternatives here, see [<u>why SQL is a strong query interface for OTel data</u>](https://www.tigerdata.com/blog/opentelemetry-where-sql-is-better-than-the-original). And for teams running this at data-center scale rather than a handful of services, [<u>Postgres for scaling AI data center operations</u>](https://www.tigerdata.com/data-centers) covers what changes at that volume.

## SQL and PromQL together: Postgres as a Prometheus remote_write backend

This isn't an either/or choice between SQL and PromQL, a common point of confusion worth clearing up. Prometheus, or the OTel Collector, keeps handling scraping and short-term buffering exactly as before. PostgreSQL with Tiger Data receives the same data via remote_write, relayed through Telegraf, for durable, SQL-queryable long-term retention. Both run at once.

The practical benefit over PromQL-only long-term stores, Grafana Mimir, Thanos, VictoriaMetrics, is standard SQL as the primary query surface for long-term analysis, while still running short-term PromQL dashboards against Prometheus itself during the local retention window.

Mimir and Thanos require several dedicated components purely for long-term metrics storage: ingester, querier, compactor, and store-gateway, plus Kafka for Mimir 3.0 and later, or Sidecar and Store Gateway for Thanos. Postgres with Tiger Data needs one lightweight relay (Telegraf) in front of a database most teams already run, rather than adding a new distributed system.

This is the OpenTelemetry-native version of a question covered in more depth in the [<u>Prometheus long-term storage options</u>](https://www.tigerdata.com/learn/prometheus-long-term-storage) guide. If you're evaluating Thanos, Mimir, or VictoriaMetrics specifically as Prometheus remote_write targets, the fuller comparison lives there.

And if the question isn't just where metrics land long-term but whether to replace Prometheus's scraping layer entirely, [<u>Prometheus alternatives compared</u>](https://www.tigerdata.com/learn/prometheus-alternatives) covers that broader decision.

## What happened to Promscale?

Readers researching TimescaleDB's history with Prometheus will run into Promscale, so it's worth addressing directly.

Promscale was TimescaleDB's earlier unified Prometheus and OpenTelemetry backend, built on top of the open-source TimescaleDB extension. It was discontinued in 2023 (maintenance ended April 30, 2023) and is not a current option. The article [<u>Promscale was deprecated in 2023</u>](https://www.tigerdata.com/blog/important-news-about-promscale) covers the full announcement.

The capability Promscale explored, TimescaleDB as a metrics store, didn't disappear with the project. Today the path is the OTel Collector's Prometheus remote-write-compatible exporter plus Telegraf, described in the sections above, without Promscale itself in the picture.

## Decision framework: choosing your OpenTelemetry metrics backend

This is a practical guide, not a ranking. Every backend below is the right call in its own context.

**Choose ClickHouse if:**

- Raw ingest or query throughput at very high cardinality is your binding constraint.
- You're willing to run and tune a dedicated OLAP cluster as its own operational surface.
- You want SQL, but don't need it to join against non-telemetry application data.

**Choose SigNoz if:**

- You want an OTel-native UI and dashboarding experience out of the box.
- You're comfortable operating, or paying for, a ClickHouse cluster underneath that UI.

**Choose Last9 if:**

- You want a fully managed platform and would rather not run storage infrastructure at all.
- Proprietary data storage is an acceptable tradeoff for close to zero operational burden.

**Choose Grafana Mimir if:**

- You're running Prometheus-format metrics at genuine multi-tenant, SaaS scale.
- You're already invested in the Grafana ecosystem or Grafana Cloud.
- You have a dedicated platform engineering team to own the operational surface.

**Choose Thanos if:**

- You have an existing Prometheus fleet and want long-term storage without changing scrape configuration.
- You already have S3-compatible object storage in place.

**Choose VictoriaMetrics if:**

- Operational simplicity is the top priority and a single-binary deployment fits your scale.
- Pure PromQL or MetricsQL is sufficient and you don't need SQL joins.

**Choose PostgreSQL with Tiger Data if:**

- You already run Postgres in production and want to extend it rather than add a new database system.
- You need SQL joins between metrics and application, deployment, or customer data.
- You want one operational surface, backups, roles, monitoring, instead of a separate analytics cluster.
- Tiger Cloud removes the self-hosting burden if you want the managed version of the same engine.

**Tiger Data isn't the best fit if:**

Your primary requirement is ClickHouse-tier raw OLAP throughput at very large cardinality and you have no existing Postgres investment to build on.

- You need a pure PromQL-only query surface with no SQL requirement. VictoriaMetrics or Mimir and Thanos are the more direct fit.

If you're making this decision specifically for data center or facilities infrastructure, [<u>what database DCIM software uses</u>](https://www.tigerdata.com/learn/dcim-database) and [<u>PUE/WUE monitoring at scale</u>](https://www.tigerdata.com/learn/data-center-power-monitoring) cover the adjacent storage questions for that environment.

## Migrating to a Postgres-based OpenTelemetry backend

A few common paths lead into this architecture:

**From SigNoz (self-hosted ClickHouse).** Teams that adopted SigNoz for its OTel-native UI but want out of ClickHouse cluster operations can redirect the OTel Collector's metrics export to Postgres with Tiger Data (via the remote-write and Telegraf path above), keeping OTel instrumentation unchanged.

**From Last9 (SaaS).** Moving off a SaaS-only platform means exporting historical data and repointing the Collector's export target to a self-hosted or Tiger Cloud Postgres instance. Expect a data-export project rather than a config change, since Last9 has no self-serve self-hosted or bulk-export-by-default path.

**From Prometheus with Thanos, Mimir, or VictoriaMetrics as the long-term store.** The Collector's Prometheus remote-write-compatible exporter can point at a Telegraf listener that writes to Postgres with Tiger Data, alongside or instead of the existing remote_write target. See the [<u>Prometheus long-term storage options</u>](https://www.tigerdata.com/learn/prometheus-long-term-storage) guide for the fuller migration detail on this specific path.

**From legacy Promscale.** Teams still running the deprecated Promscale integration should migrate to the OTel Collector's remote-write exporter plus Telegraf path described above. Promscale itself receives no further updates.

This is a map of paths, not a step-by-step tutorial. Teams evaluating whether Postgres with Tiger Data fits a data-center-scale deployment specifically can start with [<u>Postgres for scaling AI data center operations</u>](https://www.tigerdata.com/data-centers).