4 ms·
We are working on benchmarks comparing ourselves to other solutions so hopefully we'll have concrete numbers on those soon. (Incidentally, we did a blog post on
by RobAtticus 9y ago
We are working on benchmarks comparing ourselves to other solutions so hopefully we'll have concrete numbers on those soon. (Incidentally, we did a blog post on us vs plain PostgreSQL today: https://blog.timescale.com/timescaledb-vs-6a696248104e https://blog.timescale.com/timescaledb-vs-6a696248104e)
At a high level though, we do find that having native support for full SQL to be a big win. Also, if you already store metadata or other relational data that you want to combine with your time-series data, it's great to be able to use one DB instead of separate solutions. Performance wise we do believe we are competitive and in some cases much better, and we have the 20 years of stability from PostgreSQL to build on.
- jnordwick 9y agoI look forward to a KDB comparison. Please dont forget them.
- trevman 9y agoMe too. At first blush KDB is orders of magnitude faster, especially if using a GZIP card. But Timescale is open source and not core locked. ¯\_(ツ)_/¯
- continuations 9y ago> At first blush KDB is orders of magnitude faster Are there actual benchmarks that show KDB being orders of magnitude faster than Timescale? How many orders of magnitude are we talking about?