Because $75 or $150 for HA on oracle is not going to happen - period.
It's just interesting how the price points are so wildly divergent.
Using the price calculator linked in the article, on Azure the cheapest "Dev" tier (which I obviously wouldn't expect to have HA based on the name "Dev" alone) is $160/m - that's a lot for 1 vCPU and 4GB RAM. I want to give TimescaleDB money, but I just can't justify that.
The cheapest in the Basic tier on Azure is $715/m - yes, you can bet I expect HA at that price for 4 vCPUs and 16GB RAM.
I'm a big fan of TimescaleDB, but if they are competing with cloud provider's own managed solutions (which, AFAIK, all come with HA and PITR), it needs to ship with similar guarantees, and/or the pricing needs to be revised.
I don't know Azure but do know AWS. PITR restores are not in seconds but in hours and you lose data.
"... a user-initiated point-in-time-restore operation will be required. This operation can take several hours to complete, and any data updates that occurred after the latest restorable time (typically within the last five minutes) will not be available."
Failover with AWS is generally 1-4 minutes? Someone fill in the blanks here?
* The smallest multi-AZ with failover MSSQL you can get runs $1,503 on AWS.
* Undifferentiated Postgresql is pretty cheap - you should be able to get failover for about $110 or so there.
I'm just pointing out that commercial / differentiated product offerings (which is what this is), beyond just basic postgresql costing so LITTLE for HA would actually be somewhat unusual.
In enterprise sales these prices for HA are so low no one would even know how to contract for them. What happens is once you need this level of uptime you can afford it (in most cases).
Quick feedback my side - $150/month to try something and then $500/month in production is not unreasonable for I think a fair number of use cases. Making the "try it" pricing as cheap as possible, and feature limiting is a good thing I think so the onboarding step is easier.
Folks with money to spend are used to sometimes TERRIBLE support despite spending big money on big players. One thing these smaller places have, if you are giving them $10K/month - they usually answer the phone or email! A secret benefit.
You're talking about something different. I mean that if the node running Postgres goes down, your storage is simply connected to a new node (all this behind the scenes, of course).
> Quick feedback my side - $150/month to try something and then $500/month in production is not unreasonable for I think a fair number of use cases
$150/m just to play is way too much - IMO, $50/m would be much more reasonable. I also believe that $500/m for a tiny, single instance without HA is too much.
And getting a true technical resource on the phone at AWS requires an enterprise support contract, which starts at an additional $15,000 / month.
Azure Postgres and AWS RDS do _not_ include HA replication in their base price -- you need to pay extra for actual replicas. What they do provide is the fact that they use decoupled storage to automatically recreate the database in the case of failure (which we do as well).
But that's not the same thing as ~zero downtime from migrating to a synchronous replica, which you can also use for scaling read queries.
My point is that TimescaleDB's pricing is high enough that I'd expect replication to be provided, or at least some other kind of HA guarantee.
Moreover, your actual costs from the cloud vendors is often tricky and muddled, given they have some many different ways to charge you. For managed databases, this often includes things like some backup storage costs, bandwidth costs for ingress/egress, etc. All of that is "included" in our flat pricing.
But the biggest thing: Timescale Cloud is not offering an undifferentiated Postgres offering. It's the only place to get the best version of TimescaleDB.
And in many cases, this will /save/ you money. For example, TimescaleDB's native compression typically gets 94% bandwidth reduction. So the 500GB on Timescale Cloud is equivalent to paying for 8TB on Azure or AWS. And without all the other TimescaleDB features, including performance improvements of executing queries against compressed data.
You also get really useful features like continuous aggregates, data retention policies, interpolation, etc.
So the comparison isn't really 1-to-1. Depending on your workload, you could easily get better performance out of 1 vCPU on Timescale Cloud than 4 vCPU on any vanilla Postgres service (not to mention the 95% cost savings on storage).
(I work at Timescale.)
I think it makes no sense to compare your managed offering to vanilla Postgres though - surely the comparison is vs TimescaleDB hosted in other ways.
In theory I can use TimescaleDB on cloud managed DBs already (if providers didn't offer such old versions of TimescaleDB).
Given your offering deploys to cloud VMs, perhaps the best comparison is vs deploying Postgres with TimescaleDB yourself on cloud VMs. And at a glance, it looks like your Basic tier is 300-400% more than the cloud VM - so what's the value-add? You get PITR, but beyond that?
Other cloud providers can only offer the Apache-2 version of TimescaleDB. So you wouldn't get native compression, continuous aggregates, downsampling, etc.
So again, the value add in Timescale Cloud are those features (all of which took a long time to build!). Also: we fully manage the database, are responsible for keeping it online, are available for support via email and Slack, etc.
The only real alternative to Timescale Cloud is to run it yourself, where you get the features but not the services/support. But you are welcome to do that if you'd like :-).
Ah yes - I was forgetting that!
> So again, the value add in Timescale Cloud are those features
Hmm, not really; those are the value-add from TimescaleDB itself, not Timescale Cloud.
I guess I'm going to remain unconvinced for now, but I really hope that, with time, the Timescale Cloud team works on adding more value vs self-hosting, as personally I don't think it brings enough value to justify the pricing as-is.
(And as you can see, we are continuing to invest in our self-hosted community [0])
[0] https://blog.timescale.com/blog/multi-node-petabyte-scale-ti...
Btw - always happy to chat directly if you'd like. Feel free to reach out! ajay (at) timescale.com