Skip to content

Add declarative data lifecycle configuration profiles for hypertables and continuous aggregates #107

@jonatas

Description

@jonatas

Currently, configuring the complete data lifecycle for TimescaleDB hypertables and their continuous aggregates requires multiple separate method calls and configurations. This proposal suggests adding a declarative configuration API that would allow developers to define comprehensive data management profiles in a more intuitive and maintainable way.

Proposed API

Timescaledb.profile(:default) do |config|
  config[:chunk_time_interval] = 1.day
  config[:compress_after] = 1.week
  config[:drop_after] = 5.years
  config[:continuous_aggregates] = {
    compress_after: 1.week,
    chunk_time_interval: 1.year,
    timeframes: [:minute, :daily, :yearly]
  }
end

This would internally translate to the appropriate TimescaleDB commands:

create_table(name, hypertable: :default)

or

create_table(name, hypertable: {profile: :default, **overrides})

Benefits

  1. Single source of truth for data lifecycle configuration
  2. More maintainable and easier to understand at a glance
  3. Consistent configuration across environments
  4. Easier to implement best practices for data retention and aggregation

Implementation Considerations

  • Should support multiple named profiles (e.g., :default, :archive, :metrics)
  • Need to handle existing hypertables and continuous aggregates gracefully
  • Consider validation of timeframes and intervals
  • May need to support custom view definitions for continuous aggregates

Questions for Discussion

  • Should we support different compression policies for different columns?
  • How should we handle updates to existing profiles?
  • What's the best way to represent custom view definitions while maintaining the simplicity of the configuration?

Next Steps

  1. Get community feedback on the proposed API
  2. Define the complete configuration schema
  3. Create a proof of concept implementation
  4. Document migration path for existing applications

Would love to hear thoughts from the community on this approach. The goal is to make TimescaleDB's powerful features more accessible while maintaining flexibility for advanced use cases.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions