10 ms·

TimescaleDB is a great product, but if you plan to go with them long term, there are few points to consider: * They are still trying to figure out their moneti

TimescaleDB is a great product, but if you plan to go with them long term, there are few points to consider: * They are still trying to figure out their monetization strategy. Initially, they betted on their on-premise Enterprise version, then abandoned it. Now they are pushing their cloud version. * Even though most of their code licensed under Apache license, some code is under their proprietary license. * I'm sure one can get some ideas about their development directions from their issue tracker and source code, but they don't have any public product roadmap. * Even though the product itself is technically very stable, the version compatibility leaves a lot to be desired. There are removed features and broken APIs from version to version. * Their commercial support terms for on-premise instances don't seem to be well defined, not publicly at least.

akulkarni 5y ago
Timescale Co-founder here. Happy to address your concerns! 1. Monetization strategy This funding round is actually a sign that our business model is working really well. To quote Redpoint Ventures, who led this funding round: "The [Timescale] team capitalized on their significant community momentum last year, with their cloud business being one of the fastest-growing database businesses we have seen in the past 20+ years." [0] 2. Licensing Most companies (including open-source companies) actually have both open-source and proprietary software, but the proprietary software is often hidden inside private repos. The difference with Timescale is that we have made the source code for our proprietary software available (on Github), even allowing users to modify it (eg "right to repair), and made all of our software free (ie no paid software features). [1] 3. Public product roadmap We aim to be transparent re: product roadmap via Github, blog posts, etc, but I appreciate the feedback that we could be more transparent. Thanks! 4. Version compatibility / broken APIs Could you say more? AFIAK the only time we "broke" (ie changed) some APIs is with TimescaleDB 2.0, and when we did so we explained why we did that (mostly to improve user experience based on feedback). We take this topic very seriously and even the decision to do so in 2.0 was not something we did lightly (and it was also made after a lot of discussion with users). More about this decision here in our docs: [2] 5. Commercial support for on-premise We offer free support for on-premise instances via Slack (where you can often find our engineers, support team, CTO, and myself). [3] However, if you would like a higher level of support for on premise (e.g., commercial SLAs), please reach out to us directly (e.g., via the form on that same page). [3] Hope this helps! [0] https://medium.com/redpoint-ventures/building-a-next-generation-database-our-investment-in-timescale-59e9a1d1d6f9 https://medium.com/redpoint-ventures/building-a-next-generat... [1] https://blog.timescale.com/blog/building-open-source-business-in-cloud-era-v2/ https://blog.timescale.com/blog/building-open-source-busines... [2] https://docs.timescale.com/timescaledb/latest/overview/release-notes/changes-in-timescaledb-2/ https://docs.timescale.com/timescaledb/latest/overview/relea... [3] https://www.timescale.com/support https://www.timescale.com/support
- Croftengea 5y ago
  Thanks a lot for the straightforward response! As for 4 - yes, I meant 2.0 and also removal of adaptive chunking in the earlier versions.
  - mfreed 5y ago
    Fair point about adaptive chunking. You sound like a long-term user! There is always a trade-off between getting features to users quickly to experiment and incrementally improve, versus doing it always very conservatively. When we launched adaptive chunking (introduced in 0.11, deprecated in 1.2), we explicitly marked it as beta and default off, to hopefully reflect that. [1] The approach we are now taking with Timescale Analytics [2] is to have an explicit distinction between experimental features (which will be part of a distinct "experimental" schema in the database, and must be expressly turned on with appropriate warnings) and stable features. Hopefully this can help find a good balance between stability and velocity, but feedback welcome! [1] https://github.com/timescale/timescaledb/releases/tag/0.11.0 https://github.com/timescale/timescaledb/releases/tag/0.11.0 [2] https://github.com/timescale/timescale-analytics/tree/main/extension/docs https://github.com/timescale/timescale-analytics/tree/main/e...
- mfreed 5y ago
  To follow up Ajay's point, we really do take compatibility and stability seriously. I believe that our "major version" upgrade from 1.x to 2.0 was the first time we changed/broke any APIs, but that involved a long beta/RC process, much documented about the changes [1], and upgrades that also meant to seamlessly migrate. For example, upgrading from 1.x to 2.0 was still just running `ALTER EXTENSION timescaledb UPGRADE`. The main difference was if you were, for example, using some of our informational views in your applications, those had a change a bit. Or if you were querying internal catalogs in your app (although that is never recommended =) Even after 2.0 was launched, we did backport bug fixes to some follow-on 1.x releases, and continued to support users running 1.x on our cloud platform. [1] https://docs.timescale.com/timescaledb/latest/overview/release-notes/changes-in-timescaledb-2/ https://docs.timescale.com/timescaledb/latest/overview/relea...
- woofie11 5y ago
3pt14159 5y ago
For background, I haven't used TimescaleDB before, but I've done some pretty advanced ORM work to vertically shard PG tables in Rails and I know PG pretty well, so I'm quite curious about TimescaleDB. > * Even though most of their code licensed under Apache license, some code is under their proprietary license. I don't really think this is a perfectly fair characterization. Their proprietary license is essentially "don't host a cloud database and charge for it" to stop Amazon from building TimescaleDB right into RDS, or similar. I think it's a totally fair license without too much to worry about if they go out of business. > * Even though the product itself is technically very stable, the version compatibility leaves a lot to be desired. There are removed features and broken APIs from version to version. This would be my biggest worry. Upgrading Postgres is already stressful enough, having to deal with broken APIs from version to version would leave me pretty upset, though I've not heard of anyone complain about this before, so I'm not sure how much of a problem this is in practice.
- lurkerasdfh8 5y ago
  > > * Even though most of their code licensed under Apache license, some code is under their proprietary license. > I don't really think this is a perfectly fair characterization. Their proprietary license is essentially "don't host a cloud database and charge for it" to stop Amazon from building TimescaleDB right into RDS, or similar. "yeah, go ahead, infringe that copyright and host a internal/for-direct-clients only database, because i guess that would be OK from their license, even though it is not explicitly allowed" pardon the sarcasm, but i literally heard that from our lawyers today regarding another project's license, as something (quoting again) "no lawyer would ever say to their clients".
  - mfreed 5y ago
    We did work carefully with IP counsel to make sure this type of thing is pretty buttoned-up and expressly permitted: https://www.timescale.com/legal/licenses#section-2-1-grant https://www.timescale.com/legal/licenses#section-2-1-grant
    - 3pt14159 5y ago
DetroitThrow 5y ago
Even though it is proprietary, I appreciate the current fine print in their current Timescale license compared to most other proprietary licenses. It doesn't have scary ambiguous language that could apply to even small, non-cloud-provider users that the SSPL contains, and they have nice "we won't sue you" clauses that were written favorably for users. At least that's what I think, I'd want to hear kemitchell's review of the most recent iteration of their license, I think it incorporates much of what he's discussed as the correct legal direction for open-except-for-clouds licenses which strikes the right balance between user protections and safe guards against cloud providers.
cperciva 5y ago
they betted Just in case you're not a native English speaker: The verb "to bet" is irregular and the past tense is simply "they bet" rather than "betted" (which would be far more logical).
- Croftengea 5y ago
  Thanks for pointing out! You're right, I'm not a native speaker. Some dictionaries list it as an alternative form though: https://www.collinsdictionary.com/dictionary/english/bet https://www.collinsdictionary.com/dictionary/english/bet
  - cperciva 5y ago
    Right, the dictionary is not your friend here. It is true that "betted" is occasionally used... but we're talking maybe 1% of usage, and mostly in older text. I recommend sticking with "bet".
manigandham 5y ago
People want to buy services not software, that's why they go to the cloud in the first place. Vendors keep fighting this to their own detriment so it's nice to see Timescale is actually giving customers what they want. Modifying business models to optimize for success is a good thing, not a negative.

akulkarni 5y ago

Timescale Co-founder here. Happy to address your concerns! 1. Monetization strategy This funding round is actually a sign that our business model is working really well. To quote Redpoint Ventures, who led this funding round: "The [Timescale] team capitalized on their significant community momentum last year, with their cloud business being one of the fastest-growing database businesses we have seen in the past 20+ years." [0] 2. Licensing Most companies (including open-source companies) actually have both open-source and proprietary software, but the proprietary software is often hidden inside private repos. The difference with Timescale is that we have made the source code for our proprietary software available (on Github), even allowing users to modify it (eg "right to repair), and made all of our software free (ie no paid software features). [1] 3. Public product roadmap We aim to be transparent re: product roadmap via Github, blog posts, etc, but I appreciate the feedback that we could be more transparent. Thanks! 4. Version compatibility / broken APIs Could you say more? AFIAK the only time we "broke" (ie changed) some APIs is with TimescaleDB 2.0, and when we did so we explained why we did that (mostly to improve user experience based on feedback). We take this topic very seriously and even the decision to do so in 2.0 was not something we did lightly (and it was also made after a lot of discussion with users). More about this decision here in our docs: [2] 5. Commercial support for on-premise We offer free support for on-premise instances via Slack (where you can often find our engineers, support team, CTO, and myself). [3] However, if you would like a higher level of support for on premise (e.g., commercial SLAs), please reach out to us directly (e.g., via the form on that same page). [3] Hope this helps! [0] https://medium.com/redpoint-ventures/building-a-next-generation-database-our-investment-in-timescale-59e9a1d1d6f9 https://medium.com/redpoint-ventures/building-a-next-generat... [1] https://blog.timescale.com/blog/building-open-source-business-in-cloud-era-v2/ https://blog.timescale.com/blog/building-open-source-busines... [2] https://docs.timescale.com/timescaledb/latest/overview/release-notes/changes-in-timescaledb-2/ https://docs.timescale.com/timescaledb/latest/overview/relea... [3] https://www.timescale.com/support https://www.timescale.com/support

Croftengea 5y ago
Thanks a lot for the straightforward response! As for 4 - yes, I meant 2.0 and also removal of adaptive chunking in the earlier versions.
- mfreed 5y ago
  Fair point about adaptive chunking. You sound like a long-term user! There is always a trade-off between getting features to users quickly to experiment and incrementally improve, versus doing it always very conservatively. When we launched adaptive chunking (introduced in 0.11, deprecated in 1.2), we explicitly marked it as beta and default off, to hopefully reflect that. [1] The approach we are now taking with Timescale Analytics [2] is to have an explicit distinction between experimental features (which will be part of a distinct "experimental" schema in the database, and must be expressly turned on with appropriate warnings) and stable features. Hopefully this can help find a good balance between stability and velocity, but feedback welcome! [1] https://github.com/timescale/timescaledb/releases/tag/0.11.0 https://github.com/timescale/timescaledb/releases/tag/0.11.0 [2] https://github.com/timescale/timescale-analytics/tree/main/extension/docs https://github.com/timescale/timescale-analytics/tree/main/e...
mfreed 5y ago
To follow up Ajay's point, we really do take compatibility and stability seriously. I believe that our "major version" upgrade from 1.x to 2.0 was the first time we changed/broke any APIs, but that involved a long beta/RC process, much documented about the changes [1], and upgrades that also meant to seamlessly migrate. For example, upgrading from 1.x to 2.0 was still just running `ALTER EXTENSION timescaledb UPGRADE`. The main difference was if you were, for example, using some of our informational views in your applications, those had a change a bit. Or if you were querying internal catalogs in your app (although that is never recommended =) Even after 2.0 was launched, we did backport bug fixes to some follow-on 1.x releases, and continued to support users running 1.x on our cloud platform. [1] https://docs.timescale.com/timescaledb/latest/overview/release-notes/changes-in-timescaledb-2/ https://docs.timescale.com/timescaledb/latest/overview/relea...
woofie11 5y ago

3pt14159 5y ago

For background, I haven't used TimescaleDB before, but I've done some pretty advanced ORM work to vertically shard PG tables in Rails and I know PG pretty well, so I'm quite curious about TimescaleDB. > * Even though most of their code licensed under Apache license, some code is under their proprietary license. I don't really think this is a perfectly fair characterization. Their proprietary license is essentially "don't host a cloud database and charge for it" to stop Amazon from building TimescaleDB right into RDS, or similar. I think it's a totally fair license without too much to worry about if they go out of business. > * Even though the product itself is technically very stable, the version compatibility leaves a lot to be desired. There are removed features and broken APIs from version to version. This would be my biggest worry. Upgrading Postgres is already stressful enough, having to deal with broken APIs from version to version would leave me pretty upset, though I've not heard of anyone complain about this before, so I'm not sure how much of a problem this is in practice.

lurkerasdfh8 5y ago
> > * Even though most of their code licensed under Apache license, some code is under their proprietary license. > I don't really think this is a perfectly fair characterization. Their proprietary license is essentially "don't host a cloud database and charge for it" to stop Amazon from building TimescaleDB right into RDS, or similar. "yeah, go ahead, infringe that copyright and host a internal/for-direct-clients only database, because i guess that would be OK from their license, even though it is not explicitly allowed" pardon the sarcasm, but i literally heard that from our lawyers today regarding another project's license, as something (quoting again) "no lawyer would ever say to their clients".
- mfreed 5y ago
  We did work carefully with IP counsel to make sure this type of thing is pretty buttoned-up and expressly permitted: https://www.timescale.com/legal/licenses#section-2-1-grant https://www.timescale.com/legal/licenses#section-2-1-grant
  - 3pt14159 5y ago

DetroitThrow 5y ago

Even though it is proprietary, I appreciate the current fine print in their current Timescale license compared to most other proprietary licenses. It doesn't have scary ambiguous language that could apply to even small, non-cloud-provider users that the SSPL contains, and they have nice "we won't sue you" clauses that were written favorably for users. At least that's what I think, I'd want to hear kemitchell's review of the most recent iteration of their license, I think it incorporates much of what he's discussed as the correct legal direction for open-except-for-clouds licenses which strikes the right balance between user protections and safe guards against cloud providers.

cperciva 5y ago

they betted Just in case you're not a native English speaker: The verb "to bet" is irregular and the past tense is simply "they bet" rather than "betted" (which would be far more logical).

Croftengea 5y ago
Thanks for pointing out! You're right, I'm not a native speaker. Some dictionaries list it as an alternative form though: https://www.collinsdictionary.com/dictionary/english/bet https://www.collinsdictionary.com/dictionary/english/bet
- cperciva 5y ago
  Right, the dictionary is not your friend here. It is true that "betted" is occasionally used... but we're talking maybe 1% of usage, and mostly in older text. I recommend sticking with "bet".

manigandham 5y ago

People want to buy services not software, that's why they go to the cloud in the first place. Vendors keep fighting this to their own detriment so it's nice to see Timescale is actually giving customers what they want. Modifying business models to optimize for success is a good thing, not a negative.