Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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

tl;dr: 20x higher inserts at scale, faster queries, 2000x faster deletes, more time-oriented analytical features



And actually, if you want to run the benchmarks yourself:

https://github.com/timescale/benchmark-postgres


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


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.


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 :)


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


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: