How do I connect Datadog/Prometheus to TigerData Tiger Cloud for database and query monitoring?

Most teams don’t want “yet another” metrics pipeline just to keep an eye on their databases. With TigerData Tiger Cloud, you can plug into the monitoring systems you already use—like Datadog and Prometheus—to track database health, ingest rate, compression, continuous aggregates, and query performance in one place.

Quick Answer: You connect Datadog or Prometheus to Tiger Cloud by exposing Postgres metrics from your Tiger Cloud service (via Postgres stats views or an exporter), then scraping or forwarding those metrics into your monitoring stack over secure network paths (VPC peering, private link, or IP allow lists). You’ll monitor Tiger Cloud just like any other managed Postgres, but with additional TimescaleDB-specific time-series and compression metrics.

The Quick Overview

What It Is: A Postgres-native way to send Tiger Cloud database and query metrics into Datadog or Prometheus using standard Postgres telemetry (pg_stats_*, pg_stat_activity, TimescaleDB views) and supported exporters/agents.
Who It Is For: SREs, platform engineers, DBAs, and developers running production services on Tiger Cloud who already rely on Datadog or Prometheus for observability.
Core Problem Solved: You get consistent, centralized monitoring for Tiger Cloud—latency, errors, throughput, time-series ingest, compression, continuous aggregates—without building fragile custom pipelines or switching tools.

How It Works

At a high level, connecting Datadog or Prometheus to Tiger Cloud looks like this:

You provision a Tiger Cloud service (Postgres + TimescaleDB) and secure access to it, using IP allow lists and/or private networking.
You run a metrics collector (Datadog Agent, Prometheus + postgres_exporter, or a custom scraper) in your infrastructure.
The collector uses a normal Postgres connection (TLS-encrypted) to query Tiger Cloud’s system and TimescaleDB views, and then publishes those metrics into Datadog or Prometheus.

Tiger Cloud is “just Postgres”—with TimescaleDB on top—so you don’t need a custom, proprietary monitoring integration. You reuse existing Postgres/Timescale exporters and focus on which metrics to collect and how to alert.

1. Set up secure access from your monitoring stack

You need a safe network path between your monitoring components (agents/exporters) and your Tiger Cloud service.

Create or identify your Tiger Cloud service
- In Tiger Console, create a new service or use an existing one.
- Note the service hostname, port, and database name.
- Confirm TLS is enabled (Tiger Cloud encrypts traffic in transit with TLS 1.2+).
Configure network access Tiger Cloud supports:
- IP allow lists: Allow only fixed outbound IPs from your monitoring VMs/containers.
- Private networking (VPC peering / Transit Gateway, depending on cloud): Recommended in production to avoid exposing the service over the public internet.
Important: Only allow IP ranges that belong to your observability stack. Keep postgres (or any superuser) credentials tightly controlled, use dedicated monitoring roles where possible.

Create a dedicated monitoring user (recommended)

Use a psql session or SQL client:

CREATE ROLE monitor WITH
    LOGIN
    PASSWORD 'use-a-strong-password'
    NOSUPERUSER
    NOCREATEDB
    NOCREATEROLE
    INHERIT
    NOREPLICATION;

GRANT pg_monitor TO monitor;

The pg_monitor role gives read-only access to system views like pg_stat_activity, pg_stat_database, and pg_stat_io without granting superuser.

For TimescaleDB-specific views (compression stats, continuous aggregates, hypertables), you may also grant limited access:

GRANT USAGE ON SCHEMA timescaledb_experimental TO monitor;
GRANT SELECT ON ALL TABLES IN SCHEMA timescaledb_experimental TO monitor;
-- Repeat for timescaledb_internal if exporter requires it

2. Connect Datadog to Tiger Cloud

Datadog’s Postgres integration treats Tiger Cloud as a regular Postgres service, with extra metrics from Timescale if you query those views explicitly.

Step 2.1 – Install and configure the Datadog Agent

Install Agent on each host (VM or container) that will monitor Tiger Cloud.
Enable Postgres integration by editing the postgres.d/conf.yaml (exact path depends on OS and Datadog version).

Example configuration:

init_config:

instances:
  - dbm: true
    host: <your-tiger-cloud-hostname>
    port: 5432
    username: monitor
    password: <your-monitor-password>
    dbname: <your-database-name>
    ssl: true
    sslmode: require
    collect_commands: true
    collect_function_metrics: true
    tags:
      - env:prod
      - service:tiger-cloud-postgres
      - provider:tigerdata

Note: Tiger Cloud requires TLS; use ssl: true and sslmode: require (or verify-full if using CA validation).

Step 2.2 – Capture core Postgres and TimescaleDB metrics

Out of the box, Datadog’s integration can collect:

pg_stat_database: transactions, tuples read/returned, deadlocks, temp file usage.
pg_stat_activity: connections, states (active, idle, idle in transaction).
pg_stat_bgwriter / pg_stat_io: checkpoints, buffers, WAL, I/O.

To get Tiger Cloud’s time-series and TimescaleDB-specific behavior, extend collection with custom queries.

Add custom metrics to postgres.d/conf.yaml:

custom_queries:
  - metric_prefix: timescaledb.hypertable
    query: |
      SELECT
        hypertable_name,
        total_chunks,
        compressed_chunks,
        compression_ratio
      FROM timescaledb_experimental.hypertable_compression_stats();
    columns:
      - name: hypertable_name
        type: tag
      - name: total_chunks
        type: gauge
      - name: compressed_chunks
        type: gauge
      - name: compression_ratio
        type: gauge

  - metric_prefix: timescaledb.continuous_aggregates
    query: |
      SELECT
        view_name,
        completed_threshold,
        refreshed_at
      FROM timescaledb_experimental.continuous_aggregate_stats();
    columns:
      - name: view_name
        type: tag
      - name: completed_threshold
        type: gauge
      - name: refreshed_at
        type: gauge

These metrics let you:

Track compression (TigerData frequently sees up to 98% compression for telemetry workloads).
Monitor continuous aggregate freshness and watermarks.
Watch hypertable growth and chunk counts as ingest ramps up.

Step 2.3 – Enable Database Monitoring (query-level visibility)

With Datadog Database Monitoring (DBM) enabled, you can:

See slow queries, normalized by fingerprint.
Track query latency, rows, and error rates.
Correlate Tiger Cloud performance with application behavior.

In postgres.d/conf.yaml, ensure:

instances:
  - dbm: true
    # (other fields as above)
    obfuscator_options:
      collect_comments: false

Important: When DBM is enabled, validate that your monitoring role has enough privileges to read pg_stat_statements if you’ve enabled it. If you turn on pg_stat_statements, remember it affects shared memory and requires a restart; confirm support in your Tiger Cloud plan/console first.

3. Connect Prometheus to Tiger Cloud

Prometheus expects a /metrics endpoint, so you’ll use a Postgres exporter that runs in your infrastructure and connects to Tiger Cloud.

Step 3.1 – Deploy postgres_exporter (or equivalent)

One common choice is the prometheus-community/postgres_exporter. You run it alongside your Prometheus server (or in the same Kubernetes cluster).

Example Docker run:

docker run -d \
  --name=postgres_exporter \
  -e DATA_SOURCE_NAME="postgresql://monitor:<password>@<tiger-host>:5432/<dbname>?sslmode=require" \
  -p 9187:9187 \
  quay.io/prometheuscommunity/postgres-exporter

Or in Kubernetes, configure:

env:
  - name: DATA_SOURCE_NAME
    value: postgresql://monitor:<password>@<tiger-host>:5432/<dbname>?sslmode=require

Note: Again, use TLS (sslmode=require or verify-full). Make sure the pod/VM IPs are allowed in the Tiger Cloud service’s allow list or reachable via private networking.

Step 3.2 – Configure Prometheus scrape target

In prometheus.yml:

scrape_configs:
  - job_name: 'tiger-cloud-postgres'
    scrape_interval: 15s
    static_configs:
      - targets: ['postgres-exporter.default.svc.cluster.local:9187']
        labels:
          env: 'prod'
          service: 'tiger-cloud'
          provider: 'tigerdata'

The exporter will expose metrics such as:

pg_stat_database_xact_commit, pg_stat_database_xact_rollback
pg_stat_database_tup_returned, pg_stat_database_tup_inserted
pg_stat_activity_count per state
I/O and WAL metrics (depending on exporter configuration)

Step 3.3 – Add TimescaleDB metrics via custom queries

Most Postgres exporters support custom SQL queries defined in a YAML or configuration file.

Example queries.yml for TimescaleDB:

timescaledb_hypertable:
  query: |
    SELECT
      hypertable_name,
      total_chunks,
      compressed_chunks,
      compression_ratio
    FROM timescaledb_experimental.hypertable_compression_stats();
  metrics:
    - hypertable_name:
        usage: "LABEL"
        description: "Hypertable name"
    - total_chunks:
        usage: "GAUGE"
        description: "Total chunks for hypertable"
    - compressed_chunks:
        usage: "GAUGE"
        description: "Compressed chunks for hypertable"
    - compression_ratio:
        usage: "GAUGE"
        description: "Compression ratio for hypertable"

timescaledb_continuous_aggs:
  query: |
    SELECT
      view_name,
      EXTRACT(EPOCH FROM (clock_timestamp() - completed_threshold)) AS lag_seconds
    FROM timescaledb_experimental.continuous_aggregate_stats();
  metrics:
    - view_name:
        usage: "LABEL"
        description: "Continuous aggregate view"
    - lag_seconds:
        usage: "GAUGE"
        description: "Lag between now and completed_threshold"

Then point your exporter to this file (flags vary by exporter).

Now you can:

Alert on aggregate lag when continuous aggregates fall behind real-time.
Monitor compression and chunk counts per hypertable.
Track ingest throughput using pg_stat_database and TimescaleDB metrics.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Postgres-native metrics access	Uses standard system views (`pg_stat_`, `pg_statio_`, `pg_locks`) and TimescaleDB views for stats	No proprietary agents; integrate with Datadog/Prometheus easily.
Secure, controlled connectivity	Enforces TLS 1.2+, IP allow lists, and private networking options for monitoring traffic	Safe exposure of metrics from production Tiger Cloud services.
TimescaleDB observability	Surfaces hypertable, compression, and continuous aggregate metrics via SQL	Understand time-series-specific behavior, not just generic Postgres.
Query-level visibility (DBM)	Works with Datadog DBM or custom Prometheus queries on `pg_stat_statements`	Identify slow queries and regressions in near real time.
Unified telemetry stack	Feeds database and query metrics into existing monitoring dashboards and alerting pipelines	Avoid “yet another tool”; keep Tiger Cloud in your standard SLOs.

Ideal Use Cases

Best for production Tiger Cloud services: Because you can plug into Datadog/Prometheus for SLOs (latency, error rate, throughput) while relying on Tiger Cloud’s HA, backups, and point-in-time recovery underneath.
Best for high-ingest telemetry workloads: Because TimescaleDB metrics (compression ratio, chunk count, continuous aggregate lag) give you an accurate picture of how live telemetry and historical analytics are behaving at scale.

Limitations & Considerations

Metric cardinality and cost:
Datadog and Prometheus both charge or struggle with very high-cardinality metrics (e.g., per-customer, per-device tags).
Workaround: Keep labels coarse (env, region, service, hypertable), and avoid tagging per-row or per-user identifiers.
Permissions and schema changes:
If you tighten monitoring role permissions or TimescaleDB adds new views, some custom queries may fail.
Workaround: Use pg_monitor, avoid SELECT * in exporter queries, and monitor exporter logs for errors after schema or version upgrades.
Query impact:
Exporters that run heavy SQL too frequently can add load.
Workaround: Use lightweight queries, reasonable scrape_interval (e.g., 15–60s), and avoid scanning large tables; prefer summarized stats views.
pg_stat_statements and extensions:
Some query-level metrics assume pg_stat_statements is enabled. On managed services, extension availability can depend on plan and configuration.
Workaround: Check Tiger Console/docs for supported extensions and configure them cautiously—pg_stat_statements affects shared memory and needs planning.

Pricing & Plans

Connecting Datadog or Prometheus to Tiger Cloud doesn’t add separate TigerData charges. You pay for:

Tiger Cloud service usage: Compute, storage (including compressed and tiered), and optional replicas, billed with transparent, itemized pricing. There are no per-query fees and no hidden ingest/egress charges for monitoring traffic.
Your monitoring stack: Datadog hosts/metrics or Prometheus infrastructure, billed separately by those providers or your own cloud usage.

Typical alignment:

Performance / Scale plans: Best for teams needing high ingest, continuous aggregates, and compression metrics surfaced into observability tools, while relying on HA and PITR.
Enterprise plans: Best for regulated or mission-critical environments that require SOC 2 Type II reporting, GDPR support, HIPAA eligibility, private networking, and 24/7 support while integrating with existing Datadog/Prometheus setups.

(Consult the Tiger Cloud pricing page for exact plan names and region availability.)

Frequently Asked Questions

Can I use Datadog/Prometheus with Tiger Cloud’s built-in metrics and dashboards?

Short Answer: Yes, you can use both. Tiger Cloud exposes rich built-in metrics in Tiger Console, and you can also stream metrics into Datadog/Prometheus.

Details:
Tiger Cloud’s own observability gives you service-level metrics—CPU, memory, storage, compression, continuous aggregates, tiering behavior—directly in the console, without extra agents. That’s useful for quick triage, understanding how hypertables and background jobs behave, and seeing compression/tiering in context.

Datadog and Prometheus are best for integrating database metrics with application and infrastructure telemetry, building cross-service SLOs, and reusing your existing alerting. Many teams do both: Tiger Console for deep Tiger Cloud–specific views, Datadog/Prometheus for fleet-wide dashboards and alerts.

How do I safely expose Tiger Cloud metrics without opening my database to the internet?

Short Answer: Use private networking (VPC peering / Transit Gateway) or IP allow lists, plus a dedicated low-privilege monitoring role with TLS-only connections.

Details:
Tiger Cloud is designed for production workloads and includes:

Encryption in transit: TLS 1.2+ for all client connections; mutual TLS is used for critical internal traffic.
Encryption at rest: Data is encrypted with per-service keys.
Access controls: IP allow lists and private networking options to restrict who can connect.
Compliance: SOC 2 Type II, GDPR support, and HIPAA on Enterprise for regulated environments.

When connecting Datadog or Prometheus:

Place exporters/agents in a secure network segment.
Restrict outbound traffic to the Tiger Cloud service address/port.
Use a non-superuser monitoring role with pg_monitor and minimal additional grants.
Force TLS and, where possible, validate server certificates.

This way, you get full monitoring visibility without exposing privileged access paths.

Summary

Connecting Datadog or Prometheus to TigerData Tiger Cloud is straightforward because Tiger Cloud is Postgres at its core—just enhanced for time series, events, real-time analytics, and AI. You reuse the standard Postgres exporters and agents you already know, then layer in TimescaleDB-specific metrics (hypertables, compression, continuous aggregates) via SQL.

The result is a single, consistent monitoring story: Tiger Cloud handles HA, backups, compression, tiered storage, and real-time analytics; your existing observability stack tracks database and query health alongside application and infrastructure metrics. No fragile glue systems. No proprietary monitoring protocol. Just Postgres-native primitives and the tools you already run in production.

Next Step

Get Started