> $272 monthly + GPU cost<p>Imagine paying $250+/mo for 32GB of RAM and 4 VCPUs. No wonder Amazon is swimming in cash, the markup on this is bonkers.
100% this, i've been finding metal is getting very compelling against aws. For example latitude has 4 real cores and 32 GB of ram for $92/month.<p><a href="https://www.latitude.sh/pricing/c2-small-x86?gen=gen-2" rel="nofollow">https://www.latitude.sh/pricing/c2-small-x86?gen=gen-2</a><p>hetzner doesn't even have specs this low from what i can tell!<p><a href="https://www.hetzner.com/dedicated-rootserver/#cores_threads_to=6%2B12&ram_to=64" rel="nofollow">https://www.hetzner.com/dedicated-rootserver/#cores_threads_...</a>
It has a VM with 32GB RAM and 4x the cores for 1/10th of the price: 25eur/mo. Effectively even lower because it has 20TB of included traffic, and the overage cost for it is ~1/10th of the AWS egress cost.<p>Or, for 184eur/mo you can get one of their bare metal GPU offerings with 64GB of RAM, a i5-13500 and an RTX4000.
+ 3.75 TB NVMe<p>And that’s the per second pricing applied 24/7 for a month. A year commitment takes 30% off.<p>Still a big markup, but a lot of these comparisons are the the on demand instant on/off price.
Too bad aws does not support any of these other vector extensions in managed rds.
That suffer from a serious issue<p>You must have the data upfront, you cannot build this in an incremental fashion<p>There is also bo mention on how this would handle updates, and from the description, even if updates are possible, this will degrade over time, requiring new indexing batch
How does it compare with paradedb and lancedb?
Kinda makes you wonder why you need cloud for anything besides remote encrypted backups if you can run all that on 12GB
You don't, but business executives aren't the kind to easily admit they got conned - and if they're getting close to that stage, a nice dinner or golfing session paid by the vendor's representative generally alleviates those feelings very well.<p>Engineers who started their career during the cloud craze and don't know anything else are also not the kind to rock the boat, lest the cash cow dies and their whole "investment" in their career becomes useless.
what about failover story if server dies? PG failover setup is complicated, and cloud infra handles this for you.
(Genuine question) What's your current plan for when your cloud provider goes offline? Do you have a failover story, or it a case of "wait for them to come back online"?
I have backups on different cloud provider, so I could bootstrap db if provider goes dark indefinitely.<p>But realistically, I believe major clouds (google, aws) likely has more robust org and infra for recovery than I can built and maintain.
Do we mean managed or PG on K8s like CNPG? In all cases, I use the infra to simplify things like having disk redundancy and failover nodes, not because 12GB is interesting.
What are you willing to pay for cloud-native failover?<p>Not every use case requires 100% uptime
<a href="https://github.com/multigres/multigres" rel="nofollow">https://github.com/multigres/multigres</a> ... when its complete. From the guy that made Vitess for Mysql.<p>And yes, i agree, the PG failover setup (and especially dealing with a failure afterwards, to restore the ex-master is beyond infuriating).<p>But its not pay 10x the amount, while eating easily 10x performance infuriating :)
Because getting any hardware out of infra-team on premise is utterly miserable, across the board.