managed Postgres for telemetry with predictable pricing (no surprise per-query charges)

Most teams hitting telemetry scale in Postgres are fighting two battles at once: keeping ingest and queries fast enough for real-world workloads, and keeping the bill understandable when every cloud provider wants to charge per query, per read, and per egress. TigerData’s managed Postgres for telemetry is built to solve both problems—the performance and the predictability—without asking you to leave Postgres behind.

Quick Answer: TigerData is a managed Postgres platform (with TimescaleDB) purpose-built for telemetry—time-series, events, and metrics—so you get high-ingest, real-time analytics and historical storage without fragile streaming glue or surprise per‑query charges. You pay for compute and storage, not for every query or row read.

---

The Quick Overview

• What It Is: A managed Postgres service optimized for telemetry workloads, using TimescaleDB primitives (hypertables, compression, tiered storage, time-series functions) plus managed operations (HA, backups, metrics, insights) and transparent, usage-based pricing.
• Who It Is For: Teams collecting high-volume metrics, IoT telemetry, logs, events, or tick data that want to stay on Postgres while scaling ingest, analytics, and storage—without per‑query metering or complex multi-system pipelines.
• Core Problem Solved: Plain Postgres gets slow and expensive at telemetry scale, and many cloud databases hide costs behind per‑query and egress pricing. TigerData keeps workloads fast by extending Postgres for time-based data and keeps bills predictable by charging for capacity, not individual queries.

---

How It Works

TigerData takes standard Postgres, adds the TimescaleDB extension, and then layers managed cloud operations and telemetry-specific primitives on top. You still connect with regular Postgres drivers and write SQL, but the engine behaves differently under telemetry load:

• Tables become hypertables that automatically partition data by time (and optionally a key).
• Recent data is written in row format for fast ingest; older data is converted into compressed columnar chunks for efficient analytics.
• Tiered storage moves cold data to lower-cost object storage, while hot data stays on fast disks for low-latency queries.
• Continuous aggregates and time-series functions sit directly in Postgres, so your rollups and analytics don’t need a separate system.
• Tiger Cloud handles HA, automated backups, point-in-time recovery, monitoring, and insights—without charging per query or data access.

A typical telemetry deployment flows like this:

1. Ingest & schema setup:

   • You create a service in Tiger Cloud and connect over standard Postgres.
   • You define a table like metrics or events that includes a timestamp column, then convert it into a hypertable:

     SELECT create_hypertable('metrics', 'time', chunk_time_interval => interval '1 day');
     

   • Data streams in from your applications, Kafka, or other ingest pipelines using familiar SQL or drivers.

2. Real-time writes & queries:

   • TimescaleDB’s automatic partitioning (hypertables) keeps recent chunks small and indexable, so inserts and queries stay fast even as the table grows to billions of rows.
   • You add indexes optimized for your telemetry access patterns, for example:

     CREATE INDEX ON metrics (device_id, time DESC);
     

   • Applications run real-time dashboards, threshold checks, and “last N minutes/hours” queries directly against Postgres, with predictable latency.

3. Historical analytics & cost control:

   • Background jobs compress older chunks and convert them into Hypercore’s columnar format, achieving up to ~98% compression on time-series workloads.
   • Tiered storage automatically moves cold data to cheaper object storage while keeping it queryable.
   • Continuous aggregates materialize rollups (e.g., per-minute, per-hour stats) so historical reports don’t hammer your raw tables.
   • You track the cost impact in Tiger Console by looking at compute and storage usage, not a giant list of metered queries.

---

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Hypertables & automatic partitioning	Partitions tables by time and optional key; manages chunk creation, indexing, and retention.	Keeps telemetry ingest and queries fast at billions of rows while keeping schema Postgres‑native.
Hypercore row-columnar & compression	Stores recent data in row format, older chunks in compressed columnar; compresses up to 98%.	Reduces storage costs dramatically and accelerates historical analytics scans and aggregates.
Tiered storage & usage-based pricing	Moves cold data to object storage and bills based on compute + storage, not per‑query or egress.	Makes long-term telemetry retention affordable and predictable, with no surprise per‑query charges.

You also get managed ops primitives common to Tiger Cloud standard services:

• Automatic backups and PITR: Continuous backups and point-in-time recovery to protect critical telemetry data.
• High availability & read replicas: Multi-node setups for resilience and scalable read throughput.
• Connection pooling, insights, and metrics: Built-in connection management plus deep query insights beyond pg_stat_statements.

---

Ideal Use Cases

• Best for live metrics and observability backends:
  Because it handles high-ingest time-series metrics (application, infrastructure, custom business metrics) with automatic partitioning and compression, while keeping dashboards and alerts fast without per‑query or read-metered pricing.

• Best for IoT telemetry and sensor fleets:
  Because it can ingest millions to billions of data points per day from devices, maintain long-term history with high compression, and support mixed workloads (real-time device views + heavy historical analysis) on a single Postgres-native system.

Other great fits:

• Financial tick data and order events.
• Manufacturing and industrial telemetry.
• Event-driven product analytics for SaaS applications.

---

Limitations & Considerations

• Free services feature scope:
  Free Tiger Cloud services are Postgres + TimescaleDB + vector extensions with preconfigured CPU/memory and a basic feature set.
  Important: Free services do not include connection pooling, replication, tiered storage, exporters, metrics, VPC networking, and other production-grade capabilities. They are ideal for schema exploration, small-scale testing, and syntax validation, not for production telemetry workloads.

• Eventual consistency on some rollups:
  Continuous aggregates and compression policies run on schedules.
  Note: There can be a small delay between raw telemetry ingest and its appearance in materialized rollups; this is by design to balance freshness with performance. You still have access to raw data for fully real-time reads if needed.

• Postgres constraints still apply:
  This is Postgres under the hood. Familiar constraints like transaction semantics, index management, and version compatibility remain. For example, careful index design still matters (CREATE INDEX on high-cardinality dimensions, partial indexes, etc.), though hypertables and compression change the performance calculus.

---

Pricing & Plans

TigerData’s pricing is built around disaggregated, consumption-based compute and storage. That means:

• You pay for the compute resources (CPU/RAM class) you choose.
• You pay for storage usage (including data, indexes, and compressed/tiered storage).
• You do not pay per query, per scan, per read, or per GB of ingest/egress.

From the docs:

There are no per-query fees, nor additional costs to read or write data. It’s all completely transparent, easily understood, and up to you.

Using self-hosted TimescaleDB and open-source components is free; Tiger Cloud adds managed operations, HA, backups, insights, and more.

A typical telemetry setup looks like:

• A standard service in Tiger Cloud with:
  • High availability enabled.
  • Automatic backups + point-in-time recovery.
  • Connection pooling and read replicas for analytic workloads.
  • Tiered storage for long-term telemetry data.

Sketching the plans in context:

• Performance / Standard Plan:
  Best for teams needing production-ready telemetry Postgres with HA, backups, connection pooling, and insights—but not yet at extreme scale. Ideal when you want predictable monthly spend tied to instance size and storage, not query count.

• Scale / Enterprise Plan:
  Best for large-scale telemetry platforms and regulated environments (SOC 2, GDPR, HIPAA by plan) that need strict SLAs, multi-region design, private networking (VPC peering/Transit Gateway), and 24/7 operations support. Use this when telemetry is mission-critical and you’re ingesting at very high volumes.

Note: If you provision from AWS Marketplace, you’ll see pay-as-you-go and annual commit options directly in Marketplace; the underlying model is still compute + storage, not per‑query.

---

Frequently Asked Questions

Does TigerData charge per query or per GB scanned?

Short Answer: No. TigerData does not charge per query or per GB scanned; pricing is based on compute and storage consumption.

Details:
Tiger Cloud services are billed according to the size and uptime of your database service (CPU/RAM class) plus the storage you consume. There are:

• No per-query fees.
• No additional costs just to read or write data.
• No hidden ingest or egress surprises.

This is particularly important for telemetry workloads, where dashboards, alerts, and downstream analytics can fire off large volumes of queries and historical scans. With TigerData, you can create new dashboards or heavy reporting jobs without worrying about each query incrementing your bill.

---

How does TigerData keep Postgres fast for telemetry workloads?

Short Answer: By extending Postgres with TimescaleDB primitives—hypertables, compression, columnar storage, and tiered storage—that are explicitly built for time-series and event data.

Details:
Plain Postgres stores everything in a single heap table; as telemetry grows, indexes bloat, tables get huge, and queries slow down. TigerData changes that calculus:

1. Hypertables (automatic partitioning):

   SELECT create_hypertable('events', 'time', chunk_time_interval => interval '1 hour');
   

   Data is automatically sharded into time-based chunks, each with its own indexes. Inserts stay fast, and queries can prune chunks based on time predicates (WHERE time >= now() - interval '1 day').

2. Hypercore row-columnar storage:

   • Recent chunks: row-oriented, optimized for rapid inserts and point lookups.
   • Older chunks: converted to columnar and compressed.
   • Columnar storage accelerates large scans and aggregations across time, which are common in telemetry analytics (e.g., “average latency per API per day” over months).

3. Compression policies:
   You can configure policies so older telemetry automatically compresses, freeing space and improving analytic performance:

   SELECT add_compression_policy('events', INTERVAL '7 days');
   

4. Continuous aggregates:
   Precompute and maintain rollups for heavy queries:

   CREATE MATERIALIZED VIEW api_latency_1m
   WITH (timescaledb.continuous) AS
   SELECT
     time_bucket('1 minute', time) AS bucket,
     api_name,
     avg(latency_ms) AS avg_latency
   FROM events
   GROUP BY bucket, api_name;
   
   SELECT add_continuous_aggregate_policy(
     'api_latency_1m',
     start_offset => INTERVAL '1 day',
     end_offset   => INTERVAL '1 minute',
     schedule_interval => INTERVAL '1 minute'
   );
   

   Dashboards hit api_latency_1m instead of recomputing aggregates from billions of raw rows.

Together, these primitives let you treat Postgres as a single, reliable system for ingest, real-time queries, and analytics—even at scales like trillions of metrics per day that TigerData showcases—without stitching Kafka, Flink, and a separate warehouse just to stay afloat.

---

Summary

Telemetry workloads push plain Postgres beyond its default comfort zone: ingest volume explodes, tables grow to billions of rows, and queries need both real-time freshness and long-term history. At the same time, traditional cloud databases try to meter every query, scan, and GB of egress, making cost forecasting painful.

TigerData’s managed Postgres for telemetry keeps Postgres as the foundation but adds the right primitives—hypertables, Hypercore row-columnar storage, compression, tiered storage, continuous aggregates, and deep observability—so you can handle live telemetry at scale without fragile multi-system plumbing. And because pricing is based on compute and storage, not per‑query fees, you can scale dashboards and analytics without worrying that every new query is a new line item on your bill.

---

Next Step

Get Started