Using Google Spanner to Store Critical Data

Highly available, low latency, globally consistent SQL transacational database is a reality

By: Liudmila

Critical data we are dealing with:

Enterprise accounts data (schools, students, admn info)
Billing and financial data

Ideally we’d have a database which meets the requirements:

Global consistency
High availability
Low latency

Running DB Instances

What is we run our own instance of, say, PostgreSQL.

Pros:

No vendor lock-in
Easier development (can run locally on dev laptops)

Cons:

Complex Ops (nontrivial recovery, replication, …)
Without use of synchronization hardware (GPS, atomic clocks) it is hard for these DBs to combine global consistency, low latency and availability.

Using Google Spanner

Pros:

It’s a managed service
Availability (0-RTO - zero recovery time objective)
Consistent indexes & transactions
Low latency (atomic clocks minimize ACK round trips)
Lock-free schema updates

Cons:

Google-only
No dev emulator

To mitigate both potential vendor lock-in and lack of development emulator we’ll stick to using ‘common’ SQL as much as possible. E.g. in dev mode and for unit tests we’ll use regular SQL DBs (SQL Lite and PostgreSQL). This should allow us to migrate away from Spanner is similar offering appears and becomes attractive.