Live data from Hacker News

pg_timeseries: Open-source time-series extension for PostgreSQL

tembo.io

21–30 of 84 posts

Re: pg_timeseries: Open-source time-series extension for PostgreSQL

#21

Dumb question: why can't I just insert a bunch of rows with a timestamp column and indices? Where does that fall short? At a certain # of rows or something? What does this let me do that can't be achieved with "regular PostgreSQL without the extension"?

I'm with you, I need to read up more on where timeseries could benefit, at work we have a PostgreSQL instance with around 27 billion rows in a single partitioned table, partitioned by week. Goes back to January of 2017 and just contains tons of data coming in from sensors. It's not "fast", but also not ridiculously slow to say e.g. "Give me everything for sensor 29380 in March of 2019".

I guess depends on your needs but I do think I need to investigate timeseries more to see if it'd help us.

Re: pg_timeseries: Open-source time-series extension for PostgreSQL

#22

Dumb question: why can't I just insert a bunch of rows with a timestamp column and indices? Where does that fall short? At a certain # of rows or something? What does this let me do that can't be achieved with "regular PostgreSQL without the extension"?

It will work just fine.

Re: pg_timeseries: Open-source time-series extension for PostgreSQL

#23

Most of the time-series queries (almost all of them) are aggregated queries. Why not leverage or build top-notch Columnarstore for the same. Everything seems to be there and why there's not first class product like ClickHouse on PG.

Citus, Persona, TimescaleDB?

That was very "Klaatu, Barada, Nikto".

Re: pg_timeseries: Open-source time-series extension for PostgreSQL

#24
post #6

>You may already be asking: “why not just power the stack using TimescaleDB?” The Timescale License would restrict our use of features such as compression, incremental materialized views, and bottomless storage. With these missing, we felt that what remained would not provide an adequate basis for our customers’ time-series needs. Therefore, we decided to build our own PostgreSQL-licensed extension. Have been using t…

500 million is very little however. A regular table with a covering index would probably be fine for many use cases with this number of points.

Re: pg_timeseries: Open-source time-series extension for PostgreSQL

#25
post #6

>You may already be asking: “why not just power the stack using TimescaleDB?” The Timescale License would restrict our use of features such as compression, incremental materialized views, and bottomless storage. With these missing, we felt that what remained would not provide an adequate basis for our customers’ time-series needs. Therefore, we decided to build our own PostgreSQL-licensed extension. Have been using t…

500 million is very little however. A regular table with a covering index would probably be fine for many use cases with this number of points.

indeed. Financial timeseries I was working with over 100 million new points, _per day_. For anything serious TimescaleDB is essentially not open source. Well done tembo.io crew -- will definitely give this a whirl.

Re: pg_timeseries: Open-source time-series extension for PostgreSQL

#26
post #17

Earlier quoted context omitted.

Time based partitioning.

CREATE TABLE logs ( id SERIAL PRIMARY KEY, log_time TIMESTAMP NOT NULL, message TEXT ) PARTITION BY RANGE (log_time); Why won't this work on stock PostgreSQL?

read the docs, it's not saying that won't work. This extension along with timescale just makes some things more ergonomic.

Re: pg_timeseries: Open-source time-series extension for PostgreSQL

#27

Earlier quoted context omitted.

500 million is very little however. A regular table with a covering index would probably be fine for many use cases with this number of points.

indeed. Financial timeseries I was working with over 100 million new points, _per day_. For anything serious TimescaleDB is essentially not open source. Well done tembo.io crew -- will definitely give this a whirl.

What do you mean by "for anything serious it isn't open source"? I didn't see any red flags in the apache variant of timescale, just constant pleading to try their hosted option.

https://github.com/timescale/timescaledb/blob/main/LICENSE-A...

Re: pg_timeseries: Open-source time-series extension for PostgreSQL

#28
post #6

>You may already be asking: “why not just power the stack using TimescaleDB?” The Timescale License would restrict our use of features such as compression, incremental materialized views, and bottomless storage. With these missing, we felt that what remained would not provide an adequate basis for our customers’ time-series needs. Therefore, we decided to build our own PostgreSQL-licensed extension. Have been using t…

500 million is very little however. A regular table with a covering index would probably be fine for many use cases with this number of points.

I think you’re not talking about the same thing. There’s an expression related to time series data —- “high churn” and another “active time series”.

500 million active time series is extremely huge.

It does not have anything to do with number of data points.

Good time series databases can scale to 1M-10M writes per second without a hiccup.

Re: pg_timeseries: Open-source time-series extension for PostgreSQL

#30
post #27

Earlier quoted context omitted.

indeed. Financial timeseries I was working with over 100 million new points, _per day_. For anything serious TimescaleDB is essentially not open source. Well done tembo.io crew -- will definitely give this a whirl.

What do you mean by "for anything serious it isn't open source"? I didn't see any red flags in the apache variant of timescale, just constant pleading to try their hosted option. https://github.com/timescale/timescaledb/blob/main/LICENSE-A...

Compression and other features use the non-Apache license:

https://github.com/timescale/timescaledb/tree/main/tsl

Post reply on HN