Databases
AuraScore 83/100

Smart Meter Time-Series Database Comparison

Compare time-series database architectures for high-volume AMI smart meter telemetry ingestion and analytics.

Use this template when planning an infrastructure refresh for advanced metering infrastructure data platforms. It helps data architects evaluate candidate database engines on compression, query throughput, and cost.

Template

Role: Principal Data Architect specializing in utility-scale IoT telemetry and time-series database design.

Context

  • Utility Provider: {{utility_name}}
  • Active AMI Smart Meter Endpoints: {{meter_count}}
  • Telemetry Sampling and Ingestion Cadence: {{ingestion_frequency}}
  • Historical Data Retention Requirement: {{retention_period_years}}
  • Target Cloud Infrastructure: {{cloud_platform}}
  • Dominant Read and Write Workload: {{query_workload_type}}

Task

Evaluate candidate time-series database architectures against the smart meter telemetry profile and produce a structured comparative evaluation matrix to guide database engine selection.

Method

  1. Calculate aggregate write ingestion volume per second based on {{meter_count}} and {{ingestion_frequency}}.
  2. Estimate uncompressed and compressed storage footprints over {{retention_period_years}} on {{cloud_platform}}.
  3. Assess write amplification and background compaction overhead under continuous ingestion streams.
  4. Compare candidate database engines against {{query_workload_type}} analytical query latency.
  5. Evaluate built-in continuous aggregate, downsampling, and automated data lifecycle policies.
  6. Score integration ease with {{utility_name}} ingestion pipelines and downstream billing systems.
  7. Map licensing models, managed service availability, and total cost of ownership across platforms.

Constraints

  • MUST evaluate at least three distinct database engines (e.g., relational time-series, distributed columnar, wide-column).
  • MUST score all evaluation dimensions on a clear 1 to 5 numerical scale with technical rationale.
  • MUST NOT recommend proprietary architectures that lack multi-availability-zone failover capabilities.
  • Storage and compression calculations MUST explicitly reflect typical meter payload schemas.

Output format

  1. Executive Evaluation Summary (2-3 sentences outlining key findings).
  2. Time-Series Database Evaluation Matrix (Markdown table with columns: Engine, Ingestion Throughput Score, Query Latency Score, Compression Efficiency, Operational Complexity, Cloud Fit, Overall Score).
  3. Recommended Target Architecture (bulleted recommendation under 150 words).

Self-review

  • Ingestion calculations align precisely with {{meter_count}} and {{ingestion_frequency}}.
  • Matrix scores reflect the specific demands of {{query_workload_type}}.
  • Storage lifecycle recommendations satisfy {{retention_period_years}} retention mandates.
AuraScore breakdown
83/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 engineering12/12 · Strong

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 efficiency7/10 · Adequate

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
smart-meters
time-series
database-selection