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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 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

71 sources
No, that's an interesting idea though. Hard to imagine how that would help with the code correctness issues, though. I haven't even dug into algorithmic correctness yet so I have no real idea whether there's room for improvement there--although I sure do suspect there is! EDIT: Oh my. After digging into the code I found this gem: fn encode_rle(&self, value: u64, count: usize) -> u64 { let selector = Simple8bSelector::RLE as u64; (selector << 60) | ((count as u64) << 30) | (value & 0x3FFFFFFF) } And this one: fn try_rle(&self, input: &[u64]) -> Option<(u64, usize)> { if input.is_empty() { return None; } let value = input[0]; let mut count = 1; for &x in input.iter().skip(1) { if x != value || count >= 0x3FFFFFFF { // Max 30-bit run length break;
Read the rest
} count += 1; } Some((value, count)) } What even is going on here? Compare to an actually sane implementation like[1] or[2]. [1]https://github.com/lemire/FastPFor/blob/master/headers/simpl... [2]https://github.com/timescale/timescaledb/blob/403782a5899c75...
In Everything I built with Claude Artifacts this week
You can use the TimescaleDB PostgreSQL extension. It works really well and has a high compression rate for time series data, such as metrics. It can also downsample data. I have also tried InfluxDB, but you have to rewire your mental model to fit InfluxDB (it has its own query syntax and internal mechanism). They have versions v1, v2, and v3, and it's not clear which one to use, probably v2 at this point in time. It's kind of confusing and the state of development is very much in flux. I think TimescaleDB works well up to the single-digit terabyte range (according to various sources). If you need a solution in the multi-digit terabyte or petabyte range, then you probably need something like a distributed VictoriaMetrics setup. https://github.com/timescale/timescaledb
In PostgreSQL is enough
Great questions. BigQuery reduces storage costs as even before their recent pricing change, the cost per GB [0] is on par with and slightly lower than s3 storage costs [0], which we can use as a estimated market price for data storage. BigQuery makes money off the querying costs, which we take steps to optimize and minimize, with table partitions, caching, and ui design, both client side and server side. These all help to reduce querying costs. Table partitioning also helps to cut per-GB storage costs by half by switching to long-term logical storage after 90 days. Of course, using blog storage might possibly result in comparable cost, however, relying on blob storage would likely increase the querying costs (in terms of GET requests) as well as complexity to query across multiple stored objects/buckets, as opposed to relying on BQ to han
Read the rest
dle the querying. In the long term, we would likely continue using BQ for our platform infrastructure, unless GCP changes their pricing in a way that adversely affects us. When it comes to self-hosting, it would of course depend on how much complexity one would like to take on, and out-sourcing the storage and querying management is a better option in most cases. We would not rule out such features, but we consider them nice-to-have features and are very far down the priority list. At the moment we're mostly focused on improving integration with the Supabase products and platform. It is actually possible to log stack traces, and is supported out-of-the-box for certain integrations such as the Logflare Logger Backend [2]. Postgres without any extensions is not optimized for columnar storage, and would not be an optimal experience for such large scale data storage and querying. It is also not advisable to use the same production datastore for both your application and your observability, it is better to keep them separate to avoid coupling. If one really wants to use the same Postgres server for everything, there are extensions that allow for Postgres to work as a columnar store, such as citus[3] and timescaledb[4], and we have not ruled out supporting these extensions as Logflare backends. [0]: https://cloud.google.com/bigquery/pricing#storage [1]: https://aws.amazon.com/s3/pricing/ [2]: https://github.com/Logflare/logflare_logger_backend [3]: https://github.com/citusdata/citus [4]: https://github.com/timescale/timescaledb edit: Ah looks like Chase answered as well :)
In Supabase Logs: open-source logging server
I do want to note Timescale's license is extremely generous: https://github.com/timescale/timescaledb/blob/main/tsl/LICEN... There's a marked difference between what they allow you vs Mongo (SSPL) and Elastic (Elastic license) -- see (b). Also generally the Postgres ecosystem has in general seemingly found a way to strike a balance between creating immense value (point to a F/OSS DB that's better than Postgres) and enabling commercial success (Citus, 2nd Quadrant, EDB, Timescale, Supabase, Neon are all very successful) I do agree with the overall trend though -- I already think the future is going to be AGPL[0] (but that's based partially on a misunderstanding of what AGPL does). It remains to be seen if people will cynically make projects open source to start and then switch to something like SSPL/BSL/Elastic later, but the unintentional
Read the rest
rug pulls will probably continue for a while. [0]: https://vadosware.io/post/the-future-of-free-and-open-source...
In The Dead End

Showing the 15 most recent of 71 sources. Enable JavaScript to search and browse every indexed mention.

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.