41–50 of 84 posts
Earlier quoted context omitted.
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.
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.
The gold standard for this Druid at very large scale, or ClickhouseDB. Clickhouse has a lot of problems as far as modifying/scaling shards after the fact, while Druid handles this with ease (and the penalty of not being able to update after the fact.)
Would love to use this with RDS!
Interesting, how does it compare to proper (open source) time series database like InfluxDB other than being 'Postgres' like ?
Earlier quoted context omitted.
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
(Which is to say that if, like Tembo, you’re offering Postgres as a service you do indeed have a problem. But for other use, should be fine)
Earlier quoted context omitted.
Compression and other features use the non-Apache license: https://github.com/timescale/timescaledb/tree/main/tsl
And as I understand that license, you are allowed to use Timescale for anything that doesn’t involve offering Timescale itself as a service. If you were using Timescale to process lots of time series transactions in your backend, it doesn’t seem to me like that would break the license. (Which is to say that if, like Tembo, you’re offering Postgres as a service you do indeed have a problem. But for other use, should b…
The problem is that, even if your app is not a mere frontend for TimescaleDB/Mongo/Redis, you can get sued, and you'll have to spend unnecessary time and money proving things in court. No one wants this, especially a startup owner whose money and time are tight. Also, even if your startup/company uses some of these techs, potential company buyers will be very wary of the purchase if they know they'll have to deal with this later.
Earlier quoted context omitted.
Compression and other features use the non-Apache license: https://github.com/timescale/timescaledb/tree/main/tsl
And as I understand that license, you are allowed to use Timescale for anything that doesn’t involve offering Timescale itself as a service. If you were using Timescale to process lots of time series transactions in your backend, it doesn’t seem to me like that would break the license. (Which is to say that if, like Tembo, you’re offering Postgres as a service you do indeed have a problem. But for other use, should b…
Legally, what's a wrapper? Is a REST API a wrapper?
I think a columnar database store would be more efficient than normal row-based databases? load balancer log entries could be considered something similar to analytics events.
a) columnar store & built from scratch, with convergence toward open formats such as parquet & arrow: influxdb 3.0, questdb
b) Adding time-series capabilities on top of Postgres: timescale, pg_timeseries
c) platforms focused on observability around the Prometheus ecosystem: grafana, victoria metrics, chronosphere
Earlier quoted context omitted.
And as I understand that license, you are allowed to use Timescale for anything that doesn’t involve offering Timescale itself as a service. If you were using Timescale to process lots of time series transactions in your backend, it doesn’t seem to me like that would break the license. (Which is to say that if, like Tembo, you’re offering Postgres as a service you do indeed have a problem. But for other use, should b…
The license doesn't allow you to "give access to, directly or indirectly (e.g., via a wrapper) to [SQL]". Legally, what's a wrapper? Is a REST API a wrapper?
e.g. timescaledb going after a tsdb as a service company offering tsdb behind a graphql wrapper vs timescaledb going after a financial company offering timeseries data collection and viewing.
I think a good border test would be, would timescaledb allow you to offer a metrics and logging service? technically you're offering timeseries database functionality, but it's in a constrained domain, and very clearly a different product, but still effectively CRUDing timeseries data.