>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.<p>Have been using the free version timescaledb before to shard a 500 Million observation time series database. Worked drop-in without much hassle. Would have expected some benchmarks and comparisons in the post. I will for sure watch this...
Looking at their roadmap, the killer feature for me would be incremental materialised views<p>> Incremental view maintenance — define views which stay up-to-date with incoming data without the performance hit of a REFRESH<p>I wonder if they plan to incorporate something like <a href="https://github.com/sraoss/pg_ivm">https://github.com/sraoss/pg_ivm</a> or write their own implementation.<p>(Although I'm hopeful that one day we see ivm land in postgres core)
Former Timescaler here.<p>It's about time that Timescale started getting what it deserves.<p>Sometime in early 2022, just as they raised their Series C, leadership decided that they had gotten what they wanted from the open-source community and TimescaleDB. They decided it was time to focus 100% on Timescale Cloud. Features began to become exclusive to Timescale Cloud, and the self-hosted TimescaleDB was literally treated as competition. At the same time, they managed to spoil their long-time PaaS partnership with Aiven, which was (and still is) a major source of revenue for the company. The reason? Everyone needed to use Timescale Cloud and give their money to Timescale, thus making Aiven a competitor. In short, with the raising of Series C, Timescale stopped being an OSS startup and began transitioning to a money hungry corporation.<p>In 2023, they conducted two rounds of layoffs, even though the company was highly profitable. Recently, Planetscale also carried out layoffs in a similarly harsh manner as Timescale, but at least Planetscale had the "courtesy" to address this with two sentences in their PR statement about company restructuring. Timescale did not even do that; they kept it all quiet. Out of 160 employees, around 65 were laid off. The first round of layoffs occurred in January, and the second in September. No warnings. No PIPs. Just an email informing you that you no longer work for them. Many of the affected employees were in the middle of ongoing projects. The CEO even mentioned in the in-house memo how they diligently worked on the September layoff throughout the summer. Interestingly, many of these employees were hired by competitors like Supabase and Neon. It’s worth emphasizing that this was not a financial issue—Timescale is far from having such problems. Instead, it was a restructuring effort to present nice financial numbers during ongoing turbulence in the tech market. (And yes, you guessed it! Timescale also hired their first CFO a couple of months before the first layoffs.)<p>You might say that it's just business, but as an OSS startup, I expect them to live by the values they have advertised over the years and treat their users and employees much better than they currently do. With this in mind, I welcome Tembo as a new player in the time-series market.<p>Footnotes: Timescale = the company. TimescaleDB = OSS time-series database developed by Timescale. Timescale Cloud = TimescaleDB managed by Timescale on AWS.
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?<p>What does this let me do that can't be achieved with "regular PostgreSQL without the extension"?
Most of the time-series queries (almost all of them) are aggregated queries.
Why not leverage or build top-notch Columnarstore for the same.<p>Everything seems to be there and why there's not first class product like ClickHouse on PG.
Thank you for posting it: I followed the links and found out about trunk and <a href="https://pgt.dev/" rel="nofollow">https://pgt.dev/</a>
Great to see this kind of innovation. PostgreSQL is interesting while "core" was always Open Source and using very permissive Open Source library, there have been many proprietary and source available extensions, ranging from replication to time series support.<p>Now we see those Proprietary extensions being disrupted by proper Open Source!
Interesting release, it feels that the time-series database landscape is evolving toward:<p>a) columnar store & built from scratch, with convergence toward open formats such as parquet & arrow: influxdb 3.0, questdb<p>b) Adding time-series capabilities on top of Postgres: timescale, pg_timeseries<p>c) platforms focused on observability around the Prometheus ecosystem: grafana, victoria metrics, chronosphere
Would this be a good extension when you want to load balancer log entries (status, response body, headers etc)?<p>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.
It's about time that postgres (and other databases) add native append-only tables. That doesn't make it timeseries, but it probably helps with the standardiziation and all the logic/access around it.