[MUSIC PLAYING]
SPEAKER 1: As a developer, I often find myself
needing to store data in a relational database.
I'd really like to let someone else worry
about the management of the database architecture,
and I'd like it to scale easily without worsening performance.
I know Cloud Spanner is a great solution for scalability,
but I don't have a lot of data, and my application
generates a fairly low amount of requests at the moment.
I've heard that Spanner is only for really large use cases,
like storing YouTube data.
I'm concerned that Spanner may be too much for my workload.
If this sounds like you, the Google Cloud Spanner team
is happy to introduce granular instance sizing.
Now you can use Spanner from a much smaller starting point
and at a lower cost.
Cloud Spanner is a great choice for any application that
requires availability and strong consistency without losing out
on performance.
As a managed Cloud native database,
Spanner provides high availability
by managing additional copies of your data, called replicas.
Replicas ensure data is persisted
and requests will continue to work seamlessly
without downtime and without the need for you
to manage complicated architectures.
As a horizontally scaling relational database,
Spanner is able to guarantee strong consistency of your data
by utilizing ACID transactions and leveraging a distributed
clock called TrueTime to guarantee
ordering of commits even across geographic locations.
This consistency is critical to prevent unexpected data
discrepancies.
As one example, imagine two players
of a game making a trade.
Consistency is needed to guarantee
the first player gets the money and the second gets the item.
Spanner also allows you to easily scale up
as your workload grows without requiring
you to manage complex sharding.
One way Spanner is able to support
the scalability is by separating compute and storage.
When you create a Spanner instance, up until now
you specify the instance size in terms of nodes.
Nodes determine how much compute and storage you have access to.
It does not impact the availability
guarantees of Spanner or the number of replicas
your instance has.
A single node provides enough compute capacity
for up to 10,000 reads per second or up to 2,000
writes per second.
You also get storage capacity for 4 terabytes of data.
This compute and storage capacity
might be too much for many applications,
and this overprovisioning may have caused application teams
to hesitate to choose Spanner despite the great benefits
of the database solution.
With the release of granular instance sizing,
it is now easier than ever and more cost-efficient to start
using Spanner.
Granular instance sizing introduces a new unit
called processing units.
1,000 processing units is the equivalent of a single node.
When you create a new instance, you
can either specify the size as a number of nodes
or a number of processing units.
You can size your instance as low as 100 processing units,
or 1/10 the storage and compute capacity of a single node,
at 1/10 the cost.
Granular instance sizing lets you get started with Spanner
starting at $65 a month.
For example, now your team can get started with test and dev
instances that don't need the full compute capacity
a single node provides.
You can size the instances for the amount of compute capacity
you need.
If your capacity needs start to grow,
Spanner makes it easy to scale up
without downtime to your users.
Scaling up can be done incrementally
to avoid overprovisioning your Spanner resources.
Granular instance sizing allows your team
to get the incredible features of Spanner, including
strong consistency, high availability, and scalability,
without overpaying for unused resources.
So go ahead and provision your Spanner instance
with granular instance sizing.
[MUSIC PLAYING]