3 ms·
tl;dr TimescaleDB is a does batching + partitioning better than postgres (including postgres 10) can, automatically, and turns postgres into a grade A time seri
by hardwaresofton 9y ago
tl;dr TimescaleDB is a does batching + partitioning better than postgres (including postgres 10) can, automatically, and turns postgres into a grade A time series database. I'd love to know how TimescaleDB plans to monetize.
That said, I actualy did read the article, and it was excellent. I was a little put off by the "IoT" (buzzword fatigue) and like 2% over-editorializing (to set the stage for timescaledb) but it makes sense given that the poster is the CTO, with a company to promote, and the fact that the people who might read the article are varied.
Inside the article is a link to a post on why PG10 doesn't quite stack up[0], which was also a great read -- the naive engineer in me immediately asked myself that since PG10 offered improved partitioning why I would need TimescaleDB if I had PG10. Obviously PG10 doesn't offer the chunking, and it doesn't offer automation of the partitions that TimescaleDB does, and it degrades under number of partitions (which is bound to grow with time series data of course).
[EDIT] - Ignore the sentence immediately below this edit - write performance is the graphed metric in the article. Sentence left in for posterity. Turns out PG10 writes degrade horribly as partition size increases.
They did not graph write speed in the article though, which was a bit disappointing, so I assume the difference was negligible (in the end, you are writing with postgres to multiple chunks/partitions, no matter how efficiently/automatically they were created, so it's probably the same).
I've been itching to use TimescaleDB for a while, really glad to see it get exposure like this -- I'm just about ready to go all in on it, I already love Postgres and TimescaleDB means now I can do more awesome things with Postgres.
I'd like to hear the profit model of the company though -- how does TimescaleDB plan to make money?
[0]: https://blog.timescale.com/time-series-data-postgresql-10-vs-timescaledb-816ee808bac5 https://blog.timescale.com/time-series-data-postgresql-10-vs...
- RobAtticus 9y ago>They did not graph write speed in the article though, which was a bit disappointing, so I assume the difference was negligible Did you mean query performance? There are write speed/insert numbers under "Insert performance measurement graphs"
- hardwaresofton 9y agoOh sorry, I somehow focused in on the number of partitions bit and somehow missed that the metric was actually insert performance. I'm surprised PG10 tanked so fast...
- anarazel 9y agoThe partition selection / pruning in 10 was not yet improved from older inheritance based "partitioning" (COPY might already have been optimized back then, not sure right now). It's looking different in v11.
- hardwaresofton 9y agoAhhh I thought the partitioning was NOT inheritance based by default after reading the partition documentation page in the PG docs[0]. More specifically the "Implementation using inheritance" section[1] -- I thought the default was NOT to use table inheritance, but that you could use it as an option. [0]: https://www.postgresql.org/docs/current/static/ddl-partitioning.html https://www.postgresql.org/docs/current/static/ddl-partition... [1]: https://www.postgresql.org/docs/current/static/ddl-partitioning.html#DDL-PARTITIONING-IMPLEMENTATION-INHERITANCE https://www.postgresql.org/docs/current/static/ddl-partition...
- anarazel 9y agoYou misunderstood me, sorry I should have been clearer. Some internals are shared between inheritance and declarative partitioning. For v10 most parts of the system (except for COPY) used the same partition exclusion logic for both forms of partitioning. Which means it was O(partitions) with a pretty high constant.