4 ms·

In a funny bit of coincidence -- we didn't post this link to HN :) -- we just published a blog post today comparing Timescale vs. native Postgres: https://blog

by mfreed 9y ago

In a funny bit of coincidence -- we didn't post this link to HN :) -- we just published a blog post today comparing Timescale vs. native Postgres: https://blog.timescale.com/timescaledb-vs-6a696248104e https://blog.timescale.com/timescaledb-vs-6a696248104e tl;dr: 20x higher inserts at scale, faster queries, 2000x faster deletes, more time-oriented analytical features

mfreed 9y ago
And actually, if you want to run the benchmarks yourself: https://github.com/timescale/benchmark-postgres https://github.com/timescale/benchmark-postgres
qaq 9y ago
Ok and if one is partitioning by date and dropping partitions instead of deletes in vanilla postgres how does it compare ?
- mfreed 9y ago
  The delete performance will probably be similar, but standard partitions in postgres have a bunch of current limitations. For example, the insert pipeline is still quite a bit slower, partition creation is still manual, can't do as good constraint exclusion at query time, can't do certain query optimizations we've built in, can't support user-defined triggers, can't handle UPSERTs, doesn't support various constraints, can't do VACUUMing across the hierarchy, etc. We plan to write a blog post comparing against PG10 partitioning in the future to expand on this a bit. All this said, we do love Postgres and realize that it's trying to provide a more general-purpose solution, so don't mean this as criticism. We can just build something more targeted at the time-series problem.
  - qaq 9y ago
    Thank you for the explanation looks like you have dedicated a good bit of effort to making a good ts solution, will be testing it out :)
mamcx 9y ago
This would be good for a eventsourcing storage? Fast events insert and fast reads?
- mfreed 9y ago
  Yep, it can be used for either "irregular" events or "regular" time-series like monitoring data. For event sourcing, just make sure you index on the proper user/session/thing (Docs or Slack for more info).

by mfreed 9y ago

mfreed 9y ago

And actually, if you want to run the benchmarks yourself: https://github.com/timescale/benchmark-postgres https://github.com/timescale/benchmark-postgres

qaq 9y ago

Ok and if one is partitioning by date and dropping partitions instead of deletes in vanilla postgres how does it compare ?

mfreed 9y ago
The delete performance will probably be similar, but standard partitions in postgres have a bunch of current limitations. For example, the insert pipeline is still quite a bit slower, partition creation is still manual, can't do as good constraint exclusion at query time, can't do certain query optimizations we've built in, can't support user-defined triggers, can't handle UPSERTs, doesn't support various constraints, can't do VACUUMing across the hierarchy, etc. We plan to write a blog post comparing against PG10 partitioning in the future to expand on this a bit. All this said, we do love Postgres and realize that it's trying to provide a more general-purpose solution, so don't mean this as criticism. We can just build something more targeted at the time-series problem.
- qaq 9y ago
  Thank you for the explanation looks like you have dedicated a good bit of effort to making a good ts solution, will be testing it out :)

mamcx 9y ago

This would be good for a eventsourcing storage? Fast events insert and fast reads?

mfreed 9y ago
Yep, it can be used for either "irregular" events or "regular" time-series like monitoring data. For event sourcing, just make sure you index on the proper user/session/thing (Docs or Slack for more info).