►
From YouTube: Lightning Talk: Revolutionizing Application Architecture with Wasm Powered Database Ex...Carl Sverre
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Lightning Talk: Revolutionizing Application Architecture with Wasm Powered Database Extensibility - Carl Sverre, SingleStore
In this talk, Carl will show how Wasm embedded in the database can simplify applications and improve performance. In addition, we will take a close look at the benefits of running business logic within a database transaction, and how this differs from other application architectures. To help explain these concepts, Carl will use a demo of a virtual universe composed of millions of AI agents compiled to Wasm and running entirely within a distributed database.
A
Hello,
everyone,
my
name
is
Carl
and
today
I'm
going
to
be
talking
about
revolutionizing
application
architecture.
We're
going
to
be
talking
about
was
in
the
database
and
why
I'm
super
excited
about
it
and
also
how
I
see
wasm
just
helping
out
with
so
many
parts
of
our
ecosystem,
so
just
getting
into
it.
As
I
said,
my
name
is
Carl
severe
and
I.
Am
a
senior
director
of
engineering
at
single
store
single
store?
Is
a
database
company?
A
We
sell
a
distributed
relational
SQL
database
lots
of
buzzwords,
but
what
matters
to
this
group
is
that
single
store
embeds
Walzem,
so
you
can
take
any
walls
and
module
and
compile
it
against
Wazi,
push
it
into
single
store
and
run
that
code
directly
inside
of
a
massive
distributed
relational
database
and
it
works.
It
works
great
and
I'm
actually
going
to
be
doing
a
live
demo
in
a
lightning
talk.
So
we're
going
to
see
how
well
that
goes.
A
So
why
put
wasm
in
the
database
I
believe
that
wasm
in
the
database
allows
us
to
build
apps
easier
and
safer,
and
what
does
that
mean?
It
means
that
we
can
basically
make
apps.
We
can.
We
can
reduce
the
complexity
of
applications,
but
we
can
also
ensure
that
things
like
state
is
handled
in
a
more
sort
of
atomic
and
transactional
way.
Databases
are
really
really
good
at
this.
This
is
sort
of
our
bread
and
butter
and
Walzem
is
really
good
at
moving
compute
to
wherever
the
data
is.
So.
A
So
let's
talk
about
serious
business,
so
this
is
some
serious
business
that
I'm
doing
on
my
users
and,
as
you
can
see,
I'm
looping
through
all
my
users
and
running
some
update
functions
very
important
for
my
business.
I
might
have
like
hundreds
of
thousands
of
users,
and
ideally
I
would
say
that
most
Engineers
writing.
This
code
expects
this
code
to
execute
transactionally.
You
want
all
of
your
users
to
be
updated,
or
none
of
your
users
to
be
updated
anywhere
in
the
middle
is
very
complicated.
A
But
of
course,
we've
all
been
here
somewhere
in
the
middle
of
that
Loop.
You
know,
life
doesn't
go
the
way
you
think
it
goes,
and
so
you
know
many.
Many
years
ago,
people
came
up
with
solution
to
this.
They
said
well,
we
can
use
this
thing
called
a
relational
database.
We
can
create
transactions
and
we
can
pass
transactions
through
all
of
our
code
and
we
can
bundle
up
all
these
changes
together
and
this
that
this
works
this.
A
This
does
accomplish
the
goal
of
making
this
serious
business
operation
transactional
and
making
it
happen
either
entirely
or
or
not
at
all,
and
and
when
an
exception
occurs
in
this
world,
we
have
some
concept
called
rollback.
We
can
reduce
the
state
back
to
where
it
was
before
the
transaction
started,
very,
very
cool,
but
anyone
who's
written
transactional
code
in
very
large
code
bases
know
that
this
comes
with
a
cost,
causes
complexity
and
the
cost
is
performance.
A
Not
only
do
you
have
to
now
manage
these
transaction
objects
moving
them
through
your
code,
and
this
can
be
quite
quite
complex.
You
might
have
to
go
through
multiple
libraries,
maybe
even
third-party
libraries,
to
get
the
transaction
object
to
use
in
all
the
right
places,
but
you
also
potentially
have
a
lot
of
performance
cost
in
this
naive
piece
of
code
that
I
have
here
I'm.
Now
round
tripping
to
the
database
for
every
single
user.
A
In
my
in
my
data
set,
this
is
cost
that
is
sort
of
unavoidable,
because
we
need
to
be
able
to
run
custom
code,
custom
business
Logic
on
each
of
these
users
that
business
logic
as
of
yeah,
it
doesn't
doesn't
exist
in
the
database.
We
can't
push
it
there,
but
everyone
would
probably
agree
with
me
that
this
is
this
is
complicated.
This
is
this
is
silly.
What
we
really
want
is
we
just
want
this?
We
just
want
to
write
our
code
to
the
way
that
we
originally
intended
it
to
be.
A
A
We
allow
you
to
write
code,
looks
like
this
and
we
allow
you
to
have
that
code
intelligently,
pushed
down
into
the
engine
and
for
the
engine
to
actually
understand
that
what
you're
doing
is
looping
through
your
users
running
some
update
operation
on
each
user,
and
we
want
that
to
be
done
as
close
to
the
data
as
possible,
reducing
any
round
trips
that
we
don't
need
to
do,
and
that
is
a
story
of
Lawson
and
I'm.
Very,
very
excited.
You
know.
A
lot
of
the
talks
this
morning
have
been
forward-looking.
A
Looking
forward
to
where
we
see
while
I'm
going
in
this
is
yet
another
case.
We
don't
have
everything
that
we
need
to
be
able
to
accomplish
the
goal
I
just
set
out
but
we're
getting
there.
We
have
the
basic
foundational
building
blocks
and
for
that
I'd
like
to
do
a
quick
live
demo.
Hopefully
I
have
time
and
and
specifically
we're
going
to
go
to
space.
A
So
let
me
just
exit
out
of
the
presentation.
So
this
is
the
Lawson
Space
Program
I
do
have
to
plug
in
my
laptop
because
it's
Linux
and
it's
old
and
if
I
don't.
This
will
never
render
in
real
time
so
we're
getting
there
it
mostly
looking.
Okay,
the
laws
of
space
program
is
a
demo
that
I
created
to
show
off
what
it's
like
to
put
wasm
in
a
very
large
distributed
system
and
run
a
non-trivial
workload
in
that
system.
So
if
we
enter
the
walls
of
space
program,
we
see
one
little
solar
system.
A
This
is
just
running
on
my
laptop
inside
the
solar
system.
We
have
nothing,
let's,
let's
go
ahead
and
create
some
things,
so
this
is
a
little
spaceship,
I'm
going
to
create
and
I'm
going
to
create
some
energy
nodes
right
now.
My
spaceship
is
doing
nothing
behind
the
scenes.
This
spaceship
is
represented
by
a
literal
row
in
a
relational
database.
A
That's
all
it
is,
and
every
single
second,
this
relational
database
is
essentially
running
that
Opera
of
that
serious
business
operation
I
showed
earlier,
it's
looping
through
all
the
spaceships
and
running
some
wasm
code
on
every
single
spaceship,
and
that
code
is
actually
running
inside
of
the
engine
right
down
beside
the
data.
There's
there's
no
other
backend
service,
or
anything
like
that.
So
we
have
this
spaceship.
We
want
it
to
do
something.
So
let
me
open
up
my
fancy.
A
Fancy
rust
code
and
I
wrote
this
macro,
because
I
didn't
want
to
walk
through
a
bunch
of
rust
code,
and
this
is
a
lightning
talk.
So
I
I
have
this
macro,
which
allows
me
to
sort
of
fuse
together
a
bunch
of
basic
AI
behaviors
that
I've
already
written
so
my
strategy.
Blank,
which
is
the
strategy
that
this
spaceship
is
using,
has
no
behaviors
so
I'm
going
to
add
in
strategy,
Chase
energy,
save
that
and
then
we're
just
going
to
compile
it.
A
So
this
compilation
step
is
just
you're
going
to
quickly
read
through
just
cargo
Wazi
builds
or
just
doing
a
regular
rust
Wazi
build
and
then
we're
just
using
the
MySQL
command
line
tool
to
literally
just
upload
that
Walden
file
to
the
engine
that
happens
very
quickly
and
right
away
without
doing
anything
else.
Our
spaceship
has
now
moved
to
the
closest
energy
node,
and
if
we
create
a
couple
more
spaceships,
we
can
see
that
they
they
exhibit
that
behavior
and
that's
because
now
that
AI
has
literally
running
that
wasn't
code
that
I
just
uploaded
the
database.
A
Now
this
is
really
cool,
but
I
mean
anyone.
We
can
obviously
simulate
a
couple
of
spaceships
on
any
any
laptop.
That's
not
very
hard.
What
might
be
more
interesting
is
upgrading
to
a
much
larger
cluster,
and
so
this
is
the
real
live.
Wasn't
Space
Program,
you
guys,
can
race
me
and
try
to
go
there
before
I
before
the
demo
completes
in
this
live
demo.
There
is
32
000
solar
systems
and
in
each
of
these
solar
systems,
there's
tons
and
tons
of
spaceships
that
all
are
living
out.
A
Their
little
spaceship
lives
inside
of
this
massive
virtual
Universe
simulation,
and
we
can
just
jump
anywhere
in
this
demo
and
we
see
spaceships
doing
various
things
and
none
of
these
ones
are
very
exciting,
but
we
can
just
jump
to
like
another
solar
system
and
see
what's
going
on
and
in
total
this
particular
simulation.
So
you
can
see
there's
spaceships
running
around
over
here.
This
particular
simulation
has
over
a
million
spaceships
that
are
running
and
simulated
in
real
time.
Every
single
769
milliseconds
to
be
precise,
about
four
and
a
half
million
wasn't
function.
A
Invocations
are
happening
in
this
cluster
and
that's
all
happening
in
real.
Every
single
operation
allows
a
spaceship
to
see
its
entire
region
of
space
around
the
spaceship
make
concrete
AI
decisions
about
what
it
wants
to
do
issue
those
turns
and
and
execute
it,
but
even
more,
interestingly,
is
the
entire
turn
that
750
milliseconds
of
operations
that
are
going
through
and
updating
all
the
state
runs
in
one
transaction,
and
that
is
the
future
of
putting
wasm
in
transactional
systems.
A
C
Answer
is
yes,
but
I
didn't
do
that.
So
here's
my
serious
question
so
you're
building
wasm
in
the
database
and
what
about
SQL
and
pl
SQL,
so
I
sort
of
have
that
Oracle
background?
How
can
can
you
compare
what
what
you're
going
to
be
able
to
do
with
wasm
in
a
database
with
what
people
use
SQL
and
pl
SQL
for.
A
Absolutely
it's
a
great
question,
so
let's
go
ahead
and
look
at
all
the
pl
SQL
that
is
happening
so
right
now.
Our
the
limitation
of
single
store
wasm
is
that
we
can
run
wasn't
udfs.
We
can
run
laws
of
udas
and
tvfs,
which
are
technical
words
and
database
speak
for
basically
functions
that
operate
over
the
data
itself,
but
we
don't
have
Yet
the
full
procedural
level
SQL,
but
that's
next,
and
so
what
you're?
Seeing
on
the
screen?
Hopefully
is
the
Run
term
function.
This
runs
a
single
transaction.
You
can
see.
A
We
have
start
transaction
here,
and
this
is
a
bunch
of
PL
SQL,
which
basically
runs
a
bunch
of
update
queries
over
the
data
and
those
update.
Queries
themselves
run
laws
of
functions
so
we're
basically
using
the
laws
of
a
single
sort
of
push
the
AI
down
to
like
the
lowest
level
to
the
actual
sort
of
rows.
But
we
still
because
we
don't
yet
have
that
next
level,
which
is
the
procedural
level.
We
don't
have
the
ability
to
basically
put
this
entire
function
in
wasm,
but
we
want
to
do
that.
D
A
I
think
that's
a
really
cool
idea,
so
a
lot
of
databases
have
looked
at
the
idea.
If
I
understand
your
question
correctly,
like
it's
around
using
worlds
to
actually
model
objects
within
the
database
and
be
able
to
interact
with
them
and
other
databases
have
used.
This
sort
of
object
model
before
they've
tried
to
experiment
like
I
know
that
SQL
server
has
like.net
objects
where
you
have
like
custom
types
with,
you
can
send
and
receive
messages
to
them.
I
think
that's
another
story
that
was
worth
exploring
here.
We
are
part
of
the
by
code
Alliance.
A
A
A
Fantastic
idea,
so
we
actually
have
a
bunch
of
experimental
work
that
is
going
on
in
the
python
ecosystem,
where
you'd
be
able
to
have
like
a
regular
python
notebook
and
have
basically
Lambda
functions:
trans
dynamically
pushed
down
into
the
engine.
So
where
we
have,
you
know
a
billion
rows
sitting
in
single
store.
You
might
want
to
run
some
python
code
over
those
billion
rows
to
do
some
data
science
workload
or
something
so
we
want
to
be
able
to
dynamically
sort
of
handle
that
and
push
that
down.
E
A
So
udfs
are
the
simplest
case
because
fundamentally
UDF
is
is
stay
in
state
out
there
they're
not
stateful
themselves,
so
we
can
actually
just
put
them
into
our
regular
transactional
framework,
which
already
supports
running
arbitrary
code,
except
right
now,
with
single
store
before
wasm.
You
had
to
write
the
code
in
in
the
special
PL
SQL
language.
Now
you
can
basically
run
write
your
code
in
Rust,
but
the
asset,
the
atomic
unit
of
like
a
function
that
takes
them
to
stay
in
and
returns
from
State
out.
It
just
automatically
inherits
the
transactional
properties.
A
Because
it's
it's
item,
it's
state,
it's
stateless
right,
so
we
can
rerun
it.
We
can
automatically
sort
of
put
that
in
now,
as
we
get
into
the
higher
level.
So
going
back
to
this
other,
the
other
question
I
received
on
PL
SQL
and
then
procedural
logic,
that's
where
it
gets
a
little
bit
more
tricky,
and
that
goes
back
to
the
last
time.
I
gave
a
talk
here
with
Bailey.
We
talked
about
Wazi
data
and
Wazi
data.
A
Was
the
higher
level
like
talking
about
the
story
of
basically
bringing
the
transactional
layer
up
into
the
wasm,
where
you
can?
Actually
have
like
just
your
rust
code,
say
like
start
transaction
and
actually
do
like
something.
It
looks
like
almost
like
transactional
memory
at
the
application
layer
and
we
want
to
be
able
to
do
that
type
of
stuff
as
well.