TimescaleDB vs. Amazon Timestream

Re:TimescaleDB vs. Amazon Timestream by that_guy_iain on Thursday December 03, 2020 @07:39AM (#25288258)

It seems like AWS is just focusing on increasing it's vendor lock in and it makes sense not just from the AWS point of view but if you're a developer at an enterprise company that has authorised AWS the more databases the clone, poorly or badly the more choice you have without having to get authorisation and the cost doesn't matter to the developer since the enterprise company is paying for it.

I suspect there are many enterprises that are already so locked into AWS that it would take them a decade to move to a different provider.

[ Parent | on HN ]

Re:TimescaleDB vs. Amazon Timestream by frankietaylr on Thursday December 03, 2020 @07:45AM (#25288298)

I don't have much expertise with Timestream. Can't comment on it. But, there is nothing wrong in trying for an alternate implementation. We're using Kinesis and it is a good fit in our stack with lot less overhead. They did bring Kakfa (Amazon MSK) later to the AWS service list. Its upto the consumer to pick Kinesis or MSK.

One example which was influential in nature - Dyanmodb. The Dyanmodb paper inspired a number of NoSQL databases, including Apache Cassandra. If they have went with the popular NoSQL database at that time, we might have missed some good contribution.

[ Parent | on HN ]

Re:TimescaleDB vs. Amazon Timestream by Aeolun on Thursday December 03, 2020 @07:59AM (#25288388)

But you can just run timescaleDB inside your amazon VPC. No need to use their services at all.

[ Parent | on HN ]

Re:TimescaleDB vs. Amazon Timestream by that_guy_iain on Thursday December 03, 2020 @09:08AM (#25288919)

You can but then you need to spend time setting up and maintaining the service. Which many enterprises aren't willing to do. Also, while you may be authorised to use AWS tech you may not be automatically authorised to use different tech. We literally were told to use MySQL instead of MongoDB soley because RDS was allowed and all services had to be managed by AWS.

I am not complaining AWS is doing vendor lock in makes complete sense, I am just commenting that is their main direction for their offering. And their vendor lock is aimed at the enterprises where they can really run wild on it and get lots of money in return. Smaller orginisations will generally never lock themselves in so much because they won't build so many things that are so hard coupled since they just don't have the manpower.

[ Parent | on HN ]

Re:TimescaleDB vs. Amazon Timestream by mfreed on Thursday December 03, 2020 @08:26AM (#25288565)

And we in fact have fully open-source/free k8s helm charts to easily spin up TimescaleDB, including with HA and automated failure detection/failover and streaming replication for incremental backups:

https://github.com/timescale/timescaledb-kubernetes

Or just use Timescale's managed cloud on AWS:

https://www.timescale.com/timescale-signup

[ Parent | on HN ]

Re:TimescaleDB vs. Amazon Timestream by tracker1 on Thursday December 03, 2020 @09:22AM (#25289045)

Much like Amazon themselves with breaking away from using Oracle.

[ Parent | on HN ]