Reference · built on requestConnectorDatabases & warehouses

TimescaleDB

Time-series rows, hypertables, and continuous aggregates from TimescaleDB over a standard PostgreSQL connection.

About

TimescaleDB is a PostgreSQL extension from Tiger Data. It keeps the clients, drivers, and SQL of plain PostgreSQL. A hypertable is a PostgreSQL table partitioned into chunks by time and, optionally, other dimensions. Continuous aggregates are materialized views that refresh incrementally as rows arrive. Hypercore moves older chunks from rowstore to columnstore. Retention policies drop chunks past an age. Background jobs run these policies and any procedure you register with add_job. It runs self-hosted or as a Tiger Cloud service.

Through Fibric, an operator runs SQL over the hypertables and continuous aggregates you name and reads the rows and time buckets that come back. When a change is warranted, it proposes a policy or a scheduled job for your approval, and the connector runs the statement once.

This is a reference listing. It documents what Fibric would read from TimescaleDB and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Rows from hypertables over a PostgreSQL connection, filtered by time and any other partitioning dimension
  • Time buckets computed by time_bucket(bucket_width, ts) with an optional origin, offset, and timezone
  • Materialized results from continuous aggregates defined WITH (timescaledb.continuous), plus recent raw rows when real-time aggregation is on
  • First and last values per bucket through the first() and last() hyperfunctions
  • Hypertable, chunk, and job state from the informational views the extension exposes
  • Policy schedules for retention, columnstore conversion, and continuous aggregate refresh

Proposed actions

  • Target capability: propose inserting rows into a hypertable with a plain SQL INSERT
  • Target capability: propose a retention policy with add_retention_policy(relation, drop_after) on a hypertable
  • Target capability: propose a refresh policy with add_continuous_aggregate_policy(start_offset, end_offset, schedule_interval)
  • Target capability: propose a columnstore policy with add_columnstore_policy() to move chunks past an age into the columnstore
  • Target capability: propose scheduling a procedure with add_job(proc, schedule_interval, config)

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Catch a meter that drifts from its parent feed

    Submeter readings land in a hypertable. The operator queries hourly buckets per meter from a continuous aggregate, compares each meter with its parent feed, and names the ones whose ratio has moved.

    With Submeter Drift

  • Spot a sensor that stopped reporting

    The operator reads last(value, ts) per device over the latest bucket. Devices with no row inside the expected interval are listed with the time of their last reading.

    With Sensor Health, Data Freshness

  • Keep a hypertable within its storage budget

    The operator reads chunk counts and ages from the informational views, projects growth, and proposes a retention or columnstore policy with the interval it computed. You approve, and the receipt records the policy.

    With Storage Growth

Requirements

  • A Tiger Cloud service, or a self-hosted PostgreSQL with the timescaledb extension, reachable on its port (5432 by default when self-hosted)
  • A role with SELECT on the hypertables, continuous aggregates, and views you name. Tiger Data recommends roles with need-only permissions
  • For policies and jobs, a role permitted to call the add_*_policy and add_job functions on the target hypertable
Authentication
A PostgreSQL role and password: the connection details Tiger Cloud issues when you create a service, or the host, port, user, and database of a self-hosted instance.

Limits

  • One retention policy per hypertable. Chunks fully older than drop_after are dropped when the policy runs
  • Continuous aggregates accept only INNER, LEFT, and LATERAL joins, and DISTINCT only inside aggregate functions. Changes to joined non-hypertable data are not tracked
  • ROW LEVEL SECURITY is not supported on chunks in the columnstore
  • Month or year buckets in time_bucket cannot be combined with a smaller unit, and daylight saving shifts can make buckets uneven

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request TimescaleDB ↗

Questions and answers

Do I need a special driver for TimescaleDB?
No. TimescaleDB is a PostgreSQL extension, not a fork, so the connector uses the same clients, drivers, and SQL as plain PostgreSQL. Tiger Cloud supplies the hostname, port, username, password, and database name when you create a service.
How do continuous aggregates stay current?
A policy added with add_continuous_aggregate_policy refreshes the window between start_offset and end_offset every schedule_interval, 24 hours by default. Refresh is incremental. Real-time aggregates add raw rows newer than the materialized data, and are off by default from TimescaleDB v2.13.
How is old data removed?
With a retention policy. add_retention_policy(relation, drop_after) schedules a job that drops chunks fully older than drop_after. remove_retention_policy cancels it, and drop_chunks removes chunks by hand. A hypertable can have one retention policy.
Ask about TimescaleDB

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.