(Timescale engineer here) We are an extension on top of Postgres and not a whole new DBMS. That means that we inherit a lot of the reliability / stability of Postgres (critically we do not change the WAL/data on disk format which leads to the fact that even as a young database we don't loose data). What we provide on top of Postgres are significant optimization aimed at time-series data. Postgres is optimized for relational data, and it requires significant work to optimize it for time-series data workloads on both the insert and query side.
TimescaleDB provides automatic, adaptive partitioning of time-series tables to make management of time-series tables both easier and more efficient. We add new time-based analytical functions as well as improve query planning and optimization.
For new databases that I'm interested in, I generally check if there's a Jepsen analysis for it (https://jepsen.io/analyses) or whether it's being open-sourced by a company that's been using it in production for a while like Foundation DB (https://news.ycombinator.com/item?id=16877395). In either of these two cases I would say it's well-tested. Otherwise, it's often hit or miss. Thankfully the number of new db products I've seen is fewer than the halcyon days of the MongoDB wave (2011-2014) and tend to be a bit more focused on specific problems that the db solves.
Jepsen only tests distributed operation. For non-distributed databases (like PostgreSQL, which is — for the purposes of this discussion — what TimescaleDB is), Jepsen does not apply.
TimescaleDB provides automatic, adaptive partitioning of time-series tables to make management of time-series tables both easier and more efficient. We add new time-based analytical functions as well as improve query planning and optimization.