6 ms·
In my opinion it would be very hard to justify using Timestream for any analysis heavy workloads for at least three reasons: 1. Queries will need to touch a lo
by atanasovskib 6y ago
In my opinion it would be very hard to justify using Timestream for any analysis heavy workloads for at least three reasons:
1. Queries will need to touch a lot of data - will cost a lot, and there is no ability to optimize the queries in any way (no EXPLAIN, no indexes, no downsampling)
2. No integration with data exploration and visualization tools
3. No ability to have non-timeseries data, or correlate any data in two different tables (no JOINs)
(Disclaimer: I work at TimescaleDB)
- jpgvm 6y agoI completely agree I think you misunderstood me. I would like to see comparisons between Timescale and Druid. I already know Timestream isn't up to the task lol.
- valyala 6y agoWhat about comparing TimescaleDB to VictoriaMetrics? There are some old benchmarks [1], but it would be great to see updated benchmarks as well for the latest TimescaleDB and VictoriaMetrics versions. [1] https://valyala.medium.com/measuring-vertical-scalability-for-time-series-databases-in-google-cloud-92550d78d8ae https://valyala.medium.com/measuring-vertical-scalability-fo...
- siliconmountain 6y agoWhat kind of auth & logging does TimescaleDB offer? Is every request authenticated & authorized?
- mfreed 6y agoTimescaleDB inherits from Postgres a rich role-based access control, so all requests require permissions and roles can be enforced at various levels (database, schema, table, or even rows) and privileges (SELECT, INSERT, DELETE, CREATE, etc). Authentication to the database is typically governed to different security mechanisms, including certificate-based auth, password via SSL, etc.