Databases
AuraScore 77/100

Renewable Asset Sensor Database Tiering Matrix

Design a tiered storage and retention matrix for high-frequency wind and solar turbine sensor monitoring.

Use this template when designing data tiering, downsampling, and archiving strategies for renewable asset monitoring platforms. It produces a storage tiering matrix balancing hot memory, warm analytical storage, and cold object storage.

Template

Role: Lead Operational Technology Database Specialist with expertise in renewable power generation and predictive fleet analytics.

Context

  • Generation asset type: {{generation_asset_type}}
  • Monitored asset count: {{turbine_count}}
  • Sensor channels per asset: {{sensor_channels_per_asset}}
  • Hot storage retention threshold: {{hot_storage_window_days}} days
  • Long-term archive policy: {{cold_archive_policy}}
  • Analytical workload pattern: {{analytical_workload_type}}

Task

Build a database storage tiering and performance matrix to optimize sensor data lifecycle management across {{turbine_count}} {{generation_asset_type}} assets.

Method

  1. Quantify continuous telemetry ingestion volume across all {{sensor_channels_per_asset}} channels for {{turbine_count}} units.
  2. Define hot storage RAM/NVMe requirements to sustain {{hot_storage_window_days}} days of high-frequency querying.
  3. Outline roll-up, downsampling, and compression strategies for warm intermediate storage.
  4. Architect cold storage tiering to satisfy {{cold_archive_policy}} while controlling retrieval costs.
  5. Evaluate query performance across each tier against {{analytical_workload_type}} workloads.
  6. Assess automated partition purging and index lifecycle policies across tiers.
  7. Compile a consolidated storage tiering matrix contrasting performance, media type, and estimated cost per gigabyte.

Constraints

  • MUST specify discrete storage technologies and compression codecs for hot, warm, and cold tiers.
  • MUST NOT allow query latencies for {{analytical_workload_type}} to exceed operational SLA bounds.
  • Normalize storage cost estimates on a per-gigabyte/month basis.
  • Exclude raw uncompressed sensor retention beyond the defined hot storage window.

Output format

  1. Fleet Sensor Ingestion Profile: Calculated data rates per second, daily storage growth, and annual storage requirements.
  2. Tiered Storage Architecture Matrix: Markdown table detailing Tier Name, Target Media/Engine, Retention Window, Compression Strategy, Target Query Latency, and Estimated Cost/GB.
  3. Lifecycle Automation Rules: Bulleted implementation plan defining scheduled aggregation and partition migration jobs.

Self-review

  • Are the volume calculations mathematically consistent with {{turbine_count}} and {{sensor_channels_per_asset}}?
  • Does the matrix clearly separate hot, warm, and cold tiers with distinct retention criteria?
  • Are the performance requirements of {{analytical_workload_type}} addressed in each tier?
AuraScore breakdown
77/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering8/12 · Adequate

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-databases
energy-utilities
renewables
storage-tiering
iot