BBbbrazil·Sep 15, 2017
There's already a two-way integration between Prometheus and TimescaleDB: https://github.com/timescale/pg_prometheus
In InfluxDB now supports Prometheus remote reads and writes nativelytimescale
pg_prometheus
C2017–2020
timescale / pg_prometheus · Archived
pg_prometheus
PostgreSQL extension for Prometheus data
4Distinct people
7Mentions
0Explicit recommenders
217GitHub stars
What to know before exploring
What it is
PostgreSQL extension for Prometheus data
GitHub
Where it is used
No documented product use has been verified yet.
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
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 4:01:40 AM 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 year7 dated mentions
Observed mentions: 2017-08-11 04:55:45 UTC to 2020-07-21 18:23:52 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
4 sourcesA common approach we find for storing devops-related time-series data (as you'd find with influx), is to not denormalize the "labels" or "tag set" into the main metrics table.
This obviously saves significant space just by avoiding denormalization, ignoring the indexing overhead as well. You can see that in our Prometheus extension, btw:
https://github.com/timescale/pg_prometheus#user-content-norm...
Regarding performance against Influx, it really depends. We're working on releasing more complex benchmarks soon.
But overall, they have a performance edge if it's a single column scan that precisely matches their particular architecture (e.g., WHERE clause or GROUP BY by a very specific label set). But, we've found that Timescale actually gets higher query performance across a whole set of pretty natural queries (sometimes ridiculously so,
Read the rest
as Influx doesn't index numerical values). Plus higher insert rates and full SQL. Not only is the latter point important for enabling many more types of complex queries, but it means that any viz or reporting tool that already speaks to Postgres should just work with us.
Well...sorta. Postgres/Timescale have pretty rich support for JSON these days (and its more efficient "binary" JSONB), so there are a whole range of options you can do that make it feel much more schema-less than before.
In fact, last month we released a beta version of a Prometheus connector for Timescale/Postgres that allows you to store arbitrary Prometheus metrics without pre-defining all these varied schemas:
https://github.com/timescale/pg_prometheus
The same approach should work for Telegraf, we just haven't yet tried to generalize this plugin.
In Timescale, an open-source time-series SQL database for PostgreSQLIf the viz tool can speak to Postgres, it works with Timescale. Tableau, Superset, SQLPad, Mode, Plot.ly, etc.
We internally use Grafana through a REST interface to a timescale backend. (And in fact, that's how we visualize the Prometheus data we store in Timescale: https://github.com/timescale/pg_prometheus )
But, Grafana Labs is still working on a native Postgres connector (MySQL released earlier this year). They promise us soon :)
In Timescale, an open-source time-series SQL database for PostgreSQL