51–60 of 84 posts
> Incremental view maintenance — define views which stay up-to-date with incoming data without the performance hit of a REFRESH
I wonder if they plan to incorporate something like https://github.com/sraoss/pg_ivm or write their own implementation.
(Although I'm hopeful that one day we see ivm land in postgres core)
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.
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 tricky thing with these licenses (BSL, SSPL, etc.) is that you can use them freely for internal stuff, but suddenly, if you make your product public (assuming it uses, e.g., TimescaleDB), things can get muddy. Everyone wants the flexibility to either open-source or commercialize a successful internal product in the future. The problem is that, even if your app is not a mere frontend for TimescaleDB/Mongo/Redis, y…
There is 0% chance Timescale would sue mom’n’pop operation for breaking their license.
Interesting, how does it compare to proper (open source) time series database like InfluxDB other than being 'Postgres' like ?
InfluxDB is a "proper" time series database?
They're on their third serious rewrite with breaking changes for users. They pulled features from the open source version (clustering) to have a higher moat for the Enterprise version. They deleted customer data permanently in their hosted version after sending two emails to billing addresses. Their marketing and product naming also sucks:
InfluxDB InfluxDB Cloud Serverless InfluxDB Cloud Dedicated InfluxDB Clustered
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.
If you have 100 million points per day it’s likely you afford to pay any commercial license.
Earlier quoted context omitted.
If you have 100 million points per day it’s likely you afford to pay any commercial license.
Why would the number of data points correlate to budget? Perhaps there’s a chance if the business scales with paying users, but that’s unlikely to be true in finance.
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?
Which is, basically, saying that you can do anything that doesn’t give your customers the ability to redefine and modify the database schema as long as you are creating a product that is adding value on top of timescale. Is any of this 100% clear? Not any more that legalese generally is, and of course probably wise to talk to a lawyer if you’re concerned about it. Timescale has made their intent with the license clear in the past with blog posts and such though.
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"?
Earlier quoted context omitted.
Why would the number of data points correlate to budget? Perhaps there’s a chance if the business scales with paying users, but that’s unlikely to be true in finance.
At that number of observations, I would assume depth of market data so probably HFT use case. HFT is notoriously expensive to try to compete in