---
title: "Time-Series Is Just Postgres: What You Get When You Don't Split the Architecture"
published: 2026-11-05T15:58:18.000-05:00
updated: 2026-11-05T15:58:18.000-05:00
excerpt: "You don't have to decide which data goes where, and a lot gets simpler once you stop drawing the line."
tags: PostgreSQL
authors: Matty Stratton
---

> **TimescaleDB is now Tiger Data.**

Most teams evaluating a time-series database are really asking how much of their data to move out of Postgres. For most of them, the time-series side is most of the data. That question comes from an era when that data had to live in a separate system. Postgres with TimescaleDB doesn't require the split. The payoff is that every decision you make after this one gets smaller.

Your time-series tables are getting big, the dashboards are getting slow, and someone has said the words "analytics database." Now you have a spreadsheet open with two columns, one labeled "stays" and one labeled "moves."

You're drawing a line through your own system, and you're quietly dreading the part where the application has to know about both sides. What happens to the join that used to be free? Who owns the query that spans the line? Cell shading as infrastructure strategy.

The line is optional. Most people find that out after they've drawn it.

## The split made sense

The belief goes like this. Time-series data belongs in a time-series system. Relational data stays in the relational one. The application stitches them together.

That was not a dumb idea. For a long stretch it was the idea that worked best. Row-oriented storage struggles with wide scans and aggregates, and purpose-built columnar engines were built for exactly that. ClickHouse is excellent at OLAP, and warehouses at historical batch. If you split your architecture a few years ago, you made a defensible call with what was available at the time. I'd have made it too.

You won't hear the belief stated out loud very often. It mostly shows up as an assumption baked into how the spreadsheet gets drawn.

## What changed

The belief is incomplete now, not wrong. Postgres was never the problem. It was missing the storage and query primitives that justified a second system, and those primitives now run inside Postgres: Tiger Data, the creators of TimescaleDB, ship them as an extension.

Take the pressures that pushed people toward a second system. Queries over history slow down as data piles up. A [hypertable](https://www.tigerdata.com/docs/learn/hypertables/understand-hypertables) is a Postgres table that partitions itself by time, so a query over last week skips everything older. New data wants fast writes and old data wants cheap scans, which is the job of hybrid row-columnar storage ([Hypercore](https://www.tigerdata.com/docs/learn/columnar-storage/understand-hypercore)): recent rows stay in row format, older data converts to columnar, same table. And nobody should babysit a batch job to keep rollups fresh. A [continuous aggregate](https://www.tigerdata.com/docs/learn/continuous-aggregates), an incrementally refreshed materialized view, handles the refresh in the background.

None of that is a database hiding inside a database. You query a hypertable with SQL, like any other table, with the same planner and the same tools your team already knows.

That shrinks the question. It used to be "which system handles this workload?" Now it's "which storage shape does this table want?" The consequences shrink with it.

## Name the workload

Time-series is a workload pattern, not a second database.

Any system where data accumulates continuously, and queries drift from point lookups toward scans and aggregates, hits the same wall, whatever industry it lives in. Drone telemetry hits it. So do ad impressions and billing events. The data looks different and the shape is identical. That's all "[just Postgres](https://www.tigerdata.com/blog/its-2026-just-use-postgres)" has to mean: one database, with a table that happens to have this shape.

Say the rule to your staff engineer the next time the spreadsheet comes out. If it survives that conversation, you've saved yourself a diagram.

## What gets smaller

Four things get smaller when the data stays in one place. Each is a design decision you stop having to make.

### Joins stop being an architecture problem

Picture a wearables company. Per-device heart rate readings sit next to accounts, billing, and demographics. Then product asks for family-level stats: every wearable in a household, rolled up. In one database, that's a join:

```sql
-- hypertable joined to a plain table
SELECT
  d.family_id,
  avg(w.heart_rate) AS avg_hr
FROM wearable_readings w
JOIN devices d ON d.id = w.device_id
WHERE w.time > now() - INTERVAL '7 days'
GROUP BY d.family_id;
```

Across two systems, the same ask tends to become a project. Either the time-series side learns about families, or the application queries each family member separately and does the aggregation itself. Here it stays a query.

[Robert Cepa, Senior Software Engineer at Cloudflare](https://blog.cloudflare.com/timescaledb-art/), put the underlying idea better than I can: "For many teams at Cloudflare, TimescaleDB strikes a phenomenal balance between the simplicity of storing your analytical data under the same roof as your configuration data, while also gaining much of the impressive performance of a specialized OLAP system."

### Correctness lives in the database

Say an alert fires when a customer's error rate crosses a threshold that depends on their current plan. That's the last five minutes of readings joined to a billing row someone edited this morning. In one database, both sides are current by definition. With the data in two places, the answer is as fresh as the last sync. Split architectures trade analytical speed for that window, and when someone makes that trade deliberately, it's often a fair one. If the answer has to be right as of now, you don't have to take it.

Rollups are the exception. A continuous aggregate [refreshes on a policy you set](https://www.tigerdata.com/blog/continuous-aggregate-refresh-demystified). Turn on [real-time aggregation](https://www.tigerdata.com/docs/learn/continuous-aggregates/real-time-aggregates), which has been off by default since TimescaleDB 2.13, and queries blend in the raw rows that haven't been rolled up yet. The raw table is always current.

### Extensions stop being placement decisions

Split the architecture and every new capability raises the question of which side gets it. Stay on one Postgres, and [PostGIS](https://www.tigerdata.com/docs/deploy/tiger-cloud/tiger-cloud-aws/tiger-cloud-extensions/postgis), [full-text search](https://www.tigerdata.com/docs/learn/search/using-pg-textsearch) and [pgvector](https://www.tigerdata.com/docs/learn/search/pgvector-pgvectorsearch) all work across your data. Take a drone fleet: positions (geospatial), timestamps (time), and the operator, airframe, and mission (relational), all in one query.

### Changes happen at the database layer

Say product wants the wearable stats broken out by subscription tier, and tier lives in the billing tables. That's a join and a GROUP BY. Once the data sits on both sides of a line, the change has to live wherever something can see both, which means the application. The question to ask about any future feature is where its change lands. On one Postgres, the answer is the database.

## What this looks like for one team

A pre-revenue startup doing vehicle tracking had four vehicles live, about twenty expected, and telemetry at five to ten hertz. By the time we talked, they were running Redis for the live view, TimescaleDB for a two-week warm window, their own object storage for anything older, and a separate Postgres for the relational data. Four systems, no customers onboarded yet. By their own account, the tiering was a call made to save money before revenue.

Moving the relational data into the same database was the first easy yes. By our estimate, that's a `pg_dump` and under an hour, because they were early enough that there was almost nothing to move. Then geospatial came up, because they'd been eyeing PostGIS, which runs in the same database too.

Then, while answering a sizing question, they mentioned Redis and the object storage almost in passing, and the conversation turned to whether either needed to be there at all.

Redis was the interesting one, so we tested it. On a simulated version of their load, with room for several times the fleet they expect, a plain table for where each vehicle is right now and a hypertable for what it did recently kept up comfortably on a small instance. Same database, two storage shapes, chosen table by table.

They're keeping Redis for now, and that's a reasonable choice. At their size it's the cheaper option, and they're pre-revenue, the same logic that put their history on object storage in the first place. The test answered whether the database could do the job. Whether it's worth it yet is a money question, and right now the money says Redis.

That's a competent team, and the story isn't finished: their relational and time-series data are set to move in together, and Redis stays until the math changes.

## Count how many apply

Try this on the system you're about to build. It's about the shape of the system. Whether plain Postgres has outgrown a table is a different question (for that, see [when Postgres is enough and when it isn't](https://www.tigerdata.com/learn/time-series-database-vs-relational-database)). Count how many of these are true.

-   Will a query ever need to join time-ordered data to something a human typed or configured?
-   Does the answer need to be correct as of now, rather than as of the last sync?
-   Will this system get new features in the next twelve months?
-   Do you want geospatial, full-text, or vector search near this data?
-   Will more than one team query this data (support, finance, data science) and expect plain SQL?

Zero or one? A split architecture may be the right call, and I'll say so out loud. You can close this tab.

Two or three? Hold off on drawing the line. Look at where the data you were about to split actually joins. If the relational side is already in Postgres, keeping the time-series table beside it costs little. If it lives somewhere else, sizing that move is the real work, and it's better to know that up front.

Four or five? The boundary you're about to draw will be load-bearing for a long time, and it's worth asking whether you need it at all.

## Where to start

Keeping one database costs you a few primitives to learn. The boundary costs you again every time the system changes. One of those is a purchase, and the other is a subscription.

Time-series is a workload pattern, not a second database.

[Start a Tiger Cloud trial](https://tigerdata.com/go/trial), put your time-series table next to the relational tables it joins to, and run the join you were dreading. If it reads like any other Postgres query, you've learned the boundary was optional before you drew it.