Google Cloud SQL is a database-as-a-service (DBaaS) with the capability and functionality of MySQL.
$0
per core hour
PostgreSQL
Score 8.7 out of 10
N/A
PostgreSQL (alternately Postgres) is a free and open source object-relational database system boasting over 30 years of active development, reliability, feature robustness, and performance. It supports SQL and is designed to support various workloads flexibly.
N/A
Redis Software
Score 9.1 out of 10
N/A
Redis is an open source in-memory data structure server and NoSQL database.
N/A
Pricing
Google Cloud SQL
PostgreSQL
Redis Software
Editions & Modules
License - Express
$0
per core hour
License - Web
$0.01134
per core hour
Storage - for backups
$.08
per month per GB
HA Storage - for backups
$.08
per month per GB
Storage - HDD storage capacity
$.09
per month per GB
License - Standard
$0.13
per core hour
Storage - SSD storage capacity
$.17
per month per GB
HA Storage - HDD storage capacity
$.18
per month per GB
HA Storage - SSD storage capacity
$.34
per month per GB
License - Enterprise
$0.47
per core hour
Memory
$5.11
per month per GB
HA Memory
$10.22
per month per GB
vCPUs
$30.15
per month per vCPU
HA vCPUs
$60.30
per month per vCPU
No answers on this topic
No answers on this topic
Offerings
Pricing Offerings
Google Cloud SQL
PostgreSQL
Redis Software
Free Trial
Yes
No
Yes
Free/Freemium Version
No
No
Yes
Premium Consulting/Integration Services
No
No
Yes
Entry-level Setup Fee
No setup fee
No setup fee
Optional
Additional Details
Pricing varies with editions, engine, and settings, including how much storage, memory, and CPU you provision. Cloud SQL offers per-second billing.
—
—
More Pricing Information
Community Pulse
Google Cloud SQL
PostgreSQL
Redis Software
Considered Multiple Products
Google Cloud SQL
Verified User
Vice-President
Chose Google Cloud SQL
Given this is a hosted solution, database a service it helps in removing the effort of maintaining these databases manually. Eases out the pain of upgrading, applying security patches and keeping things running without having to worry about missed changes. The database can be …
Easier learning, simple features and settings with a very user-friendly application environment and flexible prices make Google Cloud [SQL] a pioneering option over competitors
Google Cloud SQL is very similar to other cloud provider options. AWS and DigitalOcean are direct competitors, While Azure is focusing on their own products. At cloud provider level, it's a matter of choosing the provider, and this product will not play a significant role on …
As mentioned previously, I came from primarily a MySQL background. I had used other databases such as SQL Server and Oracle, but MySQL is what I used most of the time for my RDBMS needs before switching to PostgreSQL. MySQL/MariaDB certainly have some great strengths, but I …
Compared to MySQL, it works well if you need to extend to your use case Compared to Spark, it works better w.r.t development time in a central database setting Like Redis, it cannot be used for caching and quick access of non-structured data
We are big users of MySQL and PostgreSQL. We were looking at replacing our aging web page caching technology and found that we could do it in SQL, but there was a NoSQL movement happening at the time. We dabbled a bit in the NoSQL scene just to get an idea of what it was about …
Every time you don't need a document DB, you can't go wrong with Redis over MongoDB. Google Cloud Pub/Sub may have solved one use case, but we'd still have to deploy Redis instances for other use cases, and adding another tech stack would only add complexity to our …
Redis was initially in the list of competitors like Aerospike, Cassandra, MongoDB.The major point that outset all others is that it provides a number of read and writes to the database that no one can match. Another major factor is Redis really knows the basic components that …
The only other product I've used that I would compare to Redis is Memcache. I prefer Redis simply because of its ease of use and it's very well documented. It also has a lot of community support which means there are a large number of client libraries that exist to make the …
As we perform a lot of deployments to AWS, we have the option of easily using a cache layer with either Memcache or Redis. We almost always choose Redis as it can solve more problems in production than Memcache in our experience. There is some overlap between what Redis can do …
Does what it promises well, for instance, as a sidecar for the main enterprise data warehouse. However, I would not recommend using it as the main data warehouse, particularly due to the heavy business logic, as other dedicated tools are more suitable for ensuring scalable operations in terms of change management and multi-developer adjustments.
PostgreSQL is best used for structured data, and best when following relational database design principles. I would not use PostgreSQL for large unstructured data such as video, images, sound files, xml documents, web-pages, especially if these files have their own highly variable, internal structure.
Redis has been a great investment for our organization as we needed a solution for high speed data caching. The ramp up and integration was quite easy. Redis handles automatic failover internally, so no crashes provides high availability. On the fly scaling scale to more/less cores and memory as and when needed.
Easy for developers to understand. Unlike Riak, which I've used in the past, it's fast without having to worry about eventual consistency.
Reliable. With a proper multi-node configuration, it can handle failover instantly.
Configurable. We primarily still use Memcache for caching but one of the teams uses Redis for both long-term storage and temporary expiry keys without taking on another external dependency.
Fast. We process tens of thousands of RPS and it doesn't skip a beat.
We had some difficulty scaling Redis without it becoming prohibitively expensive.
Redis has very simple search capabilities, which means its not suitable for all use cases.
Redis doesn't have good native support for storing data in object form and many libraries built over it return data as a string, meaning you need build your own serialization layer over it.
We will definitely continue using Redis because: 1. It is free and open source. 2. We already use it in so many applications, it will be hard for us to let go. 3. There isn't another competitive product that we know of that gives a better performance. 4. We never had any major issues with Redis, so no point turning our backs.
As with other cloud tools, users must learn a new terminology to navigate the various tools and configurations, and understand Google Cloud's configuration structure to perform even the most basic operations. So the learning curve is quite steep, but after a few months, it gets easier to maintain.
Postgresql is the best tool out there for relational data so I have to give it a high rating when it comes to analytics, data availability and consistency, so on and so forth. SQL is also a relatively consistent language so when it comes to building new tables and loading data in from the OLTP database, there are enough tools where we can perform ETL on a scalable basis.
It is quite simple to set up for the purpose of managing user sessions in the backend. It can be easily integrated with other products or technologies, such as Spring in Java. If you need to actually display the data stored in Redis in your application this is a bit difficult to understand initially but is possible.
The data queries are relatively quick for a small to medium sized table. With complex joins, and a wide and deep table however, the performance of the query has room for improvement.
GCP support in general requires a support agreement. For small organizations like us, this is not affordable or reasonable. It would help if Google had a support mechanism for smaller organizations. It was a steep learning curve for us because this was our first entry into the cloud database world. Better documentation also would have helped.
There are several companies that you can contract for technical support, like EnterpriseDB or Percona, both first level in expertise and commitment to the software.
But we do not have contracts with them, we have done all the way from googling to forums, and never have a problem that we cannot resolve or pass around. And for dozens of projects and more than 15 years now.
The support team has always been excellent in handling our mostly questions, rarely problems. They are responsive, find the solution and get us moving forward again. I have never had to escalate a case with them. They have always solved our problems in a very timely manner. I highly commend the support team.
The online training is request based. Had there been recorded videos available online for potential users to benefit from, I could have rated it higher. The online documentation however is very helpful. The online documentation PDF is downloadable and allows users to pace their own learning. With examples and code snippets, the documentation is great starting point.
Unlike other products, Google Cloud SQL has very flexible features that allow it to be selected for a free trial account so that the product can be analyzed and tested before purchasing it. Integration capabilities with most of the web services tools are easier regarding Google Cloud SQL with its nature and support.
Although the competition between the different databases is increasingly aggressive in the sense that they provide many improvements, new functionalities, compatibility with complementary components or environments, in some cases it requires that it be followed within the same family of applications that performs the company that develops it and that is not all bad, but being able to adapt or configure different programs, applications or other environments developed by third parties apart is what gives PostgreSQL a certain advantage and this diversification in the components that can be joined with it, is the reason why it is a great option to choose.
We are big users of MySQL and PostgreSQL. We were looking at replacing our aging web page caching technology and found that we could do it in SQL, but there was a NoSQL movement happening at the time. We dabbled a bit in the NoSQL scene just to get an idea of what it was about and whether it was for us. We tried a bunch, but I can only seem to remember Mongo and Couch. Mongo had big issues early on that drove us to Redis and we couldn't quite figure out how to deploy couch.
Improved integration with Google Cloud, we have set up some automations with Google Workspace, and we have noticed that the raw data sharing between them is very fast as compared to using some other managed database, not sure why.
Due to some downtime during maintenance, we had to set up a relatively small service which ingested the data while this went down and dumped it when it came back up. So this was a negative impact on our ROI, since now we had to remedy this downtime against the same profit margins
It was cheaper than the legacy aws service since we needed large database instances
Easy to administer so our DevOps team has only ever used minimal time to setup, tune, and maintain.
Easy to interface with so our Engineering team has only ever used minimal time to query or modify the database. Getting the data is straightforward, what we do with it is the bigger concern.
Redis has helped us increase our throughput and server data to a growing amount of traffic while keeping our app fast. We couldn't have grown without the ability to easily cache data that Redis provides.
Redis has helped us decrease the load on our database. By being able to scale up and cache important data, we reduce the load on our database reducing costs and infra issues.
Running a Redis node on something like AWS can be costly, but it is often a requirement for scaling a company. If you need data quickly and your business is already a positive ROI, Redis is worth the investment.