4 ms·

(Timescale Team member here) We've been working really hard on our launches / releases this month! We called it "Always Be Launching" - we've been aiming for r

(Timescale Team member here) We've been working really hard on our launches / releases this month! We called it "Always Be Launching" - we've been aiming for releasing multiple things per week during October :)

yumraj 5y ago
That sounds great. However, as a DB where users may store critical data, should you really be "Always be launching"? That sounds a little like FB's "move fast and break things". There's a reason why some of the mission critical open source technologies move slowly.
- mfreed 5y ago
  We actually are only having one database software release this month (TimescaleDB v2.5), which is aligned with our normal database release cadence. Timescale (the company) also provides a managed cloud offering, as well as Promscale (an observability product built on top of TimescaleDB). So #AlwaysBeLaunching is a company-wide effort across different product & engineering teams, as well as folks in Developer Advocacy and others (e.g., who worked on this comparison benchmarks). What might be also interesting is our introduction of Experimental Schema features in TimescaleDB - explicitly so that we can "Move fast, but don't break things" (which is also key to getting good community feedback): https://blog.timescale.com/blog/move-fast-but-dont-break-things-introducing-the-experimental-schema-with-new-experimental-features-in-timescaledb-2-4/ https://blog.timescale.com/blog/move-fast-but-dont-break-thi... (Timescale co-founder)
  - swyx 5y ago
    how long does #AlwaysBeLaunching last? seems like a good initiative but also might cause some burnout
- avthar 5y ago
  Timescale team member here. We take our responsibility to build a rock-solid platform very seriously. We have multiple "levels" of product within Timescale. At our core, we have the open-source database, TimescaleDB. This product releases on a more deliberate and careful cadence, always making sure that we are optimizing for reliability, security, and performance. This has been our approach since our initial launch [0], where we embraced the mantra "boring is awesome", recognizing that for our users stability and reliability is of paramount importance. Within the core database, we offer features that are carefully marked as "experimental", which we discuss at length in this blog post [1]. Beyond TimescaleDB, we also offer other products that are more SaaS-y in nature. While they're all based on the rock-solid foundation of TimescaleDB, we are also able to ship new features more quickly because they are UI components that make using the database even easier. Finally, some of our "launches" are more textual in nature, such as this benchmark, which we have spent months researching and compiling. [0]: https://blog.timescale.com/blog/when-boring-is-awesome-building-a-scalable-time-series-database-on-postgresql-2900ea453ee2/ https://blog.timescale.com/blog/when-boring-is-awesome-build... [1]: https://blog.timescale.com/blog/move-fast-but-dont-break-things-introducing-the-experi[…]l-schema-with-new-experimental-features-in-timescaledb-2-4/ https://blog.timescale.com/blog/move-fast-but-dont-break-thi...

yumraj 5y ago

That sounds great. However, as a DB where users may store critical data, should you really be "Always be launching"? That sounds a little like FB's "move fast and break things". There's a reason why some of the mission critical open source technologies move slowly.

mfreed 5y ago
We actually are only having one database software release this month (TimescaleDB v2.5), which is aligned with our normal database release cadence. Timescale (the company) also provides a managed cloud offering, as well as Promscale (an observability product built on top of TimescaleDB). So #AlwaysBeLaunching is a company-wide effort across different product & engineering teams, as well as folks in Developer Advocacy and others (e.g., who worked on this comparison benchmarks). What might be also interesting is our introduction of Experimental Schema features in TimescaleDB - explicitly so that we can "Move fast, but don't break things" (which is also key to getting good community feedback): https://blog.timescale.com/blog/move-fast-but-dont-break-things-introducing-the-experimental-schema-with-new-experimental-features-in-timescaledb-2-4/ https://blog.timescale.com/blog/move-fast-but-dont-break-thi... (Timescale co-founder)
- swyx 5y ago
  how long does #AlwaysBeLaunching last? seems like a good initiative but also might cause some burnout
avthar 5y ago
Timescale team member here. We take our responsibility to build a rock-solid platform very seriously. We have multiple "levels" of product within Timescale. At our core, we have the open-source database, TimescaleDB. This product releases on a more deliberate and careful cadence, always making sure that we are optimizing for reliability, security, and performance. This has been our approach since our initial launch [0], where we embraced the mantra "boring is awesome", recognizing that for our users stability and reliability is of paramount importance. Within the core database, we offer features that are carefully marked as "experimental", which we discuss at length in this blog post [1]. Beyond TimescaleDB, we also offer other products that are more SaaS-y in nature. While they're all based on the rock-solid foundation of TimescaleDB, we are also able to ship new features more quickly because they are UI components that make using the database even easier. Finally, some of our "launches" are more textual in nature, such as this benchmark, which we have spent months researching and compiling. [0]: https://blog.timescale.com/blog/when-boring-is-awesome-building-a-scalable-time-series-database-on-postgresql-2900ea453ee2/ https://blog.timescale.com/blog/when-boring-is-awesome-build... [1]: https://blog.timescale.com/blog/move-fast-but-dont-break-things-introducing-the-experi[…]l-schema-with-new-experimental-features-in-timescaledb-2-4/ https://blog.timescale.com/blog/move-fast-but-dont-break-thi...