11–20 of 73 posts
Wouldn't this introduce additional latency among other issues?
Really excited for more people to get to use Metal. Let me know if you have any questions.
I'm stoked about this release too... From what I can tell, the 'Metal' offering runs on nodes with directly attached NVMe rather than network-attached storage. That means there isn't a per-customer IOPS cap – they actually market it as 'unlimited I/O' because you hit CPU before saturating the disk. The new $50 M-class clusters are essentially smaller versions of those nodes with adjustable CPU and RAM in AWS and GCP…
Just want to add that you don't necessarily need to invest in fancy disk-usage monitoring as we always display it in the app and we start emailing database owners at 60% full to make sure no one misses it.
Earlier quoted context omitted.
Why is Metal not offered for single instance deploys? Our app does not need this kind of uptime. We would be happy with a node going down once in a while (no data loss, of course) with a little bit of downtime to save 66% on the cost of running 2 additional nodes that will never see action.
It's a durability thing, we need to make sure writes are replicated off to at least one node. There might be avenues to get Metal down to single node in the future.
Even to take a case in point where durability is irrelevant - people building caches in Postgres (so as to only have one datastore / not need Redis as well). Not a big deal if the cache blows up - just force everyone to login again. Would love to see the vendor reduce complexity on their end and pass through the savings to the customer.
edit: per your other reply re. using replication to handle resizing, maybe being upfront with customers about additional latency / downtime being necessary with single-node discounts, then for resizing you could break connections, take a backup, then restore the backup on a resized node?
Perhaps a naive question — but why would someone use a dedicated database provider and connect from another cloud provider's application service? ...as opposed to using the same provider's db + app service offering? Wouldn't this introduce additional latency among other issues?
Sounds amazing, but i would rather be able to run the database locally and use the same in dev as in production. Is this possible?
Perhaps a naive question — but why would someone use a dedicated database provider and connect from another cloud provider's application service? ...as opposed to using the same provider's db + app service offering? Wouldn't this introduce additional latency among other issues?