The company's irrevocably ingrained customer support culture will ensure they'll never be a serious AWS competitor, not with all the engineering and money in the world
This might be true, but AWS's support is not good. To get good AWS support for when their ELBs aren't working, or when half of your EBS volumes have multi-second IO latency, you need to pay for premium support, which is 10% of your bill.
Their customer support for GCP is top notch and they re-organized their entire support structure this year so each account has an account executive, SREs, etc. I've been very pleased the last year I've used GCP after migrating from AWS.
Before the reoganization I'd send in quota updates and they'd take 1-3 days. The last quota bump I did took 7 minutes.
All reports indicate that GCP is run very differently from the other products.
They had a rocky start as they were apparently ramping up the support organization, but these days I'm hearing nothing but praise.
They're getting very good at transparency. They have numerous mailing lists [1] ("Google Groups", ugh) for things like product release notes and planned changes. They just opened a public issue tracker [2] that covers the entire Google Cloud Platform.
If you're into Kubernetes/GKE, the Google team is also very active and responsive.
Try hosting a web site that serves Iranian people or a variety of other embargoed countries on GCP. You can't, nor will you find any hint of it documented anywhere, or any legal indication things must be this way.
At the simplest level when I buy compute time that looks like everybody else's compute time, I don't want to find after the fact that its provisioning is entangled in some weird corporate ideology that is now impacting my end users, left waiting to be discovered by the unsuspecting victim long after they've made plans around GCP.
(This is a true story from 2 months back, same shit used to happen with App Engine all the time)
That's because Google, as an American company, needs to ensure it doesn't violate certain trade embargoes, trade export law and other sanctions imposed on specific countries, like Iran.
Google restricts access to some of its business services in certain countries or regions, such as Crimea, Cuba, Iran, North Korea, Sudan, and Syria. If you try to sign in to these services from these countries or regions, the following error appears:
You appear to be signing in from a country where G Suite accounts are not supported.
Certain Google services, such as Gmail, might be available in these countries or regions for personal use, but not for business or education use.
Though some of the Google services are available for personal use in those countries, commercial use is restricted. A cloud would count as commercial use, even if it's only to host your own stuff.
GCP is far from the only cloud to suffer from it and many other services impose this too. The Docker Hub does it too for example.
A few months ago I would've agreed with you. After trying out GCP, interacting with support twice and speaking with a few other companies using the platform I've changed my tune.
100% agree. I actually just backed out of a GC implementation this week because their product simply didn't stack up at all compared to their competition. Google has a looong way to go in the cloud space and it starts with their support.
I've had overall pretty good experiences in my year on GCP, particularly recently. I posted a question in Slack and one of the engineers on the product PM'd me back within 15 mins to troubleshoot the problem.
If you have to raise a ticket it's a bit more variable, but on the whole I've had every issue resolved satisfactorily.
It's not actually mongodb. It's the DocumentDB nosql offering, which is very good, but just means that it takes the mongodb wire protocol and supports most operations. It is not the same thing.
This is exactly what I plan to do. Not really because of any specific issue with Docker, it's just that databases have very different lifecycles than your typical container.
Yes, it is wise to do that. If you don't want the overhead of running your own SQL instance, you definitely don't want the overhead of running it on kubernetes; it's quite tricky (but the addition of StatefulSets in 1.5 has made it easier).
"The Cloud SQL Proxy allows a user with the appropriate permissions to connect to a Second Generation Cloud SQL database without having to deal with IP whitelisting or SSL certificates manually."
I think what most people mean when they say that is "don't put the DB in Docker", so don't use Docker to host Postgres. Just because your app is hosted by Docker doesn't make it more or less wise to connect to a database. It just depends on if you need a database or not.
is this cloud sql for postgres autoscale auto replicate fully managed hands off like app-engine and datastore or does this need to be managed manually?
Sorry for hijacking, but is there an issue with Cloud SQL right now? I keep getting authentication issues from the GCP dashboard even though I've logged in with 2FA multiple times and when I try to visit my Cloud SQL instances, it just says failed to load.
This is definitely going to be very useful when it's fully fleshed out but be warned that this initial beta doesn't support Google-managed replication or HA (to say nothing of an SLA, of course).
The code is pretty much unmaintained at this point, it's a pain in the ass to build, besides the v4 UUID generation function everything else in there is useless, and the v4 UUID generation function is 6x slower than the one in pgcrypto[1].
There's no reason to use it and incorporating it into projects just creates headaches down the road.
I believe that type 5 (and I guess type 3) UUIDs both have legitimate use cases, especially when data migrations are involved. Both of these types are supported by uuid-ossp but not by pgcrypto.
Excited to see this, but holy shit is it unclear what expected costs could be. It seems like it might be on the cheap/affordable side of things, but it's not obvious. I almost prefer to just use Compose.io because at least the pricing is clear.
when ha would cost the same i.e. ~20€ than that would be amazingly cheap.
i mean on aws you would pay the same (20 €), but you need to pay 1 year upfront.. and if ha would be like 16 € you would only be a little bit more expensive than a 3 year aws rds offering (1€ per month), which is less a problem since the storage is cheaper and you are way more flexible (canceling and recreating to a bigger instance)
What's up with cloud instance naming schemes? I get this is kind of similar to Amazon, but man, I bet these are really unwieldy in conversations esp. if someone is new to a platform.
There's at least 2 performance dimensions for provisioning an instance: vCPUs and memory. Often also GPUs, local SSDs, local HDDs. And then you have multiple generations of hardware, which aren't 100% comparable to each other.
So coming up with a "fully systematic" naming scheme is not really possible without listing all the parameters, and then you lose the benefit of having a name.
We know. That's why PostgreSQL pilots hopefully clearer pricing structure where you choose how much CPU and RAM is needed and pay per CPU and GiB of ram. No more `db-nX-<something>-X`.
You'll still see instance size names for a while though. I think D0-D32 are for first generation of CloudSQL (which is MySQL only). db-* are for second generation and match GCE instance names.
Very exciting, but high availability, instance cloning, and read replicas are listed as "This functionality is not yet supported for PostgreSQL instances" in the docs. Seems like those need to be available before it's a realistic option for production workloads.
This was a tough call for the team: ship now for the folks that are okay with that, or wait until it's fully baked. They chose the former, which certainly means it's not a great idea for serious production load, but that's also true of it simply being in Beta. You won't see it go GA before it's really ready for production work (including replication, backups and so on) but I think it was a reasonable choice to get people started.
Disclosure: I work on Google Cloud (but not Cloud SQL).
It's a great idea. Customers can start using it today to host the databases for their dev and QA environments, which will help suss out any issues with it before GA.
I realize you can't commit to any particular dates, but is your feeling that this is .... single digit months away, or multiple digit months away, from being out of 'beta'?
Good question! Because of those important bits of functionality that will keep rolling in during the Beta, I'd say single digit months to the most important ones.
As a point of clarification though Beta => GA is about production hardening. Products can't go to GA without demonstrating that they've met their SLOs continuously for several weeks. Products can take longer than that if they feel they should make more tweaks first (and pgsql certainly qualifies), but we want to both ship quickly and get out of the reputation for perpetual Beta.
Regarding being beta, the flexible environment instances for App Engine are/were beta (I swear it was just a couple days ago, it was labelled beta, but not seeing it now). All the same, a lot of people are building towards that (ie Docker).
Seems like there is some confusion going on about the Free tier on a post[1]. Can you please comment there on whether the 'Always free' is free only during the first 12 months or forever?
Also, if I have been using Google Cloud since before today (when free trial was $300 over 60 days), am I still eligible for the 'Always free' tier?
From the page linked and the FAQ, it looks like it but many people on the thread I've linked are thinking otherwise.
Sorry, we've made updates to clarify. Yes, you can use during and beyond the free trial. Even though your free trial has expired, you can still use the Always Free products.
Another quick question. Is there anyway to see during instance creation/usage if it is part of the free tier?
When I create a f1-micro instance, it shows the usual $5/month billing, but doesn't indicate any kind of 'free tier' usage. How can we know if any service we use will be a part of the free tier for sure? I guess I can wait a few days to see if any costs accrue, but I was wondering if there was a better way for everyone.
Is there a way to see if the Cloud SQL team is planning to add more extensions? I'm mostly interested in citext myself but seeing that many people mentioned extensions, it would be nice to have some visibility in that.
More extensions is something we definitely plan to do.
No timeline, partially because we don't know ourselves. Our main priority for next few weeks will be ensuring everything is nice and stable. Once we are confident in current feature set we will start adding more.
You can watch https://cloud.google.com/sql/docs/postgres/release-notes for news.
As someone who interacts with PostgreSQL on-prem and cloud deployments frequently, I'm curious on the Hacker News community's thoughts on one question.
AWS has a fairly mature RDS Postgres offering. What would motivate you to use Google Cloud Postgres instead?
I've heard of four reasons from users: not on AWS, don't want to be locked into one vendor, cost, and better support. Do any of these reasons resonate with you or are there others?
As a Google customer (of both Compute/Container Engine and Cloud SQL), I'd rather use a Mysql instance hosted next to my application on Google's network than a Postgres instance that's an internet-hop away in Amazon's cloud. If I was currently running my apps on AWS that's where my DB would live too (and I'd be using RDS Posgres there).
The other reasons listed are an order of magnitude less important for my cost/benefit calculus (though things like cost and support will definitely matter to orgs bigger than mine).
What motivates me personally is not that I think Google Postgres will be better than RDS (which is great for us so far), but because I want to move to GCP for other reasons (pricing, better UI & cli, GKE, BigQuery) and the managed Postgres RDS was the only thing that was important enough to keep us on AWS
I just started using Google Postgres and, as of today, there is no way to easily get your PG data into BigQuery via any Google cloud service. You have to create your own CSV from your PG data, then upload that into BigQuery. I imagine (hope) this will change with additions to the Export options of PG instances.
There are lots of reasons to prefer Google, but ultimately there is one, single reason I want to switch:
The ability to cap costs.
With AWS, by the time you get a billing alarm, you could be thousands of dollars in the hole and there's nothing you can do about it. Avoiding that risk will help me sleep a little better.
I thought GCloud only had spending limits for App Engine services (including, apparently, Cloud Datastore even when used separately from App Engine), but not other services.
Thanks for alerting me to that possibility. If that's the case (can anyone confirm for sure?) then switching is probably not worth the switching costs for me right now.
I'd consider Google Cloud because the documentation, tutorials and verbose config (on most services) on AWS are a fairly substantial barrier. Has you ever gone through trying to wire up a Lambda function to talk to a S3 bucket and API getway endpoint? It's not fun. Even getting ElasticBeanstalk running with Docker isn't really easy.
I think Google Cloud is the middle ground between Heroku and AWS. It has potential to really gain traction with developers who want to get stuff shipped and not wear DevOps hats full time. What I'd like to see is Google adopting more modern software on their platform (Python 3) and trying to move things out of beta more quickly. You can't sell beta to management easily.
I'd say the Elastic Beanstalk with a single container is very easy... zip your project with a Dockerfile, and it will create the container...
However, man that Awsrunfile or whatever it is called, and the two versions that are incompatible with the different EB versions, and it's painful... the hosted container solution equally so.
GC's docs and tools just seem so much more straight forward (as do Azure's for that matter).
I'd consider Google Cloud because the documentation, tutorials and verbose config (on most services) on AWS are a fairly substantial barrier. Has you ever gone through trying to wire up a Lambda function to talk to a S3 bucket and API getway endpoint? It's not fun.
Strongly agree. I think that using an orchestration tool like Ansible or Cloud Formation is basically essential for AWS, because so many of the services have these interdependencies.
> Even getting ElasticBeanstalk running with Docker isn't really easy.
Yeah, we tried it. Not a great experience, and using an AWS proprietary container hosting system when everyone else is standardising on Kubernetes is not remotely attractive. I'm really looking forward to trying App Engine Flexible and GKE. If we can get really good application container hosting from GCP, then that will be a strong pull to migrating whole stacks.
I would love to see your own cloud offerings on Digital Ocean and on Google Cloud. Hopefully, with that said, we'll also see much more reasonable pricing as well!
I'm curious what you'd like to see in terms of pricing from Citus?
Yes, we do start at a higher end $990 a month, but we're very much focused on heavier workloads. Typically users come to us at 100 GB or more. If you're well below that we encourage you to stick with single node Postgres either RDS or Heroku Postgres. Once you get close to a $1k a month spend on those then we can start to make sense to consider.
Yes, you can absolutely get that much storage for that price. Though what your application needs in terms of memory/cores varies quite a bit on the application. We've seen customers that were spending $800 a month on RDS, migrate and get 2-3x performance boost for the same dollar spend.
Don't disagree at all that if you're at a lower volume of data that RDS is a great option for what you get. Depending on your application needs though as you scale and need more data in cache or more cores doing work, though this all depends on your workload. You can have 3 TB of cold storage and that work fine for your application and cost you under $1k a month on Aurora, or you could have needs with 100 GB of data that you need all queries served from cache in milliseconds. It's very unlikely you'll get that for $260 a month on RDS even at as little of 100 GB of data. It just depends on your application workload, for as long as you can you should just keep scaling up because it's much easier.
We very much focus on when you start to encounter that ceiling where scaling up starts to become prohibitive and performance is key not just storage–which can be as early as 100 GB, and is increasingly common the further you get beyond that.
If you need plv8, high availability or replication features today in Google Cloud, our Aiven PostgreSQL service may fit your needs, have a look at https://aiven.io/postgresql
They haven't really pulled the rug out for anything on Google Cloud (there've been a few things replaced, e.g., the old Master/Slave datastore on App Engine.)
And while this doesn't have an deprecation policy applicable as a Beta feature, most GA Google Cloud features have a one-year deprecation policy, so even if they were retired, no one would have the rug pulled out.)
You seem to be confusing Google Cloud Platform with Google services. AFAIK there have been no GCP features removed after they have gone into General Availability.
Bet hey, keep the uninformed meme going if you like.
I'm the Ruby Developer Advocate for GCP. I've used App Engine Flex with Rails 5 on a couple projects recently. Nothing huge but one is in production (it is for a local non-profit). I've found it to be a great way to get things out the door quickly and I love the auto-scaling.
It doesn't have all the magic of App Engine Standard and deploy times are slower than I'd like (~5 minutes). But I'm okay with that if I can use my own database, any library I want, and I have full portability.
The killer for me is PITR (point in time recover). A few years ago a colleague triggered and UPDATE without WHERE and PITR saved our sorry asses (on MS SQLServer, a fair product despite my antipathy MS).
Postgres has it, but it is kind of a pain to setup correctly and I love RDS because I don't have to deal with the setup anymore.
> Postgres has it, but it is kind of a pain to setup correctly and I love RDS because I don't have to deal with the setup anymore.
Check out barman from 2ndquadrant, we've been running it in production for 2 years now - setup was crazy easy and the one time I had to do a restore (for the same reason, UPDATE without a WHERE) it was no-fuss to get it done.
Of course, don't let me stop you from using RDS - but there's certainly user friendly backup solutions for Postgres when you're not :)
From their homepage, the features not available for Beta (because Cloud SQL for PostgreSQL is in Beta, some PostgreSQL features are not yet available):
One of the most annoying things for me about Postgres when I switched from MySQL is that in the former you can't put LIMIT clauses on UPDATE/DELETE statements.
When I'm doing surgical work on a DB, I always, always want to do something like :
- SELECT statement showing me the relevant rows (and rowcount=N)
- UPDATE/DELETE statement with a corresponding limit equal to N+1
It gives nice, easy peace of mind that you aren't accidentally wiping out your whole table because you messed up the logic on your WHERE clause. Of course if you made a mistake, you probably still killed N records, but often that is much much better than killing the whole table (and maybe also downstream tables that are linked with FKEY cascade delete!)
It seems to me that the amount of work required to fix the above, in most cases, would be almost equal to the amount of work that would be required if you hadn't used the LIMIT clause.
If you are that concerned, put "begin;" before your command, check that the updated/inserted number is reasonable, and then either do a commit or a rollback. That way you also didn't screw up N+1 totally random rows. You can even put a returning clause on the update to see which rows you were affecting.
Or if you can't afford to lock the table in the process, before you run UPDATE {foo} WHERE {bar} you back up the relevant rows into a temporary table with SELECT * INTO foo_backup WHERE {bar}.
None of this should cause a table lock: at best you will just lock the affected rows and at worst you will end up with a predicate lock on the where clause.
245 comments
[ 5.8 ms ] story [ 209 ms ] threadhttps://aws.amazon.com/premiumsupport/pricing/
https://cloudplatform.googleblog.com/2017/03/reimagining-sup...
Before the reoganization I'd send in quota updates and they'd take 1-3 days. The last quota bump I did took 7 minutes.
They had a rocky start as they were apparently ramping up the support organization, but these days I'm hearing nothing but praise.
They're getting very good at transparency. They have numerous mailing lists [1] ("Google Groups", ugh) for things like product release notes and planned changes. They just opened a public issue tracker [2] that covers the entire Google Cloud Platform.
If you're into Kubernetes/GKE, the Google team is also very active and responsive.
[1] https://cloud.google.com/support/docs/groups
[2] https://issuetracker.google.com/
At the simplest level when I buy compute time that looks like everybody else's compute time, I don't want to find after the fact that its provisioning is entangled in some weird corporate ideology that is now impacting my end users, left waiting to be discovered by the unsuspecting victim long after they've made plans around GCP.
(This is a true story from 2 months back, same shit used to happen with App Engine all the time)
Here is a list of likely affected territories: https://support.google.com/a/answer/2891389?hl=en
Though some of the Google services are available for personal use in those countries, commercial use is restricted. A cloud would count as commercial use, even if it's only to host your own stuff.GCP is far from the only cloud to suffer from it and many other services impose this too. The Docker Hub does it too for example.
But anytime this comes up on HN there are a slew of comments saying that support is top notch for GCE, so it's worth an evaluation at least.
If you have to raise a ticket it's a bit more variable, but on the whole I've had every issue resolved satisfactorily.
edit: Seriously a down-vote for asking why someone doesn't like one of the major 3 cloud platforms? These threads can be pretty childish sometimes.
Source: Work on Cloud SQL.
https://cloud.google.com/sql/docs/postgres/high-availability
https://cloud.google.com/sql/docs/postgres/replication/
Any timelines on high availability support? This would be pretty helpful
If you're running a CloudSQL instance, you can use a sidecar container to manage proxying the connection to the database: https://github.com/GoogleCloudPlatform/cloudsql-proxy
"The Cloud SQL Proxy allows a user with the appropriate permissions to connect to a Second Generation Cloud SQL database without having to deal with IP whitelisting or SSL certificates manually."
I think what most people mean when they say that is "don't put the DB in Docker", so don't use Docker to host Postgres. Just because your app is hosted by Docker doesn't make it more or less wise to connect to a database. It just depends on if you need a database or not.
I suspect that they intend that use case to be fulfilled by Cloud Spanner: https://cloud.google.com/spanner/
Don't think that they care (or should care) much about Postgre. One doesn't go to Azure for that.
Edit: not a complete end of the world, but it would be really nice (and completely easy/safe) to have the uuid-ossp extension available.
Edit: Nevermind, it does! https://cloud.google.com/sql/docs/postgres/extensions
For the record, uuid-ossp is a steaming pile and there's no reason to use it for anything on a modern Postgres install.
There's no reason to use it and incorporating it into projects just creates headaches down the road.
[1]: https://www.postgresql.org/message-id/flat/52CF07C2.3080101%...
Only does UUID 4, which should work for many applications.
Sample monthly pricing:
db-f1-micro instance : $7.56 for compute;
10GB HDD : $0.9 for storage;
No network cost if the database instance is talking to a GCE VM in the same region;
Disclaimer: I work on Google Cloud SQL
>db-g1-small
>db-n1-highmem-2
>db-n1-standard-8
>D32 Database Instance (16GB RAM)
>Tier D0, D1, D2, D4, D8, D16, D32
What's up with cloud instance naming schemes? I get this is kind of similar to Amazon, but man, I bet these are really unwieldy in conversations esp. if someone is new to a platform.
There's at least 2 performance dimensions for provisioning an instance: vCPUs and memory. Often also GPUs, local SSDs, local HDDs. And then you have multiple generations of hardware, which aren't 100% comparable to each other.
So coming up with a "fully systematic" naming scheme is not really possible without listing all the parameters, and then you lose the benefit of having a name.
You'll still see instance size names for a while though. I think D0-D32 are for first generation of CloudSQL (which is MySQL only). db-* are for second generation and match GCE instance names.
https://cloud.google.com/sql/docs/postgres/pricing
Perhaps the difficulty of working this out is from a lack of clarity on what those values would be? Or have I missed something bigger?
Disclosure: I work on Google Cloud (but not Cloud SQL).
I don't want to be overly negative though - releasing now at least let's us play with it and see how it stacks up.
As a point of clarification though Beta => GA is about production hardening. Products can't go to GA without demonstrating that they've met their SLOs continuously for several weeks. Products can take longer than that if they feel they should make more tweaks first (and pgsql certainly qualifies), but we want to both ship quickly and get out of the reputation for perpetual Beta.
https://twitter.com/googlecloud/status/839901710948589568
This might is bit off topic on this thread.
Seems like there is some confusion going on about the Free tier on a post[1]. Can you please comment there on whether the 'Always free' is free only during the first 12 months or forever?
Also, if I have been using Google Cloud since before today (when free trial was $300 over 60 days), am I still eligible for the 'Always free' tier?
From the page linked and the FAQ, it looks like it but many people on the thread I've linked are thinking otherwise.
Can you please clear that up for us? Thank you!
[1]: https://news.ycombinator.com/item?id=13832519
Another quick question. Is there anyway to see during instance creation/usage if it is part of the free tier?
When I create a f1-micro instance, it shows the usual $5/month billing, but doesn't indicate any kind of 'free tier' usage. How can we know if any service we use will be a part of the free tier for sure? I guess I can wait a few days to see if any costs accrue, but I was wondering if there was a better way for everyone.
As soon as it gets out of beta, it will get an SLA and deprecation policy of hopefully 2+ years notice before it gets discontinued.
No timeline, partially because we don't know ourselves. Our main priority for next few weeks will be ensuring everything is nice and stable. Once we are confident in current feature set we will start adding more. You can watch https://cloud.google.com/sql/docs/postgres/release-notes for news.
Source: I work on Cloud Postgres.
As someone who interacts with PostgreSQL on-prem and cloud deployments frequently, I'm curious on the Hacker News community's thoughts on one question.
AWS has a fairly mature RDS Postgres offering. What would motivate you to use Google Cloud Postgres instead?
I've heard of four reasons from users: not on AWS, don't want to be locked into one vendor, cost, and better support. Do any of these reasons resonate with you or are there others?
The other reasons listed are an order of magnitude less important for my cost/benefit calculus (though things like cost and support will definitely matter to orgs bigger than mine).
Plus RDS was the only reasonable option at that price tier (with high availability and multi-AZ). I think competition was sorely needed.
RDS was pretty much becoming a monopoly on this front.
They have a HA postgres offering (not sure about multi-az) and I thought I'd heard good things about them in the past?
The ability to cap costs.
With AWS, by the time you get a billing alarm, you could be thousands of dollars in the hole and there's nothing you can do about it. Avoiding that risk will help me sleep a little better.
I think Google Cloud is the middle ground between Heroku and AWS. It has potential to really gain traction with developers who want to get stuff shipped and not wear DevOps hats full time. What I'd like to see is Google adopting more modern software on their platform (Python 3) and trying to move things out of beta more quickly. You can't sell beta to management easily.
However, man that Awsrunfile or whatever it is called, and the two versions that are incompatible with the different EB versions, and it's painful... the hosted container solution equally so.
GC's docs and tools just seem so much more straight forward (as do Azure's for that matter).
Strongly agree. I think that using an orchestration tool like Ansible or Cloud Formation is basically essential for AWS, because so many of the services have these interdependencies.
> Even getting ElasticBeanstalk running with Docker isn't really easy.
Yeah, we tried it. Not a great experience, and using an AWS proprietary container hosting system when everyone else is standardising on Kubernetes is not remotely attractive. I'm really looking forward to trying App Engine Flexible and GKE. If we can get really good application container hosting from GCP, then that will be a strong pull to migrating whole stacks.
I would love to see your own cloud offerings on Digital Ocean and on Google Cloud. Hopefully, with that said, we'll also see much more reasonable pricing as well!
Yes, we do start at a higher end $990 a month, but we're very much focused on heavier workloads. Typically users come to us at 100 GB or more. If you're well below that we encourage you to stick with single node Postgres either RDS or Heroku Postgres. Once you get close to a $1k a month spend on those then we can start to make sense to consider.
The price to performance ratio is fairly unbeatable.
Yes, you can absolutely get that much storage for that price. Though what your application needs in terms of memory/cores varies quite a bit on the application. We've seen customers that were spending $800 a month on RDS, migrate and get 2-3x performance boost for the same dollar spend.
Don't disagree at all that if you're at a lower volume of data that RDS is a great option for what you get. Depending on your application needs though as you scale and need more data in cache or more cores doing work, though this all depends on your workload. You can have 3 TB of cold storage and that work fine for your application and cost you under $1k a month on Aurora, or you could have needs with 100 GB of data that you need all queries served from cache in milliseconds. It's very unlikely you'll get that for $260 a month on RDS even at as little of 100 GB of data. It just depends on your application workload, for as long as you can you should just keep scaling up because it's much easier.
We very much focus on when you start to encounter that ceiling where scaling up starts to become prohibitive and performance is key not just storage–which can be as early as 100 GB, and is increasingly common the further you get beyond that.
Surely this is only true for certain definitions of 'production workloads'?
[1]: https://cloud.google.com/terms/
[2]: https://cloud.google.com/terms/deprecation
https://cloud.google.com/terms/
Disclaimer: I work on GCP, though not on Cloud SQL.
And while this doesn't have an deprecation policy applicable as a Beta feature, most GA Google Cloud features have a one-year deprecation policy, so even if they were retired, no one would have the rug pulled out.)
Bet hey, keep the uninformed meme going if you like.
(For "Local SSD" the IOPS are a function of the number of devices you attach)
Anyone have any comments or experiences with the Google app engine flex environment for ruby?
It doesn't have all the magic of App Engine Standard and deploy times are slower than I'd like (~5 minutes). But I'm okay with that if I can use my own database, any library I want, and I have full portability.
I did a blog post with some of the stuff that I learned: http://www.thagomizer.com/blog/2017/03/09/rails-on-app-engin...
Postgres has it, but it is kind of a pain to setup correctly and I love RDS because I don't have to deal with the setup anymore.
Check out barman from 2ndquadrant, we've been running it in production for 2 years now - setup was crazy easy and the one time I had to do a restore (for the same reason, UPDATE without a WHERE) it was no-fuss to get it done.
Of course, don't let me stop you from using RDS - but there's certainly user friendly backup solutions for Postgres when you're not :)
1) Replication
2) High-availability configuration
3) Point-in-time recovery (PITR)
4) Import/export in CSV format
Volume snapshot restoration is atomic and probably faster, but it gets you only the specific point in time where the snapshot was taken.
I guess the worst case in terms of storage usage in both mechanisms are not that different, but PITR should be fully transparent performance-wise.
When I'm doing surgical work on a DB, I always, always want to do something like :
- SELECT statement showing me the relevant rows (and rowcount=N)
- UPDATE/DELETE statement with a corresponding limit equal to N+1
It gives nice, easy peace of mind that you aren't accidentally wiping out your whole table because you messed up the logic on your WHERE clause. Of course if you made a mistake, you probably still killed N records, but often that is much much better than killing the whole table (and maybe also downstream tables that are linked with FKEY cascade delete!)