GabeWeiss_

Yah, I know. The Cloud version has a lot of stuff happening behind the scenes that makes it a bit trickier to have a smaller machine configuration. It's being worked on, but I can't speak to timelines/configurations.

I realize this may sound hollow coming from a Google employee...but I am fighting to be sure something like this stops happening (in particular the deprecating causing loss of functionality). Google is (a little) better than it has been in the past. E.g. the opening of the protocols on the Stadia controllers when Stadia was shut down so their controllers could work on other platforms.

I am pushing at the OSS angle, but new product, so uphill battle. :)

OMG no, we didn't reimplement Postgres. Definitely started from the PG kernel and made modifications from there.

You're looking at Cloud AlloyDB sounds like? If you deploy AlloyDB to GCE (instead of locally, etc) you can provision a smaller instance than that. 2cpu(shared core)/4GB memory with a 20GB boot disk (AlloyDB takes up ~13) would run you $26/month before network/storage costs.

100% hear you. I realize this may sound hollow coming from a Google employee, but stay tuned on specifics around licensing and costs. Being a tech preview, there's been virtually no discussion on specifics yet. We just wanted to get the tech in folks' hands. We're pushing hard for a free tier of usage (and the product team isn't pushing back currently).

I have many thoughts here...but let's start with: Do you have your process of how you tested performance? My guess is the eng team would love to look at what you tested.

That's how I've been thinking/talking about it. It should be a drop-in replacement for Postgres. Obviously the install process isn't as smooth yet, but, technical preview...

Not as of yet, no. I've gently nudged the eng/product teams in this direction, but for now it's all being kept in-house.

Definitely not an emulator. It's fully AlloyDB...in a container. We'll be working moving forward to smooth out the install process (tech preview, focus was on getting it in y'alls hands). In my mind, it's a proper Postgres drop-in replacement (Yes, of course I'm biased because I work at Google) but the tech is legit.

Not sure what you mean here. The Spanner trial is a completely separate thing from the $300 starting credits. So if you use the Spanner free trial, you aren't spending any part of the $300 credits during that trial period. You can also start the free Spanner trial regardless if you've spent the $300 starting credits in the past.

TIL! Thank you, email sent.

Spanner does have an emulator that you can use locally with the gcloud SDK: https://cloud.google.com/spanner/docs/emulator

No extensions, no. Think of the interface more like a way for accessing Spanner features using Postgres, rather than using Postgres with a Spanner backend.

Correct, we (Google) didn't make the post, so unfortunately we don't have access to changing the title. Just have to hope folks read the comments.

Neither, it's just not quite what folks expect. The postgres/spanner interface is about accessing SPANNER functionality via a PG interface. It's not about using Postgres with a Spanner back-end. That's all.

Yeah, we (Googler here) know, but it's not our post, so we can't edit it. :D Best we can do is hope people read the comments (weird thing to say on the internet).

This isn't true at all. Where are you getting your numbers from?

Yup, correct. The title here isn't right. It's a free trial, not a free tier.

Yah, the title's not 100% right. :) There isn't a free TIER of Spanner. This is a 90 day free trial.

It's like, faster Postgres that also handles a lot of boilerplate infrastructure set up like creating replicas, load balancing, vacuum management, etc. That's a SERIOUS TL;DR though. This blog post covers a good overview and some details:

https://cloud.google.com/blog/products/databases/introducing...

Not anything I can talk about now unfortunately. Stay tuned though. :)

The 2x was based on an Online Transaction Processing (OLTP) benchmark that is based on industry standard TPC-C benchmark in our own testing.

Thanks! We feel pretty strongly that managed OSS is hugely valuable.

Similar in that they're both managed relational databases aimed at scaling for intense workloads. AlloyDB has specific optimizations around PG that means it runs more efficiently than Aurora for Postgres.

They aren't related at all.

Landing page on the Google Cloud docs pages:

https://cloud.google.com/blog/products/databases/introducing...

No no, you misunderstand me. I'm not saying it's FOR human safety...it's for profit. But the pushback on "losing jobs to machines" is less when the end-result is replacing human jobs that have a high degree of danger associated with them. Which is why, throughout history as well, we've seen larger adoption of automation via machines in those areas. The friction to do that replacement is lower, so we see it more often.

Also of note, the societal backlash of replacing humans with robots has been pretty massive. So it's not just cost-effectiveness that's being balanced, but care with the workforce not to implement too many replacements too fast. The places where we've seen massive substitution are all industries where humans were in physical danger from the work being done. Risky manufacturing lines, etc.

I feel like that's starting to shift a bit where folks are realizing that more automation by robotics isn't actually reducing the potential workforce, it's just shifting it. Again though, it's up to the employers and manufacturing companies to really drive that point home.

It's an exciting time. :)

As it not only says in the original article, but also in many of the comments, you can't just do that because the abuser knows if you've superseded their control, and abuse can escalate into physical if that action is taken.

It's not simple.

Victim shaming isn't acceptable. Sorry. You're blaming the person being abused for not leaving. There's a MULTITUDE of reasons (as other comments have already stated) that people aren't enabled to get out of an abusive relationship.