HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
timescale
timescaledb
C2017–2026
timescale / timescaledb

timescaledb

A time-series database for high-performance real-time analytics packaged as a Postgres extension

46Distinct people
71Mentions
0Explicit recommenders
23.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A time-series database for high-performance real-time analytics packaged as a Postgres extension

GitHub

Where it is used

  • Titan America — Titan America runs Tiger Cloud with multiple services that run TimescaleDB to ingest and store its sensor data. TimescaleDB serves as the operational engine for their time-series workloads in the deployment. Source
  • Tiger Data — “But we took a different, heretical route: we decided to build TimescaleDB on top of Postgres, a 20-year-old, seemingly boring database.” Source
  • 2 more documented examples

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:04:58 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year71 dated mentions

Observed mentions: 2017-04-04 18:28:40 UTC to 2026-06-15 19:27:40 UTC.

051015202017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 20 mentions; 0 submissions, 20 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 7 mentions; 2 submissions, 5 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC606
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC1019
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC707
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC20020
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC707
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC808
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC725
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC202

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
TimescaleDB is a PostgreSQL extension for high-performance real-time analytics on time-series and event data Quick Start with TimescaleDB Get started with TimescaleDB in under 10 minutes. This guide will help you run TimescaleDB locally, create your first hypertable with columnstore enabled, write data to the columnstore, and see instant analytical query performance. What You'll Learn How to run TimescaleDB with a one-line install or Docker command How to create a hypertable with columnstore enabled How to insert data directly to the columnstore How to execute analytical queries Prerequisites Docker installed on your machine 8GB RAM recommended psql client (included with PostgreSQL) or any PostgreSQL client like pgAdmin Step 1: Start TimescaleDB You have two options to start TimescaleDB: Option 1: One-line install (Recommended) The easiest way to get started: Important: This script is intended for local development and testing only. Do not use it for production deployments. For production-ready installation options, see the TimescaleDB installation guide. Linux/Mac: curl -sL https://tsdb.co/start-local | sh This command: Downloads and starts TimescaleDB (if not already downloaded) Exposes PostgreSQL on port 6543 (a non-standard port to avoid conflicts with other PostgreSQL instances on port 5432) Automatically tunes settings for your environment using timescaledb-tune Sets up a persistent data volume Option 2: Manual Docker command also used for Windows Alternatively, you can run TimescaleDB directly with Docker: docker run -d --name timescaledb \ -p 6543:5432 \ -e POSTGRES_PASSWORD=password \ timescale/timescaledb-ha:pg18 Note: We use port 6543 (mapped to container port 5432) to avoid conflicts if you have other PostgreSQL instances running on the standard port 5432. Wait about 1-2 minutes for TimescaleDB to download & initialize. Step 2: Connect to TimescaleDB Connect using psql: psql -h localhost -p 6543 -U postgres # When prompted, enter password: password You should see the PostgreSQL prompt. Verify TimescaleDB is installed: SELECT extname, extversion FROM pg_extension WHERE extname = 'timescaledb'; Expected output: extname | extversion -------------+------------ timescaledb | 2.x.x Prefer a GUI? If you'd rather use a graphical tool instead of the command line, you can download pgAdmin and connect to TimescaleDB using the same connection details (host: localhost, port: 6543, user: postgres, password: password). Step 3: Create Your First Hypertable Let's create a hypertable for IoT sensor data with columnstore enabled: -- Create a hypertable with automatic columnstore CREATE TABLE sensor_data ( time TIMESTAMPTZ NOT NULL, sensor_id TEXT NOT NULL, temperature DOUBLE PRECISION, humidity DOUBLE PRECISION, pressure DOUBLE PRECISION ) WITH ( tsdb.hypertable ); tsdb.hypertable - Converts this into a TimescaleDB hypertable See more: About hypertables API reference About columnstore Enable columnstore manually API reference Step 4: Insert Sample Data Let's add some sample sensor readings: -- Enable timing to see time to execute queries \timing on -- Insert sample data for multiple sensors -- SET timescaledb.enable_direct_compress_insert = on to insert data directly to the columnstore (columnnar format for performance) SET timescaledb.enable_direct_compress_insert = on; INSERT INTO sensor_data (time, sensor_id, temperature, humidity, pressure) SELECT time, 'sensor_' || ((random() * 9)::int + 1), 20 + (random() * 15), 40 + (random() * 30), 1000 + (random() * 50) FROM generate_series( NOW() - INTERVAL '90 days', NOW(), INTERVAL '1 seconds' ) AS time; -- Once data is inserted into the columnstore we optimize the order and structure -- this compacts and orders the data in the chunks for optimal query performance and compression DO $$ DECLARE ch TEXT; BEGIN FOR ch IN SELECT show_chunks('sensor_data') LOOP CALL convert_to_columnstore(ch, recompress := true); END LOOP; END $$; This generates ~7,776,001 readings across 10 sensors over the past 90 days. Verify the data was inserted: SELECT COUNT(*) FROM sensor_data; Step 5: Run Your First Analytical Queries Now let's run some analytical queries that showcase TimescaleDB's performance: -- Enable query timing to see performance \timing on -- Query 1: Average readings per sensor over the last 7 days SELECT sensor_id, COUNT(*) as readings, ROUND(AVG(temperature)::numeric, 2) as avg_temp, ROUND(AVG(humidity)::numeric, 2) as avg_humidity, ROUND(AVG(pressure)::numeric, 2) as avg_pressure FROM sensor_data WHERE time > NOW() - INTERVAL '7 days' GROUP BY sensor_id ORDER BY sensor_id; -- Query 2: Hourly averages using time_bucket -- Time buckets enable you to aggregate data in hypertables by time interval and calculate summary values. SELECT time_bucket('1 hour', time) AS hour, sensor_id, ROUND(AVG(temperature)::numeric, 2) as avg_temp, ROUND(AVG(humidity)::numeric, 2) as avg_humidity FROM sensor_data WHERE time > NOW() - INTERVAL '24 hours' GROUP BY hour, sensor_id ORDER BY hour DESC, sensor_id LIMIT 20; -- Query 3: Daily statistics across all sensors SELECT time_bucket('1 day', time) AS day, COUNT(*) as total_readings, ROUND(AVG(temperature)::numeric, 2) as avg_temp, ROUND(MIN(temperature)::numeric, 2) as min_temp, ROUND(MAX(temperature)::numeric, 2) as max_temp FROM sensor_data GROUP BY day ORDER BY day DESC LIMIT 10; -- Query 4: Latest reading for each sensor -- Highlights the value of Skipscan executing in under 100ms without skipscan it takes over 5sec SELECT DISTINCT ON (sensor_id) sensor_id, time, ROUND(temperature::numeric, 2) as temperature, ROUND(humidity::numeric, 2) as humidity, ROUND(pressure::numeric, 2) as pressure FROM sensor_data ORDER BY sensor_id, time DESC; Notice how fast these analytical queries run, even with aggregations across millions of rows. This is
Read the full README on GitHub

What Hacker News says

10 sources
Hi @ddorian43, Timescale person here. I assume the question is asking more about TimescaleDB, rather than an HA solution that is shard-aware in is View management? We're in the process of building our own scale-out clustering solution, so that the many chunks that belong to a hypertable (some users have 10,000s of such chunks per hypertable) can be spread across many servers, rather than on a single primary as currently. ( Plan is to release this coming year; you can already see some PRs hit out public github about changes for this effect: https://github.com/timescale/timescaledb/pull/904 )
In Evaluating high availability solutions for TimescaleDB and PostgreSQL
Funny timing... just installed 1.0 rc1 this week. Dual-writing and experimenting reading from TimescaleDB in prod currently. So far it's been perfect... besides a small config issue[1] causing a crash that should have been detected when Postgres starts up, TimescaleDB gives me reliability and durability of Postgres without having to manually create partition tables. What will happen when Postgres supports auto creating partition tables for declarative partitioning[2]? Will TimescaleDB still be necessary? Feature request 1: when all rows of a chunk/partition table are deleted can that chunk be automatically dropped instead of having to manually run drop_chunks[3]? Feature request 2: for the getting started docs, add an option to install with https://nixos.org [1]: https://github.com/timescale/timescaledb/issues/733 [2]: https://www.postgre
Read the rest
In First release candidate for TimescaleDB 1.0
Fellow Timescaler here. Thanks for the feedback. While we do not directly compare ingestion protocol and specific features, like continuous queries and retention polices (something I guess we could add), we do compare echosystems and third-party tools support, including ingestion (e.g., Kafka, Hibernate) and visualization (e.g., Tableau, Grafana). In fact, the developer behind the Grafana PostgreSQL data source is also a Timescaler, and an upcoming version of the data source will have an improved query builder and first-class TimescaleDB support. Finally, I can assure you that this is more than a few input scripts. In fact, the project is thousands of lines of C code (if that matters) that implement automatic partitioning, query optimizations, and much more. Our code is open source here: https://github.com/timescale/timescaledb We have ot
Read the rest
her blog posts (http://blog.timescale.com) and system documentation (http://docs.timescale.com) that explain what we're doing if you're interested in learning more about the details.
In TimescaleDB vs. InfluxDB: built differently for time-series data
I believe what akulkarni meant to talk about is relation accesses (and not just locks). While the partition pruning certainly improved things, two sources of inefficiency still remain in PG 11: 1) Fetching statistics for each table during queries (which happens by reading from the data file off of disk). This happens /before/ pruning, even on PG 11. 2) The overhead of locking each table is still there. Although it's a smaller issue than (1). We at TimescaleDB found (1) to be the most significant overhead and in fact we have significantly improved things there [1]. [1]https://github.com/timescale/timescaledb/commit/b7257fc8f483...
In TimescaleDB vs. InfluxDB: built differently for time-series data
We're looking into Timescale to replace our InfluxDB servers as we've found InfluxDB to be resource-hungry, the lack of open source clustering is also a problem. The use of PostreSQL in Timescale is a big selling point, it's something we know how to manage and scale. A big stumbling block though is with the retention of older data. For now we do mainly service/machine monitoring and event logging without needing high granularity for older data and keeping disk usage contained. For this we've found InfluxDB to be well suited, as the retention policy system is easy to set up and fits our needs perfectly. Do you plan on introducing similar functionality in Timescale? I've found this issue in Github but don't know if this is something that is being pursued for the official product. https://github.com/timescale/timescaledb/issues/350
In Postgres as the Substructure for IoT and the Next Wave of Computing
Influx founder and CTO here. I figure I should comment because it seems this post is a bit dated on information. That being said, I think this is one of those cases where based on where InfluxDB was at the time, they simply picked the wrong tool for the job. We were looking at use cases with hundreds of thousands of series. It just wasn't designed for what they were trying to do (for whatever version they were running at the time). We have much higher aspirations now, but I'll get to that in a bit when I talk to each point raised in the post. As I mentioned, it would be helpful to know which version of InfluxDB was tested against, but I'll try to cover each of the points. 1 - Cardinality. High cardinality has long been a known problem for InfluxDB. We started work on this almost 15 months ago to create a new feature called TSI or Time Ser
Read the rest
ies Index. It was significantly harder for us to develop than we thought it would be. It can be enabled on version 1.5, which was released yesterday. We'll have a detailed whitepaper on how it works and what techniques we used coming soon. It shows significantly lower memory usage for high cardinality write workloads. The other side of this is query, which I'll talk about in a bit. 2 - Rollup tables is a known issue for us. Continuous queries were originally supposed to do this, but the problem is that it falls over at scale. There are some other weird things about how it works where it won't pick up lagged data collection. It's a weak spot for us, Prometheus, OpenTSDB and a bunch of other solutions. From what I can tell, Timescale doesn't offer this feature either. See https://github.com/timescale/timescaledb/issues/350. It sounds like DNSFilter implemented this themselves using their Kafka ingest pipeline and computing them and inserting into Timescale tables (which for now is exactly what we recommend with InfluxDB). If I'm guessing wrong, I'd love to hear the detail about how this works in your solution. 3 - Ingestion performance vs. Query performance. It sounds like query load causes ingestion performance to degrade. I really don't know without more information. In the post Mike said they were working with InfluxDB in 2015 and 2016 and didn't continue upgrading. So they could have been running 0.11.0, a version that is now over two years old. We've made significant improvements since then. However, I will say that our current query engine is a known weak spot. This is why we're investing heavily into IFQL (our new language and engine). The new language also addresses the InfluxQL doesn't actually operate like SQL, which is something he mentions at the top of the post. I agree that can cause frustration, which is why we're designing our new language around this use case. I think the functional paradigm makes more sense than SQL for time series. Slides from a recent talk I gave about the engine: Slides: https://speakerdeck.com/pauldix/ifql-and-the-future-of-influ... Video: https://www.youtube.com/watch?v=QuCIhTL2lQY&list=PLYt2jfZork... 4 - Resource utilization. It uses RAM, particularly on high cardinality workloads. Yes, we know this and have known it for a long time. Running tests on 1.5 with TSI enabled, the RAM utilization is significantly lower. However, TSI is only one side of the issue. The other side is querying high cardinality data. Our current query engine will eat many resources trying to do this. It's something we're addressing with the IFQL engine. You can actually use the new engine as a separate process against the InfluxDB 1.5 release. However, it's still under heavy work and we haven't begun the performance optimizations. I'm confused how Mike talks about about their query processor and then immediately dives into Kafka, which is only relevant in the ingestion pipeline. In fact, our recommended configuration is to route writes through Kafka before sending to InfluxDB if you're operating at scale. It's how we're designing 2.0 from day 1 and that work has already started. In an analytics pipeline, you want to separate your write pipeline from production query/storage. 1 - Ease of change: schema changes in InfluxDB aren't easy. Postgres supports alter table commands. How do these work on large tables? Has Timescale (or Postgres) solved the problem of these kinds of operations taking the DB down for a while? I think that's one of the strengths of having Kafka in their ingestion pipeline to protect against it (or other DB issues). We still need to do work here and I know it's a weak spot and it's honestly just a very hard problem (for how data is stored on disk for us). In the future, at the very least we'll enable users to kick a schema change off and have it run in the background while keeping the production infrastructure up. Depending on the change it might be a long running background task that requires rewriting many things. 2 - Performance - Impossible to address without knowing their data, their queries, and really testing it on a new version. We're optimizing all the time. I guarantee you that the query performance you see in InfluxDB today won't be anything close to as good as what it'll be a year from now. 3 - No missing data - I don't know of any issue in the current release (or many previous releases) of Influx that just drops writes. This might be something to do with Continuous Queries since it sounded like it was about rollups. It's a known issue with that feature and it's being completely reworked in 2.0 to work in a guaranteed way, at scale. It's a long running problem and one that is hard to get right. Again, it sounds like Mike and team implemented it themselves through their ingestion pipeline and then attributed the gain to Timescale. You can do the same thing with InfluxDB and it's our recommended architecture. We tell customers to do their downsampling I'm not sure what is going on with deletes. You can do deletes in Influx and you can delete by a time range, which would give you a specific point. That being said we've done significant work in the last three releases to improve how deletes work and particularly how they work for deleting large amounts of data. For loads, I'd really like to see a comparison against the 1.5 release with TSI on compared to Timescale. A release that's 1.5 to 2 years old with InfluxDB is completely different that what is current, as many people that have been watching the project over the last 4 years has seen. Finally, Mike does make a case at the end for Timescale just being SQL and Postgres so they found it easy to use because it's familiar. For better or worse, we're making the bet that SQL isn't the last only true API for working with time series data. Some developers will prefer SQL and some will prefer other approaches. For InfluxDB, we're making a bet that other approaches will be better for developer productivity.
In Why DNSFilter replaced InfluxDB with TimescaleDB

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.