►
Description
Web technologies have come leaps and bounds. But are you still using the tired old database from last generation? Let’s look at the methodology of microservices, compare it to bounded contexts, and look at ops tasks for micro-databases. Let’s tour all the flavors of databases, understand their pros and cons, and when you would choose it. You’ll leave with a roadmap for moving from data-monolith to micro-databases.
Guest Speaker:
Rob Richardson, Developer Evangelist, MemSQL
OpenShift Commons Briefing
July 22 2020
Rob Richardson is a software craftsman building web properties in ASP.NET and Node, React and Vue. He’s a Microsoft MVP, published author, frequent speaker at conferences, user groups, and community events, and a diligent teacher and student of high quality software development. You can find this and other talks on https://robrich.org/presentations and follow him on twitter at @rob_rich
A
A
I've
ran
into
this
scenario
enough
that
I
take
the
complete
opposite
approach.
My
slides
are
on
my
website
right
now
you
can
go
to
robrich.org
and
you
can
see
these
slides
on
my
site
right
now.
Let's
go
to
robrich.org
and
click
on
presentations
right
here
at
the
top
and
here's
databases
in
the
microservices
world.
A
You
can
get
to
the
slides
that
we're
about
to
look
at
right
now,
while
you're
here
on
my
site,
click
on
about
me
and
you'll
get
to
this
page-
and
this
is
some
of
the
things
that
I've
done-
I'm
a
microsoft
mvp,
I'm
a
friend
of
redgate,
I'm
an
evangelist
for
mem
sql
azgive
camp
is
wonderful.
Azgive
camp
brings
volunteer
developers
together
with
charities
who
otherwise
couldn't
afford
software
services.
We
start
building
software
for
them
friday
after
work
sunday
afternoon.
We
deliver
that
completed
software
back
to
the
charities.
Sleep
is
optional.
A
Caffeine,
provided,
if
you're
in
phoenix,
come
join
us
for
the
next
mem,
the
next
a-z
gift
camp
or,
if
you'd,
like
a
gift
camp
in
your
area,
reach
out
to
me
on
twitter
or
by
email
and
let's
get
philanthropy
installed
in
your
area
too.
Some
of
the
other
things
I've
done:
sql,
source
control,
basics,
minus
chapter
eight.
That
was
a
lot
of
fun
to
write.
I
worked
on
gulp
in
the
in
version
two
and
version
three,
as
a
core
contributor,
and
one
of
the
things
that
is
particularly
cool
is
dot
net
rocks.
A
A
Talked
about
this
guy
application
architecture,
let's
start
here,
because
this
is
kind
of
fun.
As
we
look
at
the
mechanism
of
microservices,
when
we
look
at
microservices,
we
can
kind
of
think
of
it.
In
this
way
we
started
with
spaghetti.
We
moved
to
lasagna
interior
architecture
and
ultimately
we
ended
up
with
ravioli
microservices.
A
A
A
But
ultimately
it's
you
know
it's
all
deployed
in
one
piece
and
we
deployed
it
in
one
piece,
because
deployment
was
hard
we'd
get
on
a
conference
call
at.
I
don't
know
two
in
the
morning
on
friday,
night
and
we'd
keep
deploying
until
sunday
afternoon
when
we
got
it
right
and
it
was
hard.
It
was
really
hard
because
it
was
hard.
We
didn't
do
it
very
often
we'll
fast
forward
to
today,
and
now
we
have
containers
that
makes
deployment
really
easy.
A
It's
cake
to
spin
up
a
new
system
to
get
content
forwarded
from
the
internet
deployment
is
no
longer
hard,
because
deployment
is
no
longer
hard.
We
can
architect
differently.
We
can
architect
as
microservices
here
on
the
right,
and
so
these
microservices
each
one
is
responsible
for
a
very
small
piece
of
the
application's
functionality.
A
That
makes
the
code
a
lot
simpler.
It
makes
the
program
really
elegant
and
it
makes
it
replaceable
if
we
have
a
change
in
business
logic
or
in
business
need,
we
can
swap
out
a
microservice
with
a
different
microservice
that
accomplishes
the
task
better
or
add
new
microservices
to
accomplish
new
tasks,
and
each
of
these
microservices
then
can
scale
independently.
A
A
Now,
here
in
this,
we
have
a
user
interface
and
the
user
interface
will
probably
hit
a
load
balancer
that
will
then
proxy
off
to
each
of
the
microservices
or
we
may
have
microservices
running
on
subdomains,
but
then
the
microservices
as
they
need
to
reach
out
for
data.
They
will
reach
out
to
other
microservices
to
get
the
content
from
that
microservices
data.
A
So,
as
we
look
at
microservices,
they
they
do
one
job
they're
easy
to
deploy
now
with
containers,
and
they
can
scale
independently
of
other
content.
If
we
need
to
scale
up
the
shopping
cart,
we
don't
also
need
to
scale
up
the
login
system
and
the
monthly
reporting
system
they're
easy
to
replace,
and
in
particular
one
of
the
tenants
of
microservices
is
that
each
microservice
could
own
its
own
data.
A
Now,
the
beauty
of
having
the
microservice
own
its
own
data
is
that,
if
that
data
needs
to
evolve,
if
that
microservice
needs
to
get
replaced
or
adjusted,
then
there's
no
concept
of
well.
Who
owns
this
piece
of
data,
and
can
I
change
it
and
do
I
need
to
get
all
the
approval
processes
that
microservice
owns
that
data
and
as
the
microservice
evolves,
the
data
can
evolve
too.
A
Well,
we
set
out
to
build
microservices
and
we
want
them
to
own
their
own
data.
But
usually
we
fall
back
into
a
pattern
like
this,
where
we
have
one
monolithic
database
that
database
that
we
use
last
year
or
10
years
ago
or
a
generation
ago,
and
we
we
have
our
micro
services,
but
they
all
talk
to
the
same
database.
A
Bummer
well,
why
do
we
do
this?
Well,
there's
a
lot
of
reasons
but
provisioning.
The
database
is
still
hard,
there's
a
lot
of
content
in
there
and
when
we
lose
a
database,
then
that's
traumatic
to
the
organization.
We've
just
lost
data.
We've
lost
customer
records.
If
we
lose
a
web
server
yeah,
we
can
prop
up
a
web
server.
The
website
may
be
down
for
a
little
bit
said
another
way,
what'll
make
the
news
is
losing
the
database.
A
A
A
Ultimately,
the
dba
is
pushing
back.
He
doesn't
want
too
many
little
databases
because
did
we
remember
to
secure
it?
Are
they
all
backed
up?
It's
really
easy
when
we
have
lots
of
little
databases
to
forget
that
basic
database
hygiene,
I
guess
we
didn't
back
up
that
database
and
completely
lost
all
of
our
customer
data.
That's
not
something
that
we
want
to
hear.
So
to
avoid
that,
we
don't
create
these
little
databases.
We
have
one
monolithic
database.
A
So
now
what
do
we
do
about
it?
Well,
if
we
must
use
a
monolithic
database,
we
can
treat
it
like
lots
of
little
databases
with
bounded
context
and
a
bounded
context
is
a
methodology
within
an
application
to
be
able
to
carve
out
that
portion
of
the
database.
That
is
necessary
for
this
particular
task
of
work.
A
When
we
think
about
a
bounded
context,
we
could
look
at
a
shopping,
cart.
Well,
a
shopping
cart
needs
access
to
the
product,
catalog
the
shopping,
cart.
Experience
probably
owns
the
product
catalog
portion
of
the
database.
You
know
all
of
the
product
descriptions
and
all
of
the
pictures,
but
they
don't
need
to
own
the
customer
record.
They
don't
need
to
own
hr
data,
they
only
need
to
own
the
product
catalog
and
the
shopping
cart.
A
The
orders
produced
by
comparison,
the
fulfillment
system,
doesn't
need
to
worry
about
what
is
the
product
description
and
the
pictures
at
all
the
fulfillment
system's
goal
is
to
ensure
that
the
content
is
delivered,
ensure
that
it
shipped
so
they
own
things
like
the
shipping
address
and
the
order
status.
You
know
updating
the
order
status
to
mark
that
it
is
shipped
they
may
own.
Some
billing
details,
you
know,
was
it
billed
or
perhaps
that's
a
separate
system.
A
A
Each
hopefully,
we
can
get
to
micro
databases
where
each
microservice
owns
its
own
database,
but
in
the
shortest
term
a
bounded
context
is
a
great
way
to
go.
How
do
we
get
then
to
micro
databases?
Well,
here's
that
micro
database
mechanism,
where
each
microservice
owns
its
own
data.
Now
we
still
have
those
two
concerns
about
who
owns
the
backup
and
who
owns
the
authentication
story.
A
So
to
get
to
micro
databases,
we
need
to
do
interesting
things
like
a
mechanism
to
enroll
a
database
in
an
authentication
and
backup
strategy.
We
need
that
automation.
When
we
have
that
automation,
we
can
move
to
microdatabases.
We
can
get
to
that
point
where
we
have
lots
of
little
databases
that
accomplish
lots
of
tasks.
A
A
The
beauty
of
a
service
bus
is
that
the
publishers
can
publish
content
into
that
service
bus
and
they
don't
need
to
get
that
data
consumed
right
away
simultaneously.
A
consumer
can
grab
data
out
of
that
database
whenever
they're
ready
and
might
even
be
able
to
back
up
and
re-read
some
of
the
data
out
of
that
service
bus.
A
So
if
we
have
a
service
bus
between
our
microservices,
then
those
things
that
need
to
can
publish
events
into
the
service
bus
and
those
things
that
need
other
data
can
subscribe
to
that
event
in
the
service
bus.
We
call
this
event
sourcing,
where
we'll
publish
events
into
an
event
store
and
then
we'll
consume
those
from
another
store.
A
A
Well,
if
we're
in
micro
databases
where
each
event
or
each
microservice
owns
its
own
data,
well
do
all
of
them
on
the
customer
record.
Or
do
we
go
back
to
a
monolithic
database
where
the
customer
record
is
you
know
one
big
piece
so,
for
example,
should
the
shopping
cart
own,
the
customer
record,
you
know
they're
responsible
for
creating
an
order
based
on
a
customer,
they'll
likely
verify
the
shipping
address
or
should
billing
own
it?
You
know
they're
the
ones
that
need
to
own
the
credit
card
information
or
should
human
resources.
You
know.
A
Human
resources
has
lots
of
well
secret
data
about
the
about
the
user
and
it
needs
to
be
kept
within
hr's
boundaries
or
should
sales
own.
It
they're,
probably
the
first
person
that
saw
the
customer,
but
in
sales,
there's
very
different
validation
requirements,
for
example
a
lead
or
a
prospect.
They
may
only
have
a
name
and
a
phone
number
they
may
not
have
a
company
address,
but
for
order
entry
we
need
to
have
a
full
shipping
address.
We
probably
need
a
phone
number.
A
A
A
So
the
shopping
cart
can
call
into
the
customer
microservice
and
say:
hey.
I've
got
this
customer
id.
Is
this
a
valid
customer
id
or
I've
got
this
account
number?
Is
this
a
real
account
number?
The
billing
can
go.
Ask
the
customer
microservice
hey!
I
I've
got
this
credit
card
detail.
Is
this
customer
still
active?
Can
I
still
create
this
purchase
for
them?
A
Human
resources
has
all
of
their
data
within
their
human
resources
microservice,
but
the
customer
id
is
still
in
the
customer
microservice,
because
we
have
this
mechanism
where
each
microservice
owns
its
own
data,
then
each
one
can
define
what
customer
means
to
them
to
the
customer.
Microservice
a
customer
is
merely
an
auto
incrementing
primary
key
and
an
account
number
everything
else
is
stored
somewhere
else.
Sales
has
the
their
micro
service
that
has
a
foreign
key
off
to
this
customer
microservice
and
they
have
all
of
the
lead
and
prospect
information.
A
A
We've
created
a
schema
where
we
have
micro
services
that
have
maybe
overlapping
bounded
contexts,
but
each
of
them
still
owns
their
own
data
with
no
overlap
into
any
other
data
using
event
sourcing.
We
can
get
different
data
to
different
microservices
or
if
the
billing
service
does
need
to
call
out
to
the
customer
microservice,
then
that's
totally
fine.
A
So
micro
databases
we've
reached
it,
we've
gotten
to
the
point
where
each
microservice
owns
its
own
data.
We
have
enough
automation
to
be
able
to
enroll
these
databases
in
authentication
and
backup
strategies
as
soon
as
they're
created.
So
we
know
we
still
have
that
data
safety,
but
we
also
have
a
user
experience.
A
an
architected
system
that
will
scale
horizontally
rather
than
needing
to
scale
vertically,
with
very
large
database
servers,
we've
gotten
to
let's
coin
the
term
again.
A
Micro
databases.
This
is
really
cool.
Microservices
require
micro
databases.
If
we
have
the
automation
to
get
there,
then
it
can
be
really
really
cool.
Well.
The
other
thing
that's
really
interesting
here
now
is:
when
we
have
micro
databases,
each
database
doesn't
need
to
be
the
same
kind
of
database
anymore,
that's
pretty
cool,
so
some
microservices
may
be
able
to
store
data
in
a
form
that
is
better
suited
to
that
database.
A
A
Okay,
so
because
they
all
don't
all
have
to
be
the
same
type.
Let's
look
at
some
of
the
database
types
that
we
now
are
able
to
choose
from
well
relational,
a
sql
database,
a
document
database
or
a
nosql
database,
a
graph
database
key
value
time,
series,
search,
object
or
blob,
store,
file,
store,
column
store
and
let
me
introduce
you
to
new
sql
databases
as
well.
A
So,
first
up
with
each
of
these
we'll
look
at
the
characteristics,
the
pros
and
cons
best
use
cases
for
this
particular
database
type
and
some
example,
databases
that
will
get
you
to
google
search
terms.
I'm
definitely
not
pitching
a
particular
database
in
this
section,
but
when
we
look
at
examples
that
will
help
you
to
be
able
to
google
it
okay,
first
up
relational
databases.
A
What
I
love
about
relational
databases
is
it's
a
great
default?
It's
a
really
easy
mechanism
to
understand
in
a
relational
database.
We
have
rows
and
columns.
You
can
think
of
this
like
an
excel
spreadsheet.
With
a
spreadsheet,
we
have
rows
and
columns.
One
of
the
big
defining
characteristics
then
of
this
is
that
each
column
has
exactly
the
same
kind
of
data
in
it.
A
A
A
This
talk
here
where
they
talk
about
all
of
the
particulars
about
acid
compliance
and
I'd,
invite
you,
as
you
grab
the
slides
from
roberts.org
to
click
through
this
link
and
read
this
article
asset
compliance
suggests
that
all
of
the
data
either
succeeds
or
fails
together.
We're
not
going
to
get
part
of
the
update
through
and
part
of
it,
not
we're
not
going
to
lose
some
of
the
data,
all
of
it
either
gets
through
or
all
of
it
doesn't.
A
A
A
similar
thing
is
like
a
bank
statement.
If
I
go
to
my
bank
right
now,
I
may
or
may
not
have
the
charge
that
I
just
made
at
starbucks,
but
at
the
end
of
the
month,
I'll
have
all
of
the
details
of
my
statement.
There
is
eventual
consistency
sufficient
or
do
I
need
asset
compliance?
That's
definitely
a
question
for
your
organization
and
probably
for
your
microservice.
Does
this
microservice
need
eventual
consistency
or
acid
compliance.
A
So
here's
those
details
of
a
sql
database
rows
and
columns
one
big
server
tables
of
consistent
rows
and
columns.
Acid
compliance
and
sql
queries
one
big
server
so
typically
because
database
engines
were
built
before
multi-threaded
cpus
were
a
thing
most
sql
database
engines,
scale
vertically.
I
can't
really
put
two
machines
together
and
tell
them
your
one
database.
A
A
A
Did
that
end,
I
may
choose
to
use
an
orm
to
be
able
to
get
at
this
data
easier,
an
object,
relational
mapper
that
does
that
heavy
lifting
of
turning
my
objects
in
my
application
into
rows
and
columns
in
my
database
and
back
it'll.
Take
my
code-based
queries
and
turn
them
into
sql
queries
and
return.
Those
results.
A
A
Now,
the
beauty
of
a
document
database
is
that
I
can
take
this
json
blob
and
I
can
stick
it
in
my
database
as
one
piece
of
data
instead
of
tables,
we'll
probably
talk
about
collections
and
we
probably
mean
the
same
thing.
The
interesting
thing
about
these
json
documents,
though,
is
that
they
don't
all
have
to
be
the
same.
Each
document
can
include
or
exclude
any
fields
that
they
need
to,
and
I
can
nest
content
within
this
record.
A
They're,
ultimately
optimized
for
reads,
and
so
I
may
choose
a
schema
that
is
well
a
little
bit
redundant
to
ensure
that
I
can
read
really
quickly.
A
great
example
might
be
a
news
site
where
I
need
to
read
everything
about
that
news:
article
in
one
shot.
So
I'll
put
the
author
name
I'll,
put
the
author's
details,
I'll
put
the
title
and
body
content,
and
I
may
put
the
first
two
comments
in
this
single
document
so
that
I
read
by
id.
A
I
get
back
that
entire
document
and
I
render
that
page
in
one
go
now
most
document
databases
are
distributed
across
many
machines.
That
means
I
can
use
commodity
hardware
there,
and
so
I
don't
need
to
scale
up
to
one
big
object
or
one
big
machine
that
is
wonderful,
but
because
of
that
they'll
set
aside
acid
compliance
for
eventual
consistency.
A
Is
it
committed
when
I
only
write
it
to
one
machine
or
is
it
committed
when
I've
distributed
that
to
all
of
the
machines?
Do
I
need
to
wait
for
quorum
across
all
of
the
cluster
to
be
able
to
decide
that
that
data
is
committed?
Different
nosql
databases
here
will
make
different
choices
there,
but
ultimately
that's
kind
of
the
major
difference
here.
Sql
databases
are
one
big
box
and
no
sql
databases
are
json
documents
on
many
boxes.
A
A
I
have
no
schema,
which
means
my
application
probably
needs
to
enforce
different
things
like
my
database
probably
does
have
a
schema
in
the
mind
of
the
architect
who
built
it,
but
now
I'm
just
not
telling
the
database
about
it.
So
now
I
have
to
do
things
like
well.
What
if
I
read
data
that
doesn't
exist?
What
if
I'm
trying
to
do
a
wear
query,
a
filter
on
a
field
that
doesn't
exist,
so
no
no
schema
can
kind
of
be
a
two-edged
sword
there.
A
Ultimately,
because
I'm
outside
of
sql,
we
may
kind
of
try
to
layer
a
sql-like
language
on
top
of
a
document
database,
but
I'm
outside
sql.
I
don't
have
that
really
really
fast
tuned
engine,
so
we
end
up
with
sdks
for
each
language
and
that
sdk
may
have
you
know:
json-like
query
syntax,
but
it's
not
sql
or
maybe
it
is
sql.
But
now
how
do
I
talk
about
nested
things
that
can
get
a
little
bit?
Weird
in
document
database,
one
of
the
big
downsides
to
document
databases
is
each
collection
is
its
own
island.
A
There
isn't
really
a
concept
of
joins
in
a
document
database.
Now,
maybe
that's
okay,
but
the
way
we
avoid
joins
is
we
denormalize
our
data?
We
have
duplicate
copies
that
does
make
writes
more
expensive,
because
I
need
to
update
all
of
the
copies,
but
again
in
document
databases,
we're
optimizing
for
reads
so.
Here's
some
examples
of
document
databases.
A
A
Relationships
then,
are
directional,
which
is
pretty
cool,
so
graph
database.
How
is
that
different
from
a
sql
table
with
two
foreign
keys?
Well
yeah?
I
could
kind
of
start
to
fake
a
graph
database
with
sql,
but
it's
that
query
syntax.
That
makes
it
really
elegant
the
concept
of
being
able
to
join
across
those
relationships
in
a
really
elegant
way,
and
so
to
that
end
graph
databases
are
really
tuned
for
those
relationships.
A
A
A
So
a
graph
database,
here's
some
examples.
Graph
databases
are
great
for
social
networks,
because
social
networks
really
focus
on
those
relationships.
Messaging
apps,
where
I
need
to
keep
track
of
all
the
messages
between
people.
Maybe
a
recommendation
engine
might
work
for
a
graph
database
because
it's
keeping
track
of
relationships
between
products
next
up
key
value
databases.
A
Now
key
value
database
is
really
cool
in
that,
given
a
key
go
read
a
blob
of
data,
often
the
data
is
json
or
a
big
text
blob.
Although
ultimately,
what's
interesting
about
key
value,
databases
is
the
value,
is
anything
we
can
think
of
this
as
a
sql
table
with
a
primary
key
and
a
binary
blob
value.
You
know
those
two
columns,
so
whatever
I
choose
to
write
in
that
binary
blob
is
kind
of
irrelevant
to
the
key
value
database.
A
This
is
really
great
for
those
key
value
type
of
experiences,
those
buy
id
type
of
experiences.
These
can
be
great
for
caching
servers.
If
we
need
it,
I
can
store
different
data
in
each
of
the
values
because
to
the
database,
it's
just
a
binary
blob
on
the
downside.
I
can't
really
query
for
anything
but
id.
A
A
A
A
Here's
some
examples
of
time,
series,
databases,
and
it's
really
great
for
that:
iot,
monitoring
or
real-time
events.
I
might
choose
to
grab
real-time
events
from
mobile
devices
or
sensors,
maybe
stock
trades
or
click
streams.
Those
are
great
for
time.
Series
databases
where
I
need
to
know
did
that
event
happen
within
that
time
window.
What
was
the
min
and
max
or
the
quantity
of
events
within
that
time
window
when
I
need
to
handle
that
data
in
bulk?
In
that
way,
time
series
can
be
great.
A
A
A
A
A
A
great
example
is,
I
may
choose
to
not
index
a
because
you
know
a
by
itself
has
no
meaning,
but
what
about
when
I
talk
about
the
street
avenue
a
well
now
that
a
is
really
important.
Did
I
create
a
stop?
Word
that
was
a
that
just
completely
dropped
it,
and
now
all
that
I've
indexed
in
the
street
name
is
avenue.
A
A
A
A
Next
up
an
object,
store
or
a
blob
store,
or
we
could
think
of
this.
As
you
know,
a
file
system,
I'm
not
going
to
say
file
system,
because
you
know
that
has
a
very
specific
connotation
s3,
isn't
a
file
system
or
is
it?
The
key
is
a
path
into
that
document
and
the
value
is
well
whatever
I
choose
to
put
there,
it's
really
great
to
think
of
it
as
a
file
system.
A
You
know
at
that
point
I
may
not
have
folders
per
se,
but
I
do
have
documents
and
I
may
choose
to
create
a
naming
convention
that
nests
them
in
these
simulated
folders.
That's
pretty
cool
these
object.
Blob
stores
are
great
for
very
large
things
for
videos
for
file
backups
system,
backups
they're,
not
great
for
when
I
need
to
query
inside
those
big
things.
A
A
So
object
stores
are
great
when
we
need
to
store
big
things.
We
probably
don't
want
to
put
a
database
backup
or
a
video
file
in
a
cell
in
a
relational
table.
Suddenly
our
database
is,
you
know
two
or
three
five
times
the
size,
but
we
do
want
to
upload
this,
to
maybe
our
nfs
file
share
or
to
another
blob
store
where
we
can
keep
that
object
as
an
object,
just
as
a
binary
blob
in
a
lot
cheaper
mechanism
for
storage.
A
A
Column
stores
are
great
for
faster
seeks
and
for
bulk
reads
by
comparison.
Row
stores
are
usually
better
if
I'm
doing
transactional
data,
where
I
need
to
do
lots
of
random
reads
and
writes,
because
lots
of
random
reads
and
writes,
aren't
really
the
job
of
column
stores.
Here's
some
examples
of
some
column
stores.
A
A
A
One
of
the
big
barriers
of
sql
databases
was
they
were
architected
when
one
machine
one
thread
was
the
name
of
the
game
with
a
new
sql
database.
We
may
choose
to
in
this
case
we're
looking
at
a
memsql
architecture.
We
have
a
few
aggregator
nodes,
we'll
submit
our
queries
to
one
of
these
aggregator
nodes
and
it
will
go
reach
into
leaf
nodes
to
get
the
data
out
of
the
partitions.
A
A
A
A
A
Newsql
databases
are
great
when
I've
outgrown
my
sql
database
when
I
just
can't
buy
a
bigger
box
or
when
I
need
to
store
more
data
or
when
I
get
that
spinning
wheel
of
doom,
where
my
queries
are
just
taking
too
long.
I
can
get
to
that
spot
where
I
can
partition.
My
data
across
databases
partition
my
data
across
nodes
and
be
able
to
get
at
that
content
in
a
very
multi-threaded
mechanism.
A
So
one
of
the
things
that's
particularly
cool,
then
is
a
lot
of.
Databases
are
looking
less
towards
being
a
specific
type
and
more
towards
being
a
hybrid
database.
I'm
primarily
this
database,
but
I'm
also
going
to
do
that
as
well.
So,
for
example,
a
sql
database
that
adds
json
types
or
a
time
series
window
or
adding
time
series
window
functions
to
a
relational
database
or
adding
a
two
column
relational
table
to
create
a
key
value
store
within
a
relational
database.
A
A
json
data
type
in
a
database
is
a
great
example
here,
because
I
can
create
what
is
effectively
a
nosql
database
embedded
in
a
column
of
a
sql
database.
Now
I
still
get
joins
across
all
of
my
relations,
but
I
may
still
have
interesting
query
syntax
into
that
json
blog.
I
can
treat
it
not
just
like
a
big
string
in
a
column
but
like
json
data
that
can
be
really
really
cool.
A
A
Micro
databases:
we
looked
at
each
of
these
types
of
databases
and
the
beauty
here
is
that
we
don't
need
to
choose
only
one.
We
can
choose
the
one
that
best
serves
the
task.
Another
magic
question.
Well,
how
do
we
choose
here's?
The
other
slide
as
you
grab
your
camera
grab
this
slide
too
or
head
out
to
robrich.org
and
grab
these
slides
there,
and
you
can
get
this
content
straight
away.
A
Here's
my
recommendations
and
also
recommendations,
as
advised
by
gartner.
Ideally,
you
would
use
a
database
as
a
service
now
database
as
a
service
is
great,
because
they'll
keep
track
of
all
of
the
backup
and
restore
pieces.
All
of
the
user
authentication
pieces,
all
of
the
uptime
pieces
never
get
woken
up
again
if
your
database
goes
offline.
A
You've
outsourced
that
to
your
database
as
a
service
provider
use
automation
if
you're
using
more
than
one
database
server,
because
that
automation
can
ensure
that
you
have
consistent
backups
consistent,
restores
consistent
user
authentication,
rolling
secrets,
whatever
you
need
that
automation
can
provide
that
by
default,
choose
a
sql
database.
Sql
databases
have
that
asset
compliance
they're
compatible.
A
You
can
get
a
really
good
generic
and
general
mechanism
built
into
a
sql
database
and
then
once
you've
got
that
solved
for
the
other
microservices,
where
different
data
is
best
served
by
a
different
data
store,
then
grab
a
different
data
store
that
exactly
matches
those
needs.
Now
you
may
choose
to.
A
You
may
choose
a
different
database
type
based
on
the
needs
of
that
data
and
ensure
that
it's
a
really
good
fit,
because
you
are
by
choosing
that
different
data
store
sacrificing
more
generic
things.
Now,
you've
specifically
chosen
that,
because
you've
specifically
carved
out
that
portion
of
the
data
that's
needed
for
this
microservice
or
perhaps
a
micro
service
needs
more
than
one
type
of
data
store
to
be
able
to
store
different
types
of
data.
A
B
Well,
first
of
all,
thank
you
for
that,
because
that
was
really
awesome
to
to
get
that
overview
and
and
to
lead
up
into
the
to
the
mem
sql
story
and
the
new
sql
databases.
I
think
that
was
a
really
nice
thing,
but
we've
got
one
question
coming
in
from
the
youtube
feed
and
you
may
have
already
covered
it,
but
just
to
repeat
what
are
the
downsides
to
using
new
sql
over
sql,
the
overhead
network,
latency
and
performance.
A
Yeah
definitely
great
question:
when
we
looked
at
new
sql,
a
new
sql
is
that
sql
engine,
but
not
constrained
to
one
box,
and
so
we
get
a
whole
lot
of
benefits
of
a
cheaper
way
to
deploy.
We
can
just
add
more
commodity
hardware
to
get
more
capacity
to
our
database
on
the
downside
that
one
that
one
concern
there
is
potentially
network
latency.
We
do
need
to
coordinate
between
multiple
boxes
to
do
this
now.
B
And
so
I
think
that
I
think
you
did
a
good
job
answering
the
question
earlier
and
that
so,
if
you
go
back
to
your
recommendation
slide
just
for
a
second,
if
you
could
just
pass
yeah
back
there,
one
of
one
of
the
things
that
is
is
interesting
to
me.
Is
this
new
database
as
a
service
and,
as
you
know,
an
old
school
person
that
you
could
date
myself
with
being
a
dba
for
a
sql
service,
sql
database
back
in
the
dark
ages.
B
So
there's
you
know,
I
think,
the
the
emergence
of
database
as
a
service
and
how
it
simplifies
things
for
developers
so
being
able
to
attach
to
the
service
and
let
the
service
provider
manage
and
the
distribute
distribution
of
the
service
and
the
security.
And
all
that,
can
you
talk
a
little
bit
more
about
how
that
that
has
changed
things.
A
A
A
A
That
doesn't
happen
in
a
cloud
database,
vendors
mechanism,
because
they're
keeping
track
of
all
of
those
pieces
in
really
elegant
ways.
Now
it
does
mean
you
need
to
let
go,
but
I
would
argue,
as
you
think,
through
those
types
of
things,
the
things
that
you've
chosen
to
outsource,
you
can
now
focus
on
solving
the
business
needs
that
you
have
not
on
solving
for
little
things
that
you
don't
care
about.
B
A
This
is
one
of
those
touchy
ones
as
as
an
advocate
for
mem
sequel.
I
need
to
show
you
how
easy
it
is
to
get
started
with
mem
sequel
on
red
hat.
If
I
go
to
the
redhat
marketplace,
I
can
just
type
in
memsql
and
here's
that
memsql
database
from
here
I
just
click,
go
and
provision
that
database
into
place
and
it'll
keep
track
of
memsql
that
new
sql
database
across
all
of
the
pieces,
so
that
you
know
all
of
the
pods
in
my
kubernetes
cluster
in
my
openshift
cluster
are
accounted
for
and
that's
really
cool.
B
B
What
what
it
is,
I
mean
it's
really
about
the
use
case,
and
so
there's
not
really
a
good
one-off
answer,
but
I
do
think
easily
easy
to
be
deployed
easy
to
maintain
scales.
Well,
those
kinds
of
considerations
are
part
of
the
first
order
of
things
that
I
look
for,
and
definitely
we'll
have
you
back
to
do
a
deep
dive
on
mem's
sequel
sometime
soon-
and
I
really
appreciate
you
taking
the
time
today
to
to
answer
these
questions
and
to
give
us
this
tour
to
force
on
databases
today.
B
A
B
A
Roman
users
have
other
questions
that
we
didn't
answer
here,
reach
out
to
me
on
twitter
at
rob.
Underscore
ridge
grab
these
slides
right
now
at
robrich.org,
and
let's
continue
this
conversation,
because
this
was
a
lot
of
fun.
Sharing
this
knowledge
with
you,
I'd
love
to
continue
learning
with
you,
too,.