Your Rails App Isn’t Slow—Your Database Is

In case you missed the quiet launch of our timescaledb-ruby gem, we’re here to remind you that you can now connect PostgreSQL and Ruby when using TimescaleDB. 🎉 This integration delivers a deeply integrated experience that will feel natural to Ruby and Rails developers.

How to Scale Your Rails App Analytics with TimescaleDB

If you’ve worked with Rails for any length of time, you’ve probably hit the wall when dealing with time-series data. I know I did.

Your app starts off smooth—collecting metrics, logging events, tracking usage. But one day, your dashboards start lagging. Page load times creep past 10 seconds. Pagination stops helping. Background jobs queue up as yesterday’s data takes too long to process.

This isn’t a Rails problem. Or even a PostgreSQL problem. It’s a “using the wrong tool for the job” problem.

In this post, I’ll show you how we solve these challenges at Timescale—and how you can too. I’ll walk through the real implementation patterns we use in production Rails apps, using practical code examples instead of abstract concepts.

The Growing Time-Series Data Challenge

A few years ago, I was building analytics for a high-traffic Rails app. Despite adding indexes and optimizing queries, performance kept degrading as our data grew.

Like most apps, we started with simple timestamp columns and standard ActiveRecord queries:

class Event < ApplicationRecord
  scope :recent, -> { where('created_at > ?', 1.week.ago) }
  scope :by_day, -> { group("DATE_TRUNC('day', created_at)").count }
end

This works fine at first. But as your table grows to millions (or billions) of rows, things slow to a crawl:

• 5ms when you have 10K rows
• 2000ms when you have 10M rows Event.where(user_id: 123).by_day

And the problems compound when you need to:

• Track high-volume events (like API calls or page views)
• Keep historical data accessible for trends
• Run complex aggregations across time
• Maintain dashboard performance as data scales

Over the years, I tried all the usual tricks:

• Additional indexes: Helped at first, then hurt insert performance
• Manual partitioning: Fragile and hard to manage
• Pre-aggregation jobs: Complex and often stale
• Custom caching: Difficult to maintain, always a step behind

It felt like fighting my database instead of working with it.

Why PostgreSQL Falls Short for Time-Series

PostgreSQL is a fantastic general-purpose database. But time-series data introduces new demands that standard Postgres tables aren’t designed for. Let’s break that down:

• Insertion pattern: Data constantly arrives in time order, but old data rarely changes
• Query pattern: Most queries use time bounds (WHERE created_at BETWEEN x AND y)
• Aggregation pattern: You’re grouping by time (hourly, daily, monthly)
• Storage pattern: The dataset grows linearly—forever
• Access pattern: Recent (hot) data is queried far more than older (cold) data

These characteristics expose several pain points:.

• No built-in partitioning for time
• Index bloat as tables grow
• Inefficient time-based queries
• Manual rollups and background jobs
• Difficulty managing large historical datasets

And that’s exactly where TimescaleDB comes in.

TimescaleDB: PostgreSQL, But Built for Time-Series

TimescaleDB is a PostgreSQL extension built to handle time-series and real-time workloads—without giving up the safety and simplicity of Postgres.

Now with the timescaledb Ruby gem, it integrates cleanly into Rails. You don’t have to leave behind ActiveRecord, or rewrite your models, or learn a whole new stack.

Here’s what TimescaleDB brings to your Rails app:

• Hypertables: Automatic time-based partitioning, transparent to your queries
• Optimized time indexes: Stay fast even as your data grows
• Built-in compression: Reduce storage by 90–95%
• Continuous aggregates: Pre-computed rollups that stay fresh automatically

And most importantly? You keep your Rails patterns.

These work just like before:

Event.where(user_id: 123).where(created_at: 1.month.ago..Time.now)
Event.group_by_day(:created_at).count  # using the groupdate gem

Real Performance Gains Without Rewriting Everything

With Timescale, our analytics workflows went from laggy to fast—without adding new caching layers or complex ETL.

Across production workloads, teams have seen:

• Sub-second queries on tens of millions of rows
• 95%+ compression on time-series datasets
• Fewer background jobs, thanks to continuous aggregates
• Simplified code—no more rollup scripts or cache warmers

It feels like your app leveled up, without any extra complexity.

Continuous Aggregates in One Line of Ruby

One of TimescaleDB’s most powerful features is continuous aggregates—think materialized views that update automatically in the background.
And with the timescaledb gem, defining them looks like this:

class Download < ApplicationRecord
  extend Timescaledb::ActsAsHypertable
  include Timescaledb::ContinuousAggregatesHelper

  acts_as_hypertable time_column: 'ts'

  scope :total_downloads, -> { select("count(*) as total") }
  scope :downloads_by_gem, -> { select("gem_name, count(*) as total").group(:gem_name) }

  continuous_aggregates(
    timeframes: [:minute, :hour, :day, :month],
    scopes: [:total_downloads, :downloads_by_gem]
  )
end

This single model creates a cascade of continuously updated rollups—from minute to month—all while sticking to the ActiveRecord patterns you know and love.

Why It Matters

If you're building a Rails app that tracks metrics, logs, events, or any kind of time-based data, TimescaleDB gives you a clear path to scale without duct tape and complexity.

• Reduce load on your app servers—let the DB do the aggregating
• Eliminate complex background jobs—less moving parts to break
• Get predictable performance—even with billions of rows
• Stick with Rails conventions—write less custom SQL
• Continuous aggregates alone can replace dozens of lines of rollup - code and hours of maintenance work.

Try It Yourself

Rails developers deserve a time-series database that just works. TimescaleDB gives you the performance and scale your app needs without giving up the elegance of ActiveRecord.

If you’re curious, here’s how to get started:

• Install TimescaleDB (it’s just a Postgres extension)
• Add the timescaledb gem to your Gemfile
• Identify models with time-based data
• Start with hypertables, then add continuous aggregates as needed

You can self-host, or try Timescale Cloud for a fully managed option.

FAQ: TimescaleDB for Ruby on Rails Developers

Q: Do I need to change how I use ActiveRecord?

A: Nope! TimescaleDB works with your existing ActiveRecord models. Just add the timescaledb gem and use the acts_as_hypertable macro to enable time-series functionality.

Q: How is TimescaleDB different from just using PostgreSQL?

A: TimescaleDB is a PostgreSQL extension. It gives you automatic time-based partitioning (hypertables), faster time-based queries, built-in compression, and continuous aggregates—all while staying 100% SQL- and Rails-compatible.

Q: Can I keep using the gems I already use for date grouping, like groupdate?

A: Yes. TimescaleDB works seamlessly with gems like groupdate. You can continue using .group_by_day, .group_by_hour, etc., and get better performance under the hood.

Q: What kind of performance improvements can I expect?

A: Teams have seen sub-second query times on tens of millions of rows and 95%+ storage savings using TimescaleDB’s compression. The biggest wins are in read-heavy, time-bounded queries (e.g., user activity, logs, metrics).

Q: What’s the learning curve for continuous aggregates?

A: It’s minimal. The timescaledb gem lets you define continuous aggregates using a simple DSL that reuses your existing scopes. You don’t need to learn new SQL or create custom rollup jobs.

Q: Can I use this in production? Is it stable?

A: Yes. TimescaleDB powers production workloads at companies like NetApp, Linktree, and RubyGems.org. It’s backed by years of performance and reliability improvements.

Q: Do I need to self-host? Or is there a managed option?

A: Both! You can self-host TimescaleDB or use Timescale Cloud, a fully managed PostgreSQL service with built-in TimescaleDB, HA, backups, and usage-based pricing.

Q: Where can I learn more?

A:

• Ruby Quickstart in Timescale Docs
• GitHub: timescaledb-ruby
• Fully Managed Timescale Cloud (free for 30 days)
• Install the open-source TimescaleDB extension