Live data from Hacker News

Google Cloud Spanner is now half the cost of Amazon DynamoDB

cloud.google.com

211–220 of 371 posts

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#211

Just moved our infra from GCP to AWS. Kubernetes clusters, LB, storage, lambdas, KMS and all of it. Google runs their tech stack as if it's a startup that builds their CV. Everything is immature, tons of hacks, undocumented features. If you are on their k8s there are tons of upcoming new versions and features that force you to revisit key hacks you put in your infra because of their misgivings. Our infra team keeps t…

> AWS support is so nice, you can't believe it. This! They even custom-coded their support portal better than those off-the-shelf vendor like Zendesk. I say this as a Zendesk paying customer. GCP on the other hand, is a F-tier in support. Almost feel like I need to beg them to get any level of help.

A GCP issue was the only time I had a human contact with Google, they did well. However high scale low touch is in their DNA and you can tell it.

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#212
post #157

Earlier quoted context omitted.

From the AWS blog post they referenced- > DynamoDB powers multiple high-traffic Amazon properties and systems including Alexa, the Amazon.com sites, and all Amazon fulfillment centers. Over the course of Prime Day, these sources made trillions of calls to the DynamoDB API. DynamoDB maintained high availability while delivering single-digit millisecond responses and peaking at 126 million requests per second. Amazon w…

Just as a hand in the air...Be careful about what you're comparing here. # of API calls over a period of time is...largely irrelevant in the face of QPS. I can happily write a DDOS script that massively bombards a service, but if that halts my QPS then it doesn't matter. So sure, trillions of API calls were made (still impressive in the scope of the overall network of services, I'm not downplaying that), but ultimate…

Google calls API calls “queries”… because of their history as a search engine. QPS == API calls/per second == Requests per second

That said, I can’t imagine these numbers mean much to anyone after a certain point. It’s not like either company is running a single service handling them. The scale is limited by their budget and access to servers because my traffic shouldn’t impact yours. I feel like the better number is RPS/QPS per table or per logical database or whatever.

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#213
post #8
post #2

Google also has a history of massively spiking the cost of its services. Vendor lockin is a dangerous thing.

This definitely happened with Google Maps, where Google was clearly the dominant player. Has it happened to other services? It seems far less likely to happen for business cloud services where they are a distance 2nd (3rd?) to AWS. I know of some examples (admittedly ancient) where they have reduced costs: https://cloudplatform.googleblog.com/2015/05/Pay-Less-Comput...

The last year has had multiple GCP cost increases:

https://cloud.google.com/storage/pricing-announce

https://cloud.google.com/blog/products/infrastructure/update...

https://cloud.google.com/blog/products/data-analytics/introd...

https://cloud.google.com/compute/pricing-announce

https://cloud.google.com/vpc/pricing-announce

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#214

Earlier quoted context omitted.

We shared some details about Gmail's migration to Spanner in this year's developer keynote at Google Cloud Next [0] - to my knowledge, the first time that story has been publicly talked about. [0] https://www.youtube.com/watch?v=268jdNwH6AM

I tried to find it in this video, but failed. Could you please share a time stamp on where to look? It’s a pretty big deal if Gmail migrated to GCP-provided Spanner(not to an internal Spanner instance) and sounds like he kind of vote of confidence GCP and Cloud Spanner could benefit from: might I suggest to write about it? It’s easier to digest and harder to miss than an hour-long keynote video with no time stamps. A…

In the timestamped video link shared downthread, the speaker does seem to strongly imply that gWorkspace doesn’t manage the infra, when he finishes explaining the migration he declares (around 55:18)“[…]we can focus on the business of gmail and spanner can choose to improve and deliver performance gains automagically[sic]” which would imply, to me at least, that it’s on GCP.

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#215
post #174
post #157

Earlier quoted context omitted.

From the AWS blog post they referenced- > DynamoDB powers multiple high-traffic Amazon properties and systems including Alexa, the Amazon.com sites, and all Amazon fulfillment centers. Over the course of Prime Day, these sources made trillions of calls to the DynamoDB API. DynamoDB maintained high availability while delivering single-digit millisecond responses and peaking at 126 million requests per second. Amazon w…

I used DynamoDB as part of the job a few years ago and never got single-millisecond responses - it was 20ms minimum and 70+ on a cold-start, but I can accept that optimising Dynamo's various indexes is a largely opaque process. We had to add on hacks like setting the request timeout to 5ms and keeping the cluster warm by submitting a no-op query every 500ms to keep it even remotely stable. We couldn't even use DAX be…

> We had to add on hacks like setting the request timeout to 5ms and keeping the cluster warm by submitting a no-op query every 500ms to keep it even remotely stable.

This sounds like you're blaming dynamo for you/your stack's inability to handle connections / connection pooling.

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#216

But a droplet with a Postgres db is nearly free, and seriously performant. And for 65/month, you can get a VERY beefy Hetzner server. You’ll have to wade through the crazy thicket that is the menu of cloud offerings. I gave that one look, and decided I might as well give up and learn the basics of Linux admin once and apply it for life.

Or you could use DynamoDB for basically free. One month of 1GB of storage, 1kb item size, 100,000 writes, and 100,000 reads, would be $0.39 on DynamoDB on-demand. A million writes and reads respectively would be $1.63. Strongly consistent reads'd make that $1.75, and transactional writes would make it $3.00

I get it but I feel like it isn't really mine, and learning this new db/console/product/vendor that won't be around in 10-20-30 years is a waste of very limited time.

Linux admin + hosting a server = my data, on my terms, until I keel over, and possibly long after that.

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#217
post #122

Earlier quoted context omitted.

> For everybody with databases that are not that huge PostgreSQL will do just fine. Ha. Remember Gary Bernhardt of WAT fame? https://twitter.com/garybernhardt/status/600783770925420546 > Consulting service: you bring your big data problems to me, I say "your data set fits in RAM", you pay me $10,000 for saving you $500,000.

AWS will happily rent you a server with 24 TB of memory for about $200/hour. Columnar databases typically get a 10:1 compression ratio over raw data = 240 TB effectively. That’s a lot of data.

Which columnar databases are doing the above in-memory?

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#218

Earlier quoted context omitted.

yeah but you run into other issues when you put all of your lambdas on the same VPC

Not to be that guy, but why lambdas? I'm genuinely curious. I've never found the "cost savings" (big air quotes) worth it in comparison to the increased configuration/permissions complexity. Especially when Fargate exists, where you can just throw a docker container at AWS, what do Lambdas add? The zero scaling?

Why not? The setup I’m experimenting with for an API right now is basically a single Lambda that’s accessible through a function URL (so no ELB/ALB) + an RDS instance. Spinning up additional environments is a single Cloudformation call and deployment artifacts should work with both Docker containers or S3 (depending on the Lambda execution environment).

Seems like a leaner setup than using ECS/Fargate + LBs to me. Have I overlooked something?

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#219

Just moved our infra from GCP to AWS. Kubernetes clusters, LB, storage, lambdas, KMS and all of it. Google runs their tech stack as if it's a startup that builds their CV. Everything is immature, tons of hacks, undocumented features. If you are on their k8s there are tons of upcoming new versions and features that force you to revisit key hacks you put in your infra because of their misgivings. Our infra team keeps t…

Support wise, GCP is a joke run by entitled people. I had an issue some time ago with a VPN and after doing a lot of troubleshooting and having them agree the problem is on their end (packets would go in their VPN Gateway from the VPC, nothing would come out), the solution was to update my configuration on my end to workaround whatever they did because "it is how is going to be"...

TL;DR: they broke something and wouldn't fix it.

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#220
post #148

Earlier quoted context omitted.

Except for projects for which NoSQL is a better fit than a RDBMS, no? If I'm writing a chat app with millions of messages and very little in the way of "relationships", should I use Postgres or some flavor of NoSQL? Honest question.

Golden Rule of data: Use PostgreSQL unless you have an extremely good reason not to. PostgreSQL is extremely good at append-mostly data, i.e like a chat log and has powerful partitioning features that allow you to keep said chat logs for quite some time (with some caveats) while keeping queries fast. Generally speaking though PostgreSQL has powerful features for pretty much every workload, hence the Golden Rule.

100% this, and even though I work for Google I absolutely agree. BUT, for the folks that need it, PostgreSQL just DOESN'T cut it, so it's why we have databases like DynamoDB, Spanner, etc. Arguing that we should "Just use PG" is kinda a moot point.
Post reply on HN