Add to Chrome
Add to Edge
Add to Firefox
Add to Opera
Add to Brave
Add to SafariWhen comparing Google Cloud SQL vs Cloudant, the Slant community recommends Cloudant for most people. In the question“What are the best DBaaS for Event Sourcing?” Cloudant is ranked 1st while Google Cloud SQL is ranked 4th. The most important reason people chose Cloudant is:
You can choose to host your database on a single cloud provider or you can replicate it over several different providers.
Question Ranking
Pros
Pro Supports automatic encryption
Google Cloud SQL automatically encrypts all tables and temporary files.
Pro Can replicate the database across several hosts
You can choose to host your database on a single cloud provider or you can replicate it over several different providers.
Pro Runs on both bare-metal and virtual machine
Users can choose whether their database instance will run on bare-metal or a virtual machine
Pro Crash friendly
The database behind Cloudant, CouchDB uses an append-only file for it's data. To restore already used up space, a compaction must happen. When this happens is up to the database maintainer.
Pro Cloud agnostic
Cloudant hosts databases with a lot of different cloud hosting providers including Amazon, Rackspace, SoftLayer and Microsoft Azure. This way customers can choose where their database is hosted.
Cons
Con AWFUL data integrity practice: Backup lifecycle is tied to instance lifecycle
If you are using Google CloudSQL, you are one command away from losing everything:
gcloud sql instances delete prod-instance-nameWhen you delete a CloudSQL instance, it also deletes the back-ups associated with that instance along with it. So if you accidentally delete your production database: Your backups? Poof. Gone.
It says this in the fine print of the on-demand backups documentation: https://cloud.google.com/sql/docs/mysql/backup-recovery/backups#about_on-dem
They persist until you delete them or until their instance is deleted.There is also no way to mark a CloudSQL instance as "protected" so one bad CLI command can lose you your production database and all backups.
In order to get an actual backup workflow that will not affect production traffic, you must:
Don't fall for it. Protect your production data. Avoid busywork caused by poor product design. Avoid Google CloudSQL.
Con Performance limits
There are some performance limits when dealing with transactions for Google Cloud SQL.
Con Can only achieve consistency through replication and verification
Since CouchDB is considered an AP (Available, Partition-Tolerant database management system), it is not really consistent (not all clients can have the same view of the data consistently) and the only way to achieve some "eventual consistency" is through replication and verification of data.
