9 ms·

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 r

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
> 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). So I personally like your company, but I find these sorts of marketing speak responses obnoxious. Your communications strategy here is causing brand harm, not benefit. 1) You have an open source core, with proprietary components. 2) Open source adopters get a crippled product. 3) You have a custom license for the proprietary components, which is designed to allow people to make some use of those, but is poorly-written ambiguous (preventing many types of commercial use), non-open-source compatible (preventing integration into open source projects), and requires a lawyer to review (preventing integration by smaller projects). This feels like your Achilles' Heel. Troll Tech tried to go down this line for years, with their QPL license. And they even had sane messaging, where whenever I read your messaging, it feels weaselly, and it changes week-to-week. Still, they didn't really take off until they went with a licensing system customers could trust and understand. The standard dual-license model would be AGPL and commercial (or GPL+commercial). * Most open source developers won't mind (or even notice) licenses, so long as their open source and have the nice OSI and FSF logos. * Most commercial companies won't mind paying $$$. Commercial customers treat you like Microsoft. Open source developers treat you like community members. Hybrid customers are okay too; if I'm working on a piece of BSD code, I can use the AGPL license on your code, while commercial users of my code can buy a commercial license from you. And if you insist on the crazy custom license, figure out the messaging. This was better than what I read before. "Proprietary with a public repo" makes more sense than previous messaging which sounded like open source but wasn't. At that point, at least the license overdelivers rather than underdelivers. I still trust that at some point, as an adopter who can't or won't use those components, they'll become increasingly mandatory if you ever fall on hard times. The problem is still that it makes it sound like you have open source and proprietary products. You don't. You have a product with open source and proprietary components, a confused freemium model, and not something I'd ever use without consulting a good lawyer, who in turn would tell me to stay away. There are many other good models. You could go in the other direction and close up a bit too.
dataviz1000 5y ago
Lately, I've been studying machine learning, from point zero, with a focus on time series analysis. Two months in already completed a course on Python and another book on Pandas, several hundreds of hours later in the fourth chapter in a book I paid for on deep learning and time series analysis they provided me with the most important information I needed: there is no evidence deep learning works better than traditional statistical analysis using classical methods like SARIMA and ETS. Sure, great, if an academic is interested in theory hopefully making a breakthrough, however, the rest of us who are interested in applied should stick with the classical methods. I was going to write a lot here but I'll keep it short. What I discovered is that everything I want to do can best be done in PostgreSQL. It's one thing to do data analysis in a Python notebook and another in an environment that works dynamically on a server. My first guess was to do the heavy lifting in Python with Numpy, Pandas, and machine learning and have the node server -- instead of Django and if I'm learning a new web framework it will be Phoenix -- execute the Python scripts through stdin / stdout. Since started I learned that I don't need machine learning and that I can do the calculations inside PostgreSQL sometimes orders of magnitude faster than in Python. I'm using TimescaleDB which provides the postgresSQL time_bucket() function and with chunks should scale very well. First I tried to integrate it with Prisma in node, however, that proved to be far too difficult and convoluted. I reverted back to using TypeORM in node and it was extremely easy to run all the boilerplate code to initialize the TimescaleDB plugin inside of migrations which would probably be just as easy in another framework like Phoenix with Ecto. Sometimes I use SQL queries in a string literal and other times I use the query builder for more dynamic interaction with the database and to leverage some of TypeORM's other features beyond only being a connection manager. What I discovered which interestingly someone yesterday shared a popular link to a blog post on the subject[0], for most of time series analysis, Pandas isn't required and perhaps not the fastest solution. Grokking window function was a little difficult until I found this lecture on YouTube, Postgres Window Magic[1]. Leveraging and understand window function in SQL is probably the most important skill to have. I don't need Python and Pandas for time series analysis. I can using TimescaleDB and some increased knowledge of using PostgreSQL do time series analysis using all the same infrastructure I've been using for the past several years. [0] https://hakibenita.com/sql-for-data-analysis https://hakibenita.com/sql-for-data-analysis [1] https://www.youtube.com/watch?v=D8Q4n6YXdpk https://www.youtube.com/watch?v=D8Q4n6YXdpk

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

> 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). So I personally like your company, but I find these sorts of marketing speak responses obnoxious. Your communications strategy here is causing brand harm, not benefit. 1) You have an open source core, with proprietary components. 2) Open source adopters get a crippled product. 3) You have a custom license for the proprietary components, which is designed to allow people to make some use of those, but is poorly-written ambiguous (preventing many types of commercial use), non-open-source compatible (preventing integration into open source projects), and requires a lawyer to review (preventing integration by smaller projects). This feels like your Achilles' Heel. Troll Tech tried to go down this line for years, with their QPL license. And they even had sane messaging, where whenever I read your messaging, it feels weaselly, and it changes week-to-week. Still, they didn't really take off until they went with a licensing system customers could trust and understand. The standard dual-license model would be AGPL and commercial (or GPL+commercial). * Most open source developers won't mind (or even notice) licenses, so long as their open source and have the nice OSI and FSF logos. * Most commercial companies won't mind paying $$$. Commercial customers treat you like Microsoft. Open source developers treat you like community members. Hybrid customers are okay too; if I'm working on a piece of BSD code, I can use the AGPL license on your code, while commercial users of my code can buy a commercial license from you. And if you insist on the crazy custom license, figure out the messaging. This was better than what I read before. "Proprietary with a public repo" makes more sense than previous messaging which sounded like open source but wasn't. At that point, at least the license overdelivers rather than underdelivers. I still trust that at some point, as an adopter who can't or won't use those components, they'll become increasingly mandatory if you ever fall on hard times. The problem is still that it makes it sound like you have open source and proprietary products. You don't. You have a product with open source and proprietary components, a confused freemium model, and not something I'd ever use without consulting a good lawyer, who in turn would tell me to stay away. There are many other good models. You could go in the other direction and close up a bit too.

dataviz1000 5y ago

Lately, I've been studying machine learning, from point zero, with a focus on time series analysis. Two months in already completed a course on Python and another book on Pandas, several hundreds of hours later in the fourth chapter in a book I paid for on deep learning and time series analysis they provided me with the most important information I needed: there is no evidence deep learning works better than traditional statistical analysis using classical methods like SARIMA and ETS. Sure, great, if an academic is interested in theory hopefully making a breakthrough, however, the rest of us who are interested in applied should stick with the classical methods. I was going to write a lot here but I'll keep it short. What I discovered is that everything I want to do can best be done in PostgreSQL. It's one thing to do data analysis in a Python notebook and another in an environment that works dynamically on a server. My first guess was to do the heavy lifting in Python with Numpy, Pandas, and machine learning and have the node server -- instead of Django and if I'm learning a new web framework it will be Phoenix -- execute the Python scripts through stdin / stdout. Since started I learned that I don't need machine learning and that I can do the calculations inside PostgreSQL sometimes orders of magnitude faster than in Python. I'm using TimescaleDB which provides the postgresSQL time_bucket() function and with chunks should scale very well. First I tried to integrate it with Prisma in node, however, that proved to be far too difficult and convoluted. I reverted back to using TypeORM in node and it was extremely easy to run all the boilerplate code to initialize the TimescaleDB plugin inside of migrations which would probably be just as easy in another framework like Phoenix with Ecto. Sometimes I use SQL queries in a string literal and other times I use the query builder for more dynamic interaction with the database and to leverage some of TypeORM's other features beyond only being a connection manager. What I discovered which interestingly someone yesterday shared a popular link to a blog post on the subject[0], for most of time series analysis, Pandas isn't required and perhaps not the fastest solution. Grokking window function was a little difficult until I found this lecture on YouTube, Postgres Window Magic[1]. Leveraging and understand window function in SQL is probably the most important skill to have. I don't need Python and Pandas for time series analysis. I can using TimescaleDB and some increased knowledge of using PostgreSQL do time series analysis using all the same infrastructure I've been using for the past several years. [0] https://hakibenita.com/sql-for-data-analysis https://hakibenita.com/sql-for-data-analysis [1] https://www.youtube.com/watch?v=D8Q4n6YXdpk https://www.youtube.com/watch?v=D8Q4n6YXdpk