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 ti

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...