You're Not Bad at Postgres. Your Workload Just Needs Extra Help.

You've been running Postgres for years. You know optimization. But every fix you ship buys three to six months, and then you're back in the same meeting, staring at the same graphs trending in the same wrong direction.

You're not doing anything wrong. I mean that.

There's a specific type of workload that vanilla Postgres was never designed to handle well, and most teams don't realize they're running it until they've burned a year on optimizations that were never going to stick. Trust me, I’ve seen it happen to folks firsthand, and it’s a very uncool situation to be in.

That workload type isn’t transactional, and neither is it a data warehouse. It's analytics on live data: high-frequency ingestion that stays operationally queryable. And if that describes your system, everything I'm about to say is going to feel uncomfortably familiar.

There are six characteristics that define this pattern. If four or five of them apply to you, the friction is architectural, not operational. (No amount of tuning fixes that.) I’ll walk you through them. 

1. Your database never gets a break

I'm not talking about high traffic. I'm talking about thousands to hundreds of thousands of inserts per second, continuously, 24/7. Like, semiconductor fabs with 8,000 machines each reporting telemetry every two seconds. Think financial systems capturing every order and fill in real time.

Batch systems can schedule maintenance around load windows. Continuous ingestion means autovacuum, index maintenance, and statistics collection are always fighting for resources against your writes. There is no off-peak. It's go go go all the time.

2. Time is how you think about your data

Every row has a timestamp. Every query filters on a time range. "Last 30 minutes." "This week vs. last week." "Between these two dates."

It's more than just a created_at column. This is time as the fundamental axis of both storage and retrieval. General-purpose B-tree indexes aren't built for that access pattern, which is exactly why you end up hand-rolling partitioning schemes and custom tooling to get time-range queries to perform. Does that sound fun to you? It doesn't to me.

3. You only INSERT

Once a row lands, it doesn't change. Sensor readings are facts. Financial transactions are immutable. Log entries don't get edited. When data leaves, it leaves in bulk. Drop an entire partition, not individual rows.

Okay, but MVCC exists to handle concurrent reads and writes on the same rows. Your append-only workload pays all that overhead on data it never touches again. Every insert carries 23 bytes of transaction metadata. Autovacuum runs constantly, cleaning up dead tuples that were never created through updates. At 50K inserts/sec, that's MVCC overhead on 4.3 billion rows per day that will never be modified.

You're paying for features you don't use. That's not awesome.

4. You keep data for months or years

Seven years of financial records for compliance. Quarters of manufacturing data for root cause analysis. Two-plus years for ML training pipelines.

Short retention hides the problem because old data ages out. Long retention removes that escape valve entirely. At 50K inserts per second, you're looking at 1.5 billion rows per year. After three years: 4.5 billion. Lots of billions. Every optimization you've done has to hold up against that full dataset. Good luck.

5. Latency matters

This isn't archival storage waiting for a weekly report. Your dashboards need sub-100ms responses on the last five minutes of data. Your alert evaluations need sub-500ms on the last hour. Your incident investigations pull three months of history and you need it in seconds, not minutes.

We're talking warehouse scope with operational latency requirements. From a single system. Oof.

6. Growth won't stop

Your data volume is growing 50-100%+ year over year on a predictable, sustained curve. Static workloads can be over-provisioned and left alone. Yours demands constant re-optimization.

Every optimization you ship today is solving for a table size you'll blow past in six months. The hamster wheel doesn't stop.

So what does this mean for you?

Count how many of those characteristics describe your system.

Two or three? Standard Postgres optimization should have real impact. Better indexes, smarter queries, autovacuum tuning. The usual playbook works, and you should use it. Have fun!

Four or five? That's architectural friction, not operational. I’ve got good news for you though - you don't have to abandon Postgres. Purpose-built Postgres variants like TimescaleDB (which powers Tiger Cloud) are designed for exactly this workload. You keep SQL. You keep your extensions. You keep your team's expertise and the entire Postgres ecosystem. What changes is the storage engine, partitioning, and query planning underneath.

The longer you wait, the harder the migration. At 10 million rows, it takes days. At 500 million, weeks. At a billion-plus, months. Recognizing the pattern early is the highest-leverage decision you'll make. Make the future you happy.

If this resonated and you want to understand the architectural side (how hypertables, hybrid row-columnar storage, and continuous aggregates address each of these six characteristics), the Tiger Data architecture whitepaper breaks it all down. Link in the comments.

I'm Matty Stratton, Head of Developer Relations at Tiger Data. I spend most of my time talking to engineering teams about the weird middle ground between transactional databases and data warehouses. It's a strange place to live, but somebody's gotta do it.