Which relational Database is cost effective?

Hi Team,

I am recently running into some doubts regarding choosing Cloud SQL vs Cloud Spanner. My size of database would be very small like up to 1-2 GB as text only and up to like ~3000 raw at max, scalability would be also very slow on it, but read and write will be daily once or twice on each raws of table.

I was checking on gcp cloud cost estimator, I find that cloud SQL with 10 GB and lowest size of instance costs 435$/month whereas cloud spanner with 100 processing unit only cost ~75$. 

There are many posts saying Cloud Spanner is expensive compare to others as well as should use cloud spanner if database size is large. can someone help me with some inputs?

Solved Solved
0 4 3,959
1 ACCEPTED SOLUTION

Thanks. I have checked further and found this to share. I think it answers to what I am looking for. 

According to Google's documentation, at 100% CPU utilization, each 1,000 processing units (1 node) of compute capacity can support up to 15,000 reads per second or 2,300 writes per second (assuming 1KB per row for both reads and writes). Each optional read-only replica can support an additional 5,000 reads per second.

Therefore, for 100 processing units, which is 1/10 of a node's resource, you can expect a pick capacity performance of up to 1,500 reads/sec or 230 writes/sec in a single region. Again, it's important to note that the actual performance may vary depending on the specifics of your use case. It's always a good idea to perform load testing and benchmarking to determine the actual performance of your system under real-world conditions.

However, final outcome will be based on performance testing. but so far I don't think I have any plan to reach these limit, as it won't be this many requests/seconds. 

View solution in original post

4 REPLIES 4

Hi @jatin_rajpura ,

Welcome to the Google Cloud Community!

You can check more about pricing:

In Cloud SQL, pricing is composed of:

  • CPU and memory pricing
  • storage and network pricing
  • instance pricing

In Cloud Spanner, pricing is composed of:

  • The amount of compute capacity in your instance
  • The amount of storage that your databases use
  • The amount of storage that your backups use
  • The amount of network bandwidth used

Also, you can also check in with Cloud Billing Support to assist with your billing needs.

let me know if it helped, thanks!

Hello,

Thanks for the links. It is something I have already checked before posting my question, however I am here asking some specific help to understand if my understanding is correct or something I should be concerned about.

While I was checking or comparing price at Google Cloud Pricing Calculator, I can see the price is a lot cheaper for Cloud Spanner than Cloud SQL. is it correct based on my usage or something I can optimize in here?

Thanks

Jatin

The Spanner price could be very low for 100 processing units but you might need to perform additional testing to understand if that performance level would be sufficient for you. I would advice to do the tests and see what can be done with 100 processing units. From any other point of view Spanner might be a great choice for you. 

Thanks

Thanks. I have checked further and found this to share. I think it answers to what I am looking for. 

According to Google's documentation, at 100% CPU utilization, each 1,000 processing units (1 node) of compute capacity can support up to 15,000 reads per second or 2,300 writes per second (assuming 1KB per row for both reads and writes). Each optional read-only replica can support an additional 5,000 reads per second.

Therefore, for 100 processing units, which is 1/10 of a node's resource, you can expect a pick capacity performance of up to 1,500 reads/sec or 230 writes/sec in a single region. Again, it's important to note that the actual performance may vary depending on the specifics of your use case. It's always a good idea to perform load testing and benchmarking to determine the actual performance of your system under real-world conditions.

However, final outcome will be based on performance testing. but so far I don't think I have any plan to reach these limit, as it won't be this many requests/seconds.