1. Types
   1. Relational
      1. Cloud SQL
      2. Cloud Spanner
   2. Non relational
      1. Cloud Firestore
      2. Cloud Bigtable
   3. Data warehouse
      1. BigQuery
   4. Unstructured
      1. Cloud Storage
   5. In-memory
      1. Cloud Memorystore
   6. Fileserver
      1. Cloud Filestore
   7. Unmanaged
      1. Compute Engine/Persistent Disk
2. Storage
   1. Overview
      1. Enables users to create buckets to store data
      2. Globally unique name and location
      3. Default storage class for objects
      4. Low-milliseconds latency and high durability
   2. Storage Classes
      1. Standard
         1. Multi-Regional
            1. Designed for frequently accessed data
            2. e.g. hot objects, website content etc
            3. Highest availability
            4. Geo-redundant, US, EU etc
         2. Regional
            1. Designed for storing data in the same region
            2. Better performance for high-compute workloads
            3. Data stored in regional locations close to compute
            4. Lacks high availability
         3. Dual-Regional
            1. Data stored across two regions
            2. Similar to Regional storage class
            3. Provides high availability
            4. Higher cost than regional
      2. Nearline
         1. Designed for infrequently accessed data
         2. Read or modify data once a month or less
         3. Data backup
         4. Cost for data access
         5. Highly durable
         6. Geo-redundancy available
         7. 30-day minimum storage duration
      3. Coldline
         1. Designed for disaster recovery storage
         2. Access at most every 90 days
         3. Very low cost
         4. Highly durable
         5. Data available within milliseconds
         6. Cost for data access higher than nearline
         7. Geo-redundancy available
         8. 90-day minimum storage durability
      4. Archival
         1. Designed for data accessed approx once a year
         2. For long term storage of data for compliance
         3. Highest cost for data access
      5. Bucket storage class
         1. Specified when creating bucket
         2. Defaults to Standard storage class
         3. Regional or multi-regional
         4. Objects added use the default unless otherwise specified
         5. Bucket storage class can be changed
         6. Only new objects will be affected
      6. Object storage class
         1. Storage class for objects can be specified
         2. If not specified, object will take on default storage class of bucket
         3. Can be changed later autotomatically using Object Lifecycle Management
         4. Storage class setting for objects affects availability and pricing
         5. Availability, storage duration and pricing differ by storage class
3. SQL
   1. Overview
      1. Hosted MySQL, PostgreSQL and MSSQL database
      2. Traditional relational database, managed on Compute Engine
      3. Supports Lift and shift of on-premise database
      4. Often the first step for on-premise to Cloud migration
      5. Schema, SQL, Stong consistency, failover replica, vertical scalability
   2. Managed services
      1. OS and database installation and updates
      2. Storage (autoscaling)
      3. Backups
      4. Failover, read replicas
      5. Cross regional replication
   3. Limitations
      1. Hard cap of 30TB for single Cloud SQL instance
      2. Limited scalability (vertical rather than horizontal)
   4. Availability
      1. Failover created in separate region, or zone in same region
      2. Data is automatically replicated to failover instance
   5. Failover
      1. Primary instance stops responding
      2. Cloud SQL automatically fails over to failover instance
      3. Failover instance becomes the new primary instance
      4. Replication lag is the time a failover instance takes to catch up with primary instance update
      5. Replication lag does not result in data loss
      6. Lag can be addressed by increasing performance of failover instance
   6. Scaling
      1. Vertical scaling by increasing storage/compute for single instance
      2. Horizontal scaling by creating multiple read replicas
      3. Storage scales automatically, while compute does not
      4. No downtime during storage scaling
      5. Disk size directly tied to disk performance
      6. Compute (CPU/RAM) scaling requires a restart
4. Spanner
   1. Horizontally scalable relational database
   2. Cross regional availability
   3. Global footprint, strong consistency
   4. Near infinite capacity
   5. Not a direct lift and shift of MySQL. Modification required
   6. Schema, SQL, Stong consistency, high availability, automatic replication
5. Firestore
   1. Non relational database
   2. Semi-structured, ACID transactions
   3. Completely no-ops, no individual machine to interact with
   4. Key/value pair with flexible schema definition
   5. Scales from zero to terabytes
   6. Grows with application. Cost effective
   7. Ideal for web and mobile applications
   8. Improved query performance with indexes
   9. Composite index for complex queries
6. Bigtable
   1. Non-relational database
   2. Ideal for analytics
   3. Very high volume of writes
   4. Milliseconds response time
   5. More expensive than Datastore
   6. Requires node management
   7. HBase compatible
   8. Performance over cost efficiency
   9. Pay for nodes, irrespective of utilization
   10. Petabyte scale
7. Memorystore
   1. Managed in-memory database, compatible with Redis
   2. Results in very fast performance
   3. Sub-milliseconds data access
   4. Regional presence, similar to Cloud SQL
   5. Up to 300 GB instance capacity
   6. Failover and high availability across two zones in single region
8. Filestore
   1. High performance file store - NAS
   2. Managed file storage/sharing instance
   3. OS, updates, patches handled for user