Monitor Tiered Tables status and storage savings v1.2

Suggest edits

After configuring Tiered Tables, it's important to monitor:

  • Which partitions have been offloaded
  • Whether offloading is progressing as expected
  • Storage savings on PGD vs. object storage
  • Offload-related activity on your PGD cluster

You can monitor Tiered Tables from both:

  • PGD cluster — using SQL observability queries
  • Hybrid Manager — via monitoring dashboards (if available in your environment)

Why monitor Tiered Tables?

Monitoring Tiered Tables allows you to:

  • Validate that offload is working as configured.
  • Confirm that hot/cold partitioning is behaving as expected.
  • Track storage savings and partition lifecycle.
  • Troubleshoot issues with offload or partition management.

Goals

After completing this How-To, you will be able to:

  • Identify which tables are configured for offload and their current status.
  • Monitor AutoPartition offload activity and job success.
  • Measure storage savings on PGD primary storage.
  • Use observability queries to monitor partition states.

Prerequisites

Before you begin:

Monitor analytics table status

To view which PGD tables are marked for analytics offload:

SELECT * FROM bdr.analytics_table;

Useful columns:

  • relation — table name
  • state — current offload state
  • enabled — whether analytics offload is enabled
  • disabled — whether offload is disabled
  • in_progress — whether offload is currently running

Monitor AutoPartition offload activity

Check the AutoPartition work queue for offload-related tasks:

SELECT
wqs.workid, wis.ap_wi_started_at, wis.ap_wi_finished_at,
wis.ap_wi_status, "partition", sql
FROM bdr.taskmgr_local_workitem_status wis
RIGHT JOIN bdr.taskmgr_local_work_queue_status wqs
ON wis.ap_wi_workid = wqs.workid
WHERE sql NOT LIKE '%bdr.autopartition_create_partition%'
ORDER BY ap_wi_finished_at DESC;

This helps you track:

  • When offload jobs ran
  • Their status (success/failure)
  • Which partition was affected

Monitor storage savings on PGD

To observe reduction in transactional storage used by the parent table:

SELECT pg_size_pretty(pg_total_relation_size('public.application_logs'));

As partitions are offloaded and truncated, this size should decrease.

Advanced observability — Heap vs. Offloaded size

To compare local heap vs. offloaded size for partitions: You can run an advanced observability query from EDB's recommended runbooks.

This allows you to see:

  • Per-partition storage split across heap and Iceberg/Delta
  • Remaining heap size vs. offloaded size

What you can do next

Now that you can monitor Tiered Tables status and storage savings, you can:

  • Tune your partitioning and offload policies — adjust analytics_offload_period if needed based on observed hot/cold access patterns.
  • Query Tiered Tables for analytics and BI workloads:
  • Query Tiered Tables from PGD and Lakehouse
  • Scale Lakehouse clusters appropriately to handle offloaded data queries.
  • Validate compliance and retention goals — confirm that old data is offloaded and retained per your policy.

Related How-Tos

← Prev

Create a Lakehouse cluster

↑ Up

How-To Guides for Analytics in Hybrid Manager

Next →

Offload PGD data to Apache Iceberg®