1
00:00:00,180 --> 00:00:04,620
Last time I was here at Seattle Systems, just over a year ago, I spoke about the design

2
00:00:04,620 --> 00:00:09,660
of Aurora D -SQL. This is our scalable SQL database. It was a very fun thing to talk

3
00:00:09,660 --> 00:00:16,200
about, and this time I got to use D -SQL as a customer to build with the team,

4
00:00:16,280 --> 00:00:22,740
the scalable backend of Dogwood in the cloud. The cool way this works, and this was a

5
00:00:22,740 --> 00:00:27,660
core observation that John Tristan made, is the semantics of Dogwood and the semantics

6
00:00:27,660 --> 00:00:34,620
of SQL are actually pretty compatible. It's a fairly simple compiler that compiles Dogwood

7
00:00:34,620 --> 00:00:41,360
to SQL. This seems like a little bit of a wild thing to do, but if you think about how

8
00:00:41,360 --> 00:00:47,160
good SQL is at saying, before this key in a table, is this thing true? How many keys

9
00:00:47,160 --> 00:00:52,520
are in this range? These are the kinds of things that SQL databases do at scale, reliably,

10
00:00:52,860 --> 00:00:58,520
durably, isolated all day long, and so compiling Dogwood to SQL lets us take advantage

11
00:00:58,520 --> 00:01:02,560
of all of that great systems and database work that has been going on for decades and

12
00:01:02,560 --> 00:01:03,040
decades.

13
00:01:04,340 --> 00:01:08,520
You get durability, scalability, and high availability kind of for free by running on

14
00:01:08,520 --> 00:01:13,160
those backends rather than building one for yourself. You get strong consistency. It's

15
00:01:13,160 --> 00:01:17,580
not quite for free. Strong consistency is never quite for free, but you get it for cheap,

16
00:01:17,720 --> 00:01:23,780
which is also nice, and strong consistency is super important when you're a policy language

17
00:01:23,780 --> 00:01:28,780
because an eventually consistent policy language isn't pretty useless.