5 ms·

It seems disingenuous to call it the first. AWS has it's own time series db. In terms of open source Apache druid had a managed cloud variant that imply.io runs

It seems disingenuous to call it the first. AWS has it's own time series db. In terms of open source Apache druid had a managed cloud variant that imply.io runs.

akulkarni 7y ago
It’s the first multi-cloud. AWS obviously just AWS. Based on Imply Cloud website it looks like it too is just AWS. Timescale Cloud gives you freedom to choose your own cloud provider, and lets you migrate between clouds with a few clicks. I’m fairly certain we are the first to offer that, but I’m open to any counter examples.
- fitzoh 7y ago
  Also, Amazon Timestream isn't usable yet, it's still in private preview.
- SteveBash 7y ago
  Q: Regarding multi-cloud. Say if AWS has an outage will Timescale cloud fallback to use GCP or Azure? Can something like this be provided? Not sure if the network latency between different cloud providers would allow doing a multi-master replication scheme.
  - ddorian43 7y ago
    Can be done with an async-replication db like ScyllaDB. Or even CP db (just harder/slower).
    - dianasaur323 7y ago
      Yeah! CockroachDB is also a really cool multi-cloud DB. That being said, they are really more for transactional workloads, and less purpose built for time-series. I guess there are always trade-offs in the software world.
  - dianasaur323 7y ago
    You select the public cloud vendor you want your machine spun up on. So no, if AWS has a full outage, it won't fall back to a different cloud. Failover is done at an availability zone level. Since TimescaleDB is also open-source, if you want that kind of replication scheme, you can always install on VMs across clouds. However, as you rightly pointed out, network latency is a definite concern and impacts the feasibility of RPO and RTO.
    - mfreed 7y ago
      One thing to add: The Timescale Cloud does allow you to do is create asynchronous read replicas across different clouds and regions (with a couple clicks). You can then "fork" a read replica (at any point in time) and make it a primary to start serving out of that cloud (again, with just a couple clicks). That's not quite the same as auto-replication/failover between clouds, but getting pretty far there.

It seems disingenuous to call it the first. AWS has it's own time series db. In terms of open source Apache druid had a managed cloud variant that imply.io runs.

akulkarni 7y ago

It’s the first multi-cloud. AWS obviously just AWS. Based on Imply Cloud website it looks like it too is just AWS. Timescale Cloud gives you freedom to choose your own cloud provider, and lets you migrate between clouds with a few clicks. I’m fairly certain we are the first to offer that, but I’m open to any counter examples.

fitzoh 7y ago
Also, Amazon Timestream isn't usable yet, it's still in private preview.
SteveBash 7y ago
Q: Regarding multi-cloud. Say if AWS has an outage will Timescale cloud fallback to use GCP or Azure? Can something like this be provided? Not sure if the network latency between different cloud providers would allow doing a multi-master replication scheme.
- ddorian43 7y ago
  Can be done with an async-replication db like ScyllaDB. Or even CP db (just harder/slower).
  - dianasaur323 7y ago
    Yeah! CockroachDB is also a really cool multi-cloud DB. That being said, they are really more for transactional workloads, and less purpose built for time-series. I guess there are always trade-offs in the software world.
- dianasaur323 7y ago
  You select the public cloud vendor you want your machine spun up on. So no, if AWS has a full outage, it won't fall back to a different cloud. Failover is done at an availability zone level. Since TimescaleDB is also open-source, if you want that kind of replication scheme, you can always install on VMs across clouds. However, as you rightly pointed out, network latency is a definite concern and impacts the feasibility of RPO and RTO.
  - mfreed 7y ago
    One thing to add: The Timescale Cloud does allow you to do is create asynchronous read replicas across different clouds and regions (with a couple clicks). You can then "fork" a read replica (at any point in time) and make it a primary to start serving out of that cloud (again, with just a couple clicks). That's not quite the same as auto-replication/failover between clouds, but getting pretty far there.