A Time-Series Database in Postgres - WHY?

1
00:00:00,200 --> 00:00:01,369
Postgres works great up
2
00:00:01,370 --> 00:00:02,220
to a certain scale and
3
00:00:02,220 --> 00:00:02,989
then it stops working.
4
00:00:03,000 --> 00:00:04,700
And so what you find
5
00:00:04,710 --> 00:00:05,940
is that users have the
6
00:00:05,940 --> 00:00:07,080
option either to like
7
00:00:07,120 --> 00:00:08,669
try to get like a very
8
00:00:08,840 --> 00:00:10,709
niche database, move
9
00:00:10,719 --> 00:00:11,959
off Postgres, go to
10
00:00:11,959 --> 00:00:12,590
something they're less
11
00:00:12,590 --> 00:00:13,239
familiar with, their
12
00:00:13,239 --> 00:00:14,059
team's less familiar
13
00:00:14,059 --> 00:00:14,939
with, not as good
14
00:00:14,940 --> 00:00:16,339
an ecosystem for it.
15
00:00:16,390 --> 00:00:17,259
Or they could just,
16
00:00:17,259 --> 00:00:18,089
you know, adopt
17
00:00:18,220 --> 00:00:19,079
timescale and basically
18
00:00:19,080 --> 00:00:20,119
keep everything they
19
00:00:20,130 --> 00:00:20,910
already know and love
20
00:00:20,910 --> 00:00:21,689
and then get these
21
00:00:21,780 --> 00:00:22,599
kind of superpowers
22
00:00:22,599 --> 00:00:23,040
on top of it.
23
00:00:23,275 --> 00:00:23,845
When you have
24
00:00:23,855 --> 00:00:24,895
compression, you do
25
00:00:24,895 --> 00:00:25,905
not calculate the
26
00:00:25,975 --> 00:00:26,755
uncompressed storage,
27
00:00:26,765 --> 00:00:27,665
if I understood that
28
00:00:27,665 --> 00:00:28,805
correctly, but you're
29
00:00:28,925 --> 00:00:29,985
calculating the
30
00:00:30,025 --> 00:00:31,415
actual storage uses.
31
00:00:31,425 --> 00:00:32,955
So if I have like a
32
00:00:32,955 --> 00:00:33,905
90 percent compression
33
00:00:33,905 --> 00:00:34,685
ratio, that means
34
00:00:34,685 --> 00:00:35,745
I'm paying like for
35
00:00:35,745 --> 00:00:36,855
10 percent of the
36
00:00:36,855 --> 00:00:37,824
actual data stored.
37
00:00:37,954 --> 00:00:39,654
More broadly, I think we
38
00:00:39,654 --> 00:00:41,205
are bullish on Postgres.
39
00:00:41,820 --> 00:00:42,839
And what that means
40
00:00:42,840 --> 00:00:43,860
is that, you know, we
41
00:00:43,860 --> 00:00:45,770
think that 99 percent
42
00:00:45,800 --> 00:00:47,610
of developers problems
43
00:00:47,670 --> 00:00:48,280
can be solved with
44
00:00:48,280 --> 00:00:49,570
Postgres for database.
45
00:00:49,790 --> 00:00:50,279
Now, there's going
46
00:00:50,280 --> 00:00:51,540
to be always that 1%.
47
00:00:51,570 --> 00:00:52,179
There's going to be
48
00:00:52,179 --> 00:00:53,560
the, Hey, I'm building
49
00:00:53,570 --> 00:00:55,389
Netflix, Uber, Google.
50
00:00:55,400 --> 00:00:56,240
They're going to build
51
00:00:56,240 --> 00:00:57,620
custom, but that's not
52
00:00:57,629 --> 00:00:59,179
what most companies do
53
00:00:59,179 --> 00:00:59,919
you're listening to
54
00:00:59,919 --> 00:01:00,799
Simplyblock's Cloud
55
00:01:00,799 --> 00:01:01,779
Commute Podcast,
56
00:01:01,899 --> 00:01:02,789
your weekly 20
57
00:01:02,789 --> 00:01:03,869
minute podcast about
58
00:01:03,869 --> 00:01:04,809
cloud technologies,
59
00:01:04,859 --> 00:01:06,349
Kubernetes, security,
60
00:01:06,349 --> 00:01:07,139
sustainability,
61
00:01:07,139 --> 00:01:07,559
and more.
62
00:01:09,689 --> 00:01:10,389
Hello everyone.
63
00:01:10,399 --> 00:01:11,499
Welcome back to the next
64
00:01:11,529 --> 00:01:12,719
episode of Simplyblock's
65
00:01:12,739 --> 00:01:13,769
Cloud Commute Podcast.
66
00:01:14,039 --> 00:01:15,159
This week, I have a
67
00:01:15,169 --> 00:01:16,279
very special guest.
68
00:01:16,279 --> 00:01:17,389
I know I say, oh, always
69
00:01:17,389 --> 00:01:18,229
say I have a special
70
00:01:18,229 --> 00:01:19,039
guest, but this week
71
00:01:19,039 --> 00:01:20,249
it's actually a special
72
00:01:20,249 --> 00:01:21,369
guest because he's-
73
00:01:21,509 --> 00:01:22,169
he's basically
74
00:01:22,169 --> 00:01:22,859
my old boss.
75
00:01:22,859 --> 00:01:23,939
I used to work for him.
76
00:01:24,629 --> 00:01:25,829
we know each other for,
77
00:01:25,829 --> 00:01:27,179
a long, long, long time.
78
00:01:27,479 --> 00:01:28,259
and nobody knows
79
00:01:28,259 --> 00:01:29,519
why that's the best
80
00:01:29,519 --> 00:01:30,209
thing about it.
81
00:01:31,289 --> 00:01:33,929
But maybe, Mike had some
82
00:01:33,929 --> 00:01:36,029
idea by now how to get
83
00:01:36,029 --> 00:01:38,249
here, . So, Hey Mike.
84
00:01:39,229 --> 00:01:40,099
Welcome to the show.
85
00:01:40,489 --> 00:01:41,389
glad to have you.
86
00:01:42,049 --> 00:01:43,459
maybe you can give
87
00:01:43,519 --> 00:01:44,329
a quick introduction
88
00:01:44,329 --> 00:01:44,749
of yourself.
89
00:01:46,229 --> 00:01:46,589
Sure.
90
00:01:46,599 --> 00:01:46,919
Thanks for
91
00:01:46,919 --> 00:01:47,529
having me, Chris.
92
00:01:48,209 --> 00:01:48,929
Mike Friedman, I'm
93
00:01:48,929 --> 00:01:49,679
the co founder and
94
00:01:49,679 --> 00:01:51,699
CTO here at Timescale.
95
00:01:52,429 --> 00:01:54,329
Timescale is a database
96
00:01:54,369 --> 00:01:55,669
company we build
97
00:01:55,669 --> 00:01:56,599
on top of Postgres
98
00:01:56,609 --> 00:01:57,569
to make it powerful
99
00:01:57,589 --> 00:01:58,539
for time series,
100
00:01:58,539 --> 00:01:59,329
advanced analytics,
101
00:01:59,539 --> 00:02:00,609
AI, and other things.
102
00:02:01,974 --> 00:02:04,054
I've been working in
103
00:02:04,084 --> 00:02:05,074
distributed systems
104
00:02:05,784 --> 00:02:06,794
and storage systems
105
00:02:06,794 --> 00:02:07,634
for many years.
106
00:02:08,604 --> 00:02:11,484
Not only as a founder
107
00:02:11,484 --> 00:02:12,374
and engineer, but
108
00:02:12,384 --> 00:02:13,884
I'm also a academic.
109
00:02:13,884 --> 00:02:14,604
I'm a professor of
110
00:02:14,604 --> 00:02:15,424
computer science at
111
00:02:15,424 --> 00:02:16,844
Princeton, where I've
112
00:02:16,844 --> 00:02:18,064
been on the faculty for
113
00:02:18,064 --> 00:02:20,334
the last 17 years now.
114
00:02:21,344 --> 00:02:22,034
So, time flies
115
00:02:22,034 --> 00:02:22,494
a little bit.
116
00:02:23,949 --> 00:02:24,609
Oh, wow.
117
00:02:24,829 --> 00:02:25,339
17.
118
00:02:25,379 --> 00:02:26,919
I knew you're Princeton,
119
00:02:26,919 --> 00:02:27,859
but I didn't know
120
00:02:27,859 --> 00:02:29,419
you were a professor
121
00:02:29,419 --> 00:02:30,219
for that long.
122
00:02:30,239 --> 00:02:30,609
Wow.
123
00:02:31,509 --> 00:02:31,939
All right.
124
00:02:33,519 --> 00:02:34,309
I have a bunch of stuff
125
00:02:34,489 --> 00:02:36,634
with elbow pads, and,
126
00:02:37,024 --> 00:02:38,404
graybeard, you know.
127
00:02:38,904 --> 00:02:39,854
That's perhaps
128
00:02:39,874 --> 00:02:40,694
my other persona.
129
00:02:42,274 --> 00:02:42,854
Okay.
130
00:02:42,924 --> 00:02:43,374
I see.
131
00:02:43,414 --> 00:02:43,774
I see.
132
00:02:43,934 --> 00:02:44,214
All right.
133
00:02:44,224 --> 00:02:44,854
You already
134
00:02:44,854 --> 00:02:45,904
mentioned timescale.
135
00:02:46,284 --> 00:02:46,754
You said it's
136
00:02:46,754 --> 00:02:47,944
a database, on
137
00:02:47,944 --> 00:02:48,624
top of Postgres.
138
00:02:49,014 --> 00:02:49,614
Maybe you can
139
00:02:49,724 --> 00:02:50,464
elaborate a little
140
00:02:50,464 --> 00:02:51,274
bit more on that.
141
00:02:51,774 --> 00:02:52,664
A lot of people
142
00:02:52,684 --> 00:02:53,535
listening in are
143
00:02:53,554 --> 00:02:54,334
actually timescale-
144
00:02:54,884 --> 00:02:55,654
Postgres users.
145
00:02:55,674 --> 00:02:56,014
Probably
146
00:02:56,014 --> 00:02:56,714
timescale as well.
147
00:02:57,664 --> 00:02:58,014
Sure.
148
00:02:58,414 --> 00:02:59,374
So Postgres,
149
00:02:59,704 --> 00:03:01,084
you know, old.
150
00:03:01,474 --> 00:03:02,874
Has been a database
151
00:03:03,304 --> 00:03:04,914
for, you know, now
152
00:03:05,154 --> 00:03:06,144
since the nineties
153
00:03:06,164 --> 00:03:07,114
been very popular, but
154
00:03:07,114 --> 00:03:08,304
really I think found a
155
00:03:08,364 --> 00:03:09,654
renaissance in the last
156
00:03:09,654 --> 00:03:11,724
five years is according
157
00:03:11,724 --> 00:03:12,674
to like StackOverflow
158
00:03:12,674 --> 00:03:13,694
is now the most popular
159
00:03:13,694 --> 00:03:14,994
database in the market.
160
00:03:15,004 --> 00:03:16,004
I think when people
161
00:03:16,004 --> 00:03:17,034
today look for
162
00:03:17,064 --> 00:03:17,404
something, that's
163
00:03:17,404 --> 00:03:18,184
what they turn to.
164
00:03:19,974 --> 00:03:22,864
About 15 years ago,
165
00:03:23,054 --> 00:03:23,964
Postgres started
166
00:03:23,974 --> 00:03:25,114
introducing an
167
00:03:25,114 --> 00:03:26,164
extension framework.
168
00:03:26,524 --> 00:03:28,014
And so this is what
169
00:03:28,014 --> 00:03:29,784
allows people to think
170
00:03:29,784 --> 00:03:31,584
of Postgres not only as
171
00:03:31,979 --> 00:03:32,969
the features it offers
172
00:03:32,969 --> 00:03:34,529
itself, the traditional
173
00:03:34,559 --> 00:03:36,519
OLTP database, you know,
174
00:03:36,529 --> 00:03:37,549
back your website, e
175
00:03:37,549 --> 00:03:38,989
commerce site, whatever,
176
00:03:39,749 --> 00:03:40,699
but also a way that
177
00:03:40,699 --> 00:03:41,739
it could be extended
178
00:03:41,749 --> 00:03:43,649
by third parties who
179
00:03:43,649 --> 00:03:44,329
actually have hooks
180
00:03:44,329 --> 00:03:45,699
throughout the database
181
00:03:45,739 --> 00:03:46,759
to make changes.
182
00:03:47,404 --> 00:03:48,064
In the beginning,
183
00:03:48,064 --> 00:03:48,814
that was, you know,
184
00:03:48,884 --> 00:03:50,194
add an index, add
185
00:03:50,194 --> 00:03:51,344
more monitoring,
186
00:03:51,914 --> 00:03:54,424
more smaller things.
187
00:03:55,264 --> 00:03:55,734
But you know, but
188
00:03:55,734 --> 00:03:57,674
timescale really,
189
00:03:58,044 --> 00:03:58,674
I think is at the
190
00:03:58,674 --> 00:04:01,724
forefront of advancing
191
00:04:01,774 --> 00:04:02,904
what you could do
192
00:04:02,924 --> 00:04:03,914
on top of this data
193
00:04:03,914 --> 00:04:04,894
platform other than
194
00:04:04,894 --> 00:04:05,944
what is offered by the
195
00:04:05,944 --> 00:04:07,004
core infrastructure.
196
00:04:07,954 --> 00:04:09,384
And so we basically
197
00:04:09,394 --> 00:04:10,904
built it to be also an
198
00:04:10,914 --> 00:04:12,714
analytics powerhouse to
199
00:04:12,714 --> 00:04:14,464
deal with time series
200
00:04:14,484 --> 00:04:15,934
data, event data,
201
00:04:16,374 --> 00:04:18,364
anything where rather
202
00:04:18,364 --> 00:04:19,704
than very small, you
203
00:04:19,704 --> 00:04:20,914
know, like update,
204
00:04:20,934 --> 00:04:22,054
deletes records, you
205
00:04:22,054 --> 00:04:23,454
want to ingest as
206
00:04:23,484 --> 00:04:24,854
large amounts of data
207
00:04:25,144 --> 00:04:26,554
and then ask questions
208
00:04:26,554 --> 00:04:28,874
about your particularly-
209
00:04:29,784 --> 00:04:30,434
almost how your
210
00:04:30,435 --> 00:04:31,274
data changes over
211
00:04:31,284 --> 00:04:32,834
time, aggregations
212
00:04:32,844 --> 00:04:33,754
on top of it.
213
00:04:34,084 --> 00:04:35,014
Basically insights
214
00:04:35,014 --> 00:04:36,244
to drive things like
215
00:04:36,634 --> 00:04:38,704
real time dashboards,
216
00:04:38,704 --> 00:04:40,134
API, Power Customer
217
00:04:40,134 --> 00:04:41,814
Facing APIs, and other
218
00:04:41,814 --> 00:04:42,384
things like that.
219
00:04:43,794 --> 00:04:44,084
Right.
220
00:04:44,634 --> 00:04:45,434
You already mentioned
221
00:04:45,444 --> 00:04:46,534
like analytics data,
222
00:04:46,534 --> 00:04:47,734
time series, maybe
223
00:04:47,924 --> 00:04:49,084
you can explain
224
00:04:49,104 --> 00:04:49,434
a little bit.
225
00:04:49,434 --> 00:04:50,244
I mean, I know what
226
00:04:50,244 --> 00:04:51,104
it is, but there's
227
00:04:51,124 --> 00:04:51,924
probably still a lot
228
00:04:51,924 --> 00:04:52,794
of people that have
229
00:04:52,804 --> 00:04:54,024
not really an idea what
230
00:04:54,024 --> 00:04:55,264
a time series is and
231
00:04:55,264 --> 00:04:56,324
how to identify one.
232
00:04:56,694 --> 00:04:56,994
Sure.
233
00:04:57,094 --> 00:04:58,554
So we think of time
234
00:04:58,554 --> 00:04:59,304
series as almost
235
00:04:59,344 --> 00:05:00,314
any data that has
236
00:05:00,314 --> 00:05:01,634
a timestamp where
237
00:05:01,634 --> 00:05:02,654
you might actually
238
00:05:02,674 --> 00:05:04,404
care about how
239
00:05:04,564 --> 00:05:05,424
something over time.
240
00:05:05,434 --> 00:05:05,454
Yeah.
241
00:05:06,059 --> 00:05:08,099
And so that could be on
242
00:05:08,099 --> 00:05:09,189
real wall clock time.
243
00:05:09,189 --> 00:05:09,949
How did something
244
00:05:10,029 --> 00:05:11,539
differ day to day?
245
00:05:11,589 --> 00:05:12,579
It could also be in
246
00:05:12,579 --> 00:05:14,099
terms of some abstract
247
00:05:14,099 --> 00:05:15,279
notion of system time.
248
00:05:15,309 --> 00:05:16,639
For example, we have a
249
00:05:16,639 --> 00:05:17,919
lot of crypto companies
250
00:05:17,939 --> 00:05:18,629
that use us for
251
00:05:18,629 --> 00:05:19,679
blockchain analytics,
252
00:05:20,079 --> 00:05:21,359
where the time that
253
00:05:21,359 --> 00:05:22,869
they think about is
254
00:05:22,889 --> 00:05:23,999
actually the blockchain
255
00:05:24,029 --> 00:05:25,174
height, which is a
256
00:05:25,174 --> 00:05:28,769
monotonic counter, as
257
00:05:28,769 --> 00:05:29,439
opposed to something
258
00:05:29,439 --> 00:05:30,309
that corresponds
259
00:05:30,309 --> 00:05:31,279
to wall clock time.
260
00:05:31,679 --> 00:05:32,539
But the nature of
261
00:05:32,539 --> 00:05:33,659
data is that it's
262
00:05:33,659 --> 00:05:34,669
append mostly.
263
00:05:35,789 --> 00:05:37,239
You are often interested
264
00:05:37,279 --> 00:05:38,449
in what happened
265
00:05:38,449 --> 00:05:40,659
recently, not equally,
266
00:05:40,719 --> 00:05:41,669
not randomly what
267
00:05:41,669 --> 00:05:42,629
happened five years
268
00:05:42,629 --> 00:05:44,019
ago, but you also
269
00:05:44,019 --> 00:05:45,919
want to often analyze
270
00:05:45,919 --> 00:05:46,889
the stuff over it.
271
00:05:46,979 --> 00:05:48,699
So rather than simple
272
00:05:48,849 --> 00:05:49,609
point queries, which you
273
00:05:49,629 --> 00:05:50,539
currently can certainly
274
00:05:50,539 --> 00:05:52,499
can do with timescale,
275
00:05:52,674 --> 00:05:53,994
you're often interested
276
00:05:53,994 --> 00:05:54,914
in things that look more
277
00:05:55,004 --> 00:05:56,004
scan like, where you
278
00:05:56,004 --> 00:05:58,584
want to scan over either
279
00:05:58,594 --> 00:06:00,404
some period of time, or
280
00:06:00,404 --> 00:06:02,804
by other thing like, a
281
00:06:03,104 --> 00:06:06,344
device, in a game, in
282
00:06:06,344 --> 00:06:07,414
a gaming application,
283
00:06:07,414 --> 00:06:09,184
a particular user, a
284
00:06:09,184 --> 00:06:11,094
session ID, anything
285
00:06:11,094 --> 00:06:11,784
that actually has that
286
00:06:11,814 --> 00:06:12,844
type of access as well.
287
00:06:14,564 --> 00:06:14,874
Right.
288
00:06:15,694 --> 00:06:16,454
And from a use case
289
00:06:16,454 --> 00:06:17,794
perspective, that is
290
00:06:17,824 --> 00:06:18,914
often observability
291
00:06:18,914 --> 00:06:20,729
data in like the
292
00:06:20,959 --> 00:06:21,989
infrastructure world.
293
00:06:22,239 --> 00:06:23,239
It is any kind of,
294
00:06:23,299 --> 00:06:24,189
you hinted at that,
295
00:06:24,199 --> 00:06:25,799
like IOT data, like
296
00:06:25,799 --> 00:06:27,049
device information,
297
00:06:27,079 --> 00:06:27,639
temperature,
298
00:06:27,639 --> 00:06:28,829
humidity, whatever.
299
00:06:30,139 --> 00:06:33,659
But it can basically
300
00:06:33,679 --> 00:06:35,209
be everything, anything
301
00:06:35,209 --> 00:06:36,759
that has like a time
302
00:06:36,759 --> 00:06:37,719
relation, I think.
303
00:06:38,189 --> 00:06:38,469
Yeah.
304
00:06:38,469 --> 00:06:39,569
And that's how I
305
00:06:39,569 --> 00:06:40,619
would explain it.
306
00:06:40,619 --> 00:06:42,149
We like to almost say
307
00:06:42,579 --> 00:06:44,119
all data is time series,
308
00:06:44,189 --> 00:06:45,559
because as you start
309
00:06:45,559 --> 00:06:46,459
squinting at it, I
310
00:06:46,459 --> 00:06:48,319
mean, I mentioned, you
311
00:06:48,319 --> 00:06:48,879
know, the traditional
312
00:06:48,919 --> 00:06:50,419
OLTP, which is your
313
00:06:50,439 --> 00:06:51,109
e commerce app.
314
00:06:51,289 --> 00:06:52,619
Well, if you actually
315
00:06:52,619 --> 00:06:53,849
look at that database,
316
00:06:53,869 --> 00:06:55,549
where over time, if your
317
00:06:55,549 --> 00:06:56,539
business is successful,
318
00:06:56,539 --> 00:06:57,929
where is most of your
319
00:06:57,929 --> 00:06:58,639
data going to be stored?
320
00:06:58,639 --> 00:06:59,009
It's something like
321
00:06:59,009 --> 00:07:00,379
your orders table, which
322
00:07:00,379 --> 00:07:01,419
is keeping a record
323
00:07:01,429 --> 00:07:04,119
of not just every SKU,
324
00:07:04,399 --> 00:07:05,449
not just every item you
325
00:07:05,449 --> 00:07:06,399
have, but how frequently
326
00:07:06,419 --> 00:07:07,009
you sold that.
327
00:07:07,009 --> 00:07:07,449
Well, what is
328
00:07:07,449 --> 00:07:08,319
an orders table?
329
00:07:08,459 --> 00:07:09,329
An orders table is
330
00:07:09,329 --> 00:07:10,929
basically a log of
331
00:07:10,999 --> 00:07:12,279
events with a timestamp.
332
00:07:12,279 --> 00:07:12,919
And you might look
333
00:07:12,919 --> 00:07:13,819
over the time and see
334
00:07:13,819 --> 00:07:14,549
how your sales has
335
00:07:14,549 --> 00:07:17,069
changed across a time,
336
00:07:17,119 --> 00:07:18,049
across a particular
337
00:07:18,049 --> 00:07:19,639
order, across a region.
338
00:07:19,859 --> 00:07:21,539
This is all what
339
00:07:21,539 --> 00:07:22,549
we think of as time
340
00:07:22,549 --> 00:07:23,969
series or, event data.
341
00:07:24,169 --> 00:07:25,599
And so, yeah, so you
342
00:07:25,599 --> 00:07:26,659
might think of it as
343
00:07:26,739 --> 00:07:27,319
there are certainly
344
00:07:27,319 --> 00:07:28,199
been use cases in
345
00:07:28,199 --> 00:07:29,689
observability, but in
346
00:07:29,719 --> 00:07:31,469
IOT, in manufacturing,
347
00:07:31,479 --> 00:07:33,259
in energy, in gaming,
348
00:07:33,269 --> 00:07:34,489
in product analytics,
349
00:07:34,519 --> 00:07:35,739
in music analytics,
350
00:07:36,519 --> 00:07:37,659
anything where you ever
351
00:07:37,659 --> 00:07:38,629
would build a dashboard
352
00:07:38,629 --> 00:07:39,639
on top of your data,
353
00:07:39,979 --> 00:07:41,409
I think is a good,
354
00:07:41,489 --> 00:07:43,039
or analysis over your
355
00:07:43,039 --> 00:07:43,759
data, I think is a
356
00:07:43,759 --> 00:07:44,839
good use for something
357
00:07:44,839 --> 00:07:45,189
like timescale.
358
00:07:46,604 --> 00:07:47,594
Yeah, I agree.
359
00:07:47,844 --> 00:07:49,644
And I like the, like
360
00:07:49,694 --> 00:07:51,304
order invoice table
361
00:07:51,324 --> 00:07:52,274
kind of stuff, because
362
00:07:52,814 --> 00:07:53,614
that is something
363
00:07:53,614 --> 00:07:55,004
people really do not
364
00:07:55,014 --> 00:07:56,374
consider as time series.
365
00:07:56,394 --> 00:07:57,024
But as you said,
366
00:07:57,034 --> 00:07:57,764
when you want to
367
00:07:57,764 --> 00:07:58,554
build a dashboard
368
00:07:58,554 --> 00:07:59,304
on top of that, it
369
00:07:59,304 --> 00:08:00,074
makes total sense.
370
00:08:00,094 --> 00:08:01,044
You want to understand
371
00:08:01,044 --> 00:08:02,204
like, what is the
372
00:08:02,204 --> 00:08:04,154
average order value?
373
00:08:04,154 --> 00:08:05,024
What is like the
374
00:08:05,024 --> 00:08:05,684
lifetime value
375
00:08:05,684 --> 00:08:06,384
of a customer?
376
00:08:07,074 --> 00:08:07,994
The average lifetime
377
00:08:07,994 --> 00:08:08,564
value of a customer.
378
00:08:08,574 --> 00:08:09,484
All that kind of stuff.
379
00:08:10,014 --> 00:08:11,484
And hopefully your
380
00:08:11,494 --> 00:08:12,534
business is successful
381
00:08:12,534 --> 00:08:13,714
enough that this table
382
00:08:13,714 --> 00:08:15,559
grows quite a bit.
383
00:08:16,199 --> 00:08:17,849
If not, you're probably
384
00:08:17,859 --> 00:08:18,749
in the wrong business.
385
00:08:19,399 --> 00:08:19,629
Right.
386
00:08:19,629 --> 00:08:20,449
And if you even think
387
00:08:20,719 --> 00:08:21,669
of the questions you
388
00:08:21,669 --> 00:08:23,479
ask, you know, in your,
389
00:08:23,629 --> 00:08:25,549
if you have a website
390
00:08:25,569 --> 00:08:27,259
or a web console that
391
00:08:27,259 --> 00:08:28,019
you have your users
392
00:08:28,089 --> 00:08:29,459
log into, typically
393
00:08:29,459 --> 00:08:30,099
you'll show them their
394
00:08:30,099 --> 00:08:31,249
orders in chronologic
395
00:08:31,249 --> 00:08:32,159
order, chronologic
396
00:08:32,159 --> 00:08:33,249
reverse order, right?
397
00:08:33,249 --> 00:08:34,679
Which is again, the
398
00:08:34,679 --> 00:08:35,589
recent stuff gets
399
00:08:35,589 --> 00:08:36,759
shown more frequently.
400
00:08:37,509 --> 00:08:38,139
Or you might allow
401
00:08:38,139 --> 00:08:39,299
them to define, you
402
00:08:39,299 --> 00:08:40,009
know, tell me all
403
00:08:40,019 --> 00:08:41,119
the orders I placed
404
00:08:41,379 --> 00:08:42,309
during this month.
405
00:08:42,489 --> 00:08:45,699
Again, it's, have your
406
00:08:45,719 --> 00:08:46,849
history of all data,
407
00:08:46,979 --> 00:08:47,839
but it narrows into a
408
00:08:47,859 --> 00:08:48,879
particular user or a
409
00:08:48,879 --> 00:08:49,899
particular time range.
410
00:08:50,089 --> 00:08:50,879
That is the type of
411
00:08:50,879 --> 00:08:53,469
things where the type
412
00:08:53,469 --> 00:08:54,699
of capabilities we build
413
00:08:54,699 --> 00:08:56,009
the infrastructure in
414
00:08:56,009 --> 00:08:57,839
timescale maps very well
415
00:08:57,839 --> 00:09:00,449
to efficient, scalable,
416
00:09:00,450 --> 00:09:00,589
performing queries.
417
00:09:02,249 --> 00:09:03,829
So, the next question
418
00:09:03,829 --> 00:09:05,219
would be like, why do
419
00:09:05,219 --> 00:09:06,769
this in an extension?
420
00:09:06,769 --> 00:09:07,569
I mean, Postgres
421
00:09:07,609 --> 00:09:10,469
gives me basically
422
00:09:10,489 --> 00:09:11,169
everything I
423
00:09:11,189 --> 00:09:12,049
need to do that.
424
00:09:12,559 --> 00:09:14,989
And in the worst case
425
00:09:14,989 --> 00:09:15,919
I can partition data,
426
00:09:15,969 --> 00:09:16,689
but why would I do
427
00:09:16,689 --> 00:09:17,769
that with an extension?
428
00:09:19,089 --> 00:09:19,359
Yeah.
429
00:09:19,359 --> 00:09:22,459
So the way I like
430
00:09:22,459 --> 00:09:23,249
to think of is what
431
00:09:23,249 --> 00:09:24,349
timescale has often
432
00:09:24,349 --> 00:09:25,529
done is has made
433
00:09:25,879 --> 00:09:27,099
Postgres is performance
434
00:09:27,109 --> 00:09:28,999
scale for, you know,
435
00:09:29,059 --> 00:09:30,059
particular app for a
436
00:09:30,059 --> 00:09:31,139
particular use cases.
437
00:09:31,569 --> 00:09:33,539
And it is true that
438
00:09:33,539 --> 00:09:34,539
like, obviously SQL
439
00:09:34,539 --> 00:09:35,159
is super powerful
440
00:09:35,159 --> 00:09:35,719
and Postgres is
441
00:09:35,719 --> 00:09:36,579
super powerful.
442
00:09:36,659 --> 00:09:38,169
You could represent this
443
00:09:38,179 --> 00:09:39,169
problem in Postgres.
444
00:09:39,569 --> 00:09:41,059
In fact, the biggest
445
00:09:41,059 --> 00:09:42,129
source of users of
446
00:09:42,129 --> 00:09:43,129
timescale is people
447
00:09:43,129 --> 00:09:44,319
who started on Postgres
448
00:09:44,839 --> 00:09:45,779
and realized that
449
00:09:45,789 --> 00:09:46,619
they need something
450
00:09:46,619 --> 00:09:47,219
else to take it to
451
00:09:47,219 --> 00:09:48,879
the next level, either
452
00:09:48,889 --> 00:09:50,109
because of scalability,
453
00:09:50,109 --> 00:09:51,679
performance, cost
454
00:09:51,679 --> 00:09:53,659
effectiveness or, you
455
00:09:53,659 --> 00:09:55,819
know, we enable a lot
456
00:09:55,859 --> 00:09:56,829
ease of use because of
457
00:09:56,829 --> 00:09:57,549
kind of the additional
458
00:09:57,549 --> 00:09:58,329
functionality built
459
00:09:58,329 --> 00:09:58,959
on top of that.
460
00:09:59,539 --> 00:10:01,459
You know, in general,
461
00:10:01,459 --> 00:10:03,049
why do we ever have many
462
00:10:03,049 --> 00:10:04,539
databases is because
463
00:10:04,929 --> 00:10:05,719
what you can do under
464
00:10:05,719 --> 00:10:06,449
the covers is you
465
00:10:06,449 --> 00:10:08,459
build data structures,
466
00:10:08,469 --> 00:10:10,939
optimizations,
467
00:10:11,289 --> 00:10:12,209
other things that
468
00:10:12,209 --> 00:10:13,489
basically make it
469
00:10:13,649 --> 00:10:15,189
both easier and more
470
00:10:15,189 --> 00:10:16,279
performant to manage.
471
00:10:16,629 --> 00:10:17,429
You know, I could
472
00:10:17,429 --> 00:10:19,059
talk about, you know,
473
00:10:19,069 --> 00:10:20,984
various technological
474
00:10:20,994 --> 00:10:21,954
things that we built,
475
00:10:22,404 --> 00:10:23,984
but, you know, that's
476
00:10:24,054 --> 00:10:24,914
basically the reason,
477
00:10:24,914 --> 00:10:26,634
you know, it, Postgres
478
00:10:26,644 --> 00:10:27,434
works great up to
479
00:10:27,434 --> 00:10:28,214
a certain scale and
480
00:10:28,214 --> 00:10:29,074
then it stops working.
481
00:10:29,444 --> 00:10:31,774
And so what you find
482
00:10:31,784 --> 00:10:33,024
is that users have the
483
00:10:33,024 --> 00:10:34,194
option either to like,
484
00:10:35,104 --> 00:10:36,674
try to get like a very
485
00:10:36,844 --> 00:10:38,714
niche database, move
486
00:10:38,724 --> 00:10:39,964
off Postgres, go to
487
00:10:39,964 --> 00:10:40,594
something they're less
488
00:10:40,594 --> 00:10:41,244
familiar with, their
489
00:10:41,244 --> 00:10:42,054
team's less familiar
490
00:10:42,054 --> 00:10:42,794
with, there's not as
491
00:10:42,794 --> 00:10:43,904
good enough ecosystem
492
00:10:43,904 --> 00:10:45,544
for it, or they could
493
00:10:45,544 --> 00:10:46,714
just, you know, adopt
494
00:10:46,754 --> 00:10:47,634
timescale and basically
495
00:10:47,634 --> 00:10:48,694
keep everything they
496
00:10:49,079 --> 00:10:49,869
already know and love
497
00:10:49,869 --> 00:10:50,619
and then get these
498
00:10:50,769 --> 00:10:51,559
kind of superpowers
499
00:10:51,559 --> 00:10:51,999
on top of it.
500
00:10:53,279 --> 00:10:53,639
Right.
501
00:10:53,679 --> 00:10:54,839
So you mentioned
502
00:10:54,849 --> 00:10:55,909
superpowers.
503
00:10:55,909 --> 00:10:56,799
Maybe, maybe just
504
00:10:56,799 --> 00:10:57,499
give one or two
505
00:10:57,499 --> 00:10:59,199
examples, because
506
00:10:59,199 --> 00:11:00,169
I know there's like
507
00:11:00,169 --> 00:11:01,279
super cool features.
508
00:11:03,319 --> 00:11:04,979
So stop talking black
509
00:11:04,979 --> 00:11:07,249
magic and give the
510
00:11:07,249 --> 00:11:08,359
engineers something to
511
00:11:08,489 --> 00:11:09,399
sink their teeth into.
512
00:11:10,459 --> 00:11:11,219
So one of the really
513
00:11:11,219 --> 00:11:11,889
interesting things
514
00:11:11,919 --> 00:11:14,359
is that Timescale
515
00:11:14,359 --> 00:11:16,704
has a very, what
516
00:11:16,704 --> 00:11:17,354
I'd call interesting
517
00:11:17,354 --> 00:11:18,254
data life cycle.
518
00:11:18,654 --> 00:11:20,914
And let me get into it.
519
00:11:21,154 --> 00:11:22,224
You mentioned briefly
520
00:11:22,224 --> 00:11:23,424
before partitioning,
521
00:11:24,004 --> 00:11:25,104
you know, timescale
522
00:11:25,124 --> 00:11:27,044
has these things, which
523
00:11:27,044 --> 00:11:28,174
we call hyper tables
524
00:11:28,174 --> 00:11:29,134
rather than tables.
525
00:11:29,644 --> 00:11:30,724
And one of the
526
00:11:30,734 --> 00:11:31,964
big differences is
527
00:11:31,974 --> 00:11:33,304
they basically do
528
00:11:33,305 --> 00:11:34,334
automated partitioning
529
00:11:34,334 --> 00:11:34,984
under the covers.
530
00:11:34,984 --> 00:11:35,714
You kind of
531
00:11:35,714 --> 00:11:36,624
create a policy.
532
00:11:36,624 --> 00:11:38,084
You might say, what
533
00:11:38,084 --> 00:11:39,554
roughly is a time period
534
00:11:39,554 --> 00:11:40,264
of which you want to
535
00:11:40,274 --> 00:11:41,144
partition the data?
536
00:11:41,174 --> 00:11:42,599
It could be a week,
537
00:11:42,609 --> 00:11:43,399
it could be a day.
538
00:11:45,359 --> 00:11:46,219
We have high, you
539
00:11:46,219 --> 00:11:47,689
know, really high
540
00:11:47,689 --> 00:11:48,469
end services that do
541
00:11:48,469 --> 00:11:49,369
it every 10 minutes.
542
00:11:50,199 --> 00:11:50,749
And you just set
543
00:11:50,749 --> 00:11:51,409
it and forget it.
544
00:11:51,409 --> 00:11:52,439
And it could be modified
545
00:11:52,439 --> 00:11:53,939
over time and adapt as
546
00:11:53,939 --> 00:11:55,809
your data volume scale.
547
00:11:56,359 --> 00:11:57,819
But under the covers,
548
00:11:58,039 --> 00:11:58,929
what we're doing and
549
00:11:59,289 --> 00:11:59,889
a bunch of things,
550
00:11:59,889 --> 00:12:00,549
but one thing I want
551
00:12:00,549 --> 00:12:01,029
to talk about with
552
00:12:01,039 --> 00:12:02,789
data lifecycle is
553
00:12:02,789 --> 00:12:04,354
we basically kind of
554
00:12:04,354 --> 00:12:05,854
change the formatting
555
00:12:05,854 --> 00:12:06,904
of your data as it
556
00:12:06,904 --> 00:12:08,554
ages because your needs
557
00:12:08,554 --> 00:12:09,604
will often change.
558
00:12:09,839 --> 00:12:10,864
So for the most recent
559
00:12:10,864 --> 00:12:11,704
data, we store that
560
00:12:11,704 --> 00:12:12,784
in row based form,
561
00:12:13,024 --> 00:12:14,434
and that becomes much
562
00:12:14,434 --> 00:12:15,424
more efficient than to
563
00:12:15,424 --> 00:12:16,954
do high ingest rates,
564
00:12:16,984 --> 00:12:17,524
'cause usually
565
00:12:17,524 --> 00:12:18,424
data comes in as an
566
00:12:18,424 --> 00:12:19,594
individual row and
567
00:12:19,594 --> 00:12:20,524
you can kind of insert
568
00:12:20,524 --> 00:12:21,304
it row after row,
569
00:12:21,304 --> 00:12:22,174
after row after row.
570
00:12:22,794 --> 00:12:23,904
And then as it gets
571
00:12:23,904 --> 00:12:25,464
a little bit older,
572
00:12:25,944 --> 00:12:27,134
we basically have,
573
00:12:28,044 --> 00:12:29,734
the engine underneath
574
00:12:29,754 --> 00:12:30,774
the covers would
575
00:12:30,774 --> 00:12:31,974
automatically change
576
00:12:31,974 --> 00:12:33,204
it to a compressed
577
00:12:33,204 --> 00:12:34,114
columnar format.
578
00:12:34,724 --> 00:12:36,804
And so, compression is
579
00:12:36,804 --> 00:12:38,034
great for cost savings.
580
00:12:38,439 --> 00:12:40,369
In production, we see on
581
00:12:40,369 --> 00:12:41,009
average something like
582
00:12:41,019 --> 00:12:44,669
90 to 95 percent storage
583
00:12:44,669 --> 00:12:45,899
reduction once people
584
00:12:45,899 --> 00:12:46,819
adopt our columnar.
585
00:12:46,829 --> 00:12:47,369
We actually use
586
00:12:47,369 --> 00:12:48,559
different algorithms
587
00:12:49,319 --> 00:12:50,469
per column based on the
588
00:12:50,469 --> 00:12:51,749
data type automatically.
589
00:12:52,819 --> 00:12:53,719
And then columnar
590
00:12:53,719 --> 00:12:54,359
means that I talked
591
00:12:54,359 --> 00:12:55,439
about scans before,
592
00:12:55,659 --> 00:12:56,889
it becomes much more
593
00:12:56,909 --> 00:12:59,269
efficient then to do
594
00:12:59,539 --> 00:13:01,624
kind of longer queries
595
00:13:01,674 --> 00:13:03,594
over time, particularly
596
00:13:03,594 --> 00:13:04,374
when you're interested
597
00:13:05,094 --> 00:13:06,324
in like primary keys
598
00:13:06,324 --> 00:13:07,054
where you want to
599
00:13:07,054 --> 00:13:08,714
scan over the user or
600
00:13:08,714 --> 00:13:09,654
when you want to ask
601
00:13:09,654 --> 00:13:10,644
questions about certain
602
00:13:10,644 --> 00:13:11,484
columns as opposed
603
00:13:11,484 --> 00:13:12,374
to all the columns,
604
00:13:12,374 --> 00:13:12,984
let's say, that might
605
00:13:12,984 --> 00:13:13,544
be in the database.
606
00:13:14,304 --> 00:13:15,414
And then even third on
607
00:13:15,414 --> 00:13:16,434
our cloud, we offered
608
00:13:16,434 --> 00:13:17,314
a tiered storage
609
00:13:17,334 --> 00:13:18,484
now, which is when
610
00:13:18,484 --> 00:13:19,744
we actually store the
611
00:13:19,744 --> 00:13:21,324
data from, you know,
612
00:13:21,324 --> 00:13:22,814
it starts in hot, high
613
00:13:22,814 --> 00:13:24,174
performance row format.
614
00:13:24,634 --> 00:13:25,434
To high performance
615
00:13:25,474 --> 00:13:27,334
columnar format, and now
616
00:13:27,334 --> 00:13:29,884
to tiered, warm storage.
617
00:13:29,904 --> 00:13:30,914
So this is kind of
618
00:13:30,914 --> 00:13:31,854
tiering it off to S3.
619
00:13:32,624 --> 00:13:33,184
So it becomes this
620
00:13:33,184 --> 00:13:35,284
bottomless store for
621
00:13:35,284 --> 00:13:36,904
data that, again, is
622
00:13:36,904 --> 00:13:38,344
transparently queried,
623
00:13:38,814 --> 00:13:40,134
but now provides
624
00:13:40,134 --> 00:13:40,744
this trade off for
625
00:13:40,744 --> 00:13:41,704
you as a developer.
626
00:13:42,004 --> 00:13:42,934
You know, your trade off
627
00:13:42,934 --> 00:13:44,984
between the performance
628
00:13:44,984 --> 00:13:45,814
you get from it versus
629
00:13:45,834 --> 00:13:46,674
the cost of, you
630
00:13:46,674 --> 00:13:47,664
know, how expensive
631
00:13:47,674 --> 00:13:48,584
the storage is.
632
00:13:48,584 --> 00:13:49,794
And again, you
633
00:13:49,804 --> 00:13:50,684
create a hyper table.
634
00:13:50,684 --> 00:13:52,384
You set two policies for
635
00:13:52,774 --> 00:13:54,024
when you want to move
636
00:13:54,024 --> 00:13:54,854
something to columnar
637
00:13:54,854 --> 00:13:55,344
and when you want to
638
00:13:55,344 --> 00:13:56,194
move something to tiered
639
00:13:56,194 --> 00:13:57,504
storage and everything
640
00:13:57,504 --> 00:13:58,454
else is handled for you.
641
00:13:58,874 --> 00:13:59,844
So there's an example
642
00:13:59,844 --> 00:14:00,714
of like, obviously
643
00:14:00,724 --> 00:14:01,734
Postgres itself doesn't
644
00:14:01,734 --> 00:14:03,234
have columnar storage,
645
00:14:03,234 --> 00:14:05,014
doesn't do this tiering.
646
00:14:05,344 --> 00:14:06,614
There's a lot of query
647
00:14:06,614 --> 00:14:07,544
optimizations on top
648
00:14:07,544 --> 00:14:08,874
of it, which we use to
649
00:14:09,484 --> 00:14:10,704
select which portion
650
00:14:10,704 --> 00:14:12,844
of your data we query.
651
00:14:12,869 --> 00:14:13,419
We build a lot
652
00:14:13,419 --> 00:14:14,429
of small indexes.
653
00:14:14,429 --> 00:14:15,889
We build sparse indexes.
654
00:14:16,329 --> 00:14:16,899
There's a lot of
655
00:14:16,899 --> 00:14:17,629
this fancy stuff
656
00:14:17,629 --> 00:14:18,279
under the covers.
657
00:14:18,529 --> 00:14:19,389
Again, as a developer,
658
00:14:19,389 --> 00:14:19,919
you don't really think
659
00:14:19,929 --> 00:14:21,189
about that, kind of,
660
00:14:21,199 --> 00:14:22,129
we've done that for you.
661
00:14:23,769 --> 00:14:24,439
Right, right.
662
00:14:24,889 --> 00:14:27,059
And as a developer,
663
00:14:27,309 --> 00:14:28,479
I feel like I want to
664
00:14:28,489 --> 00:14:29,569
get started right now.
665
00:14:29,569 --> 00:14:30,279
So what is-
666
00:14:31,259 --> 00:14:31,629
how would I
667
00:14:31,629 --> 00:14:32,494
go about that?
668
00:14:33,054 --> 00:14:33,514
Yeah, so there's
669
00:14:33,514 --> 00:14:33,884
two ways.
670
00:14:33,894 --> 00:14:35,344
One is Timescale
671
00:14:35,344 --> 00:14:36,034
is open source.
672
00:14:36,054 --> 00:14:37,054
You could go to GitHub,
673
00:14:37,054 --> 00:14:37,534
you could download,
674
00:14:37,554 --> 00:14:38,734
we provide, you know,
675
00:14:38,734 --> 00:14:39,774
different installations
676
00:14:39,774 --> 00:14:40,744
that you could use.
677
00:14:40,954 --> 00:14:41,674
We also, in our
678
00:14:41,674 --> 00:14:43,024
businesses, we build a
679
00:14:43,074 --> 00:14:43,984
Timescale cloud, which
680
00:14:43,984 --> 00:14:44,864
is a managed service.
681
00:14:45,324 --> 00:14:45,974
And so, you know,
682
00:14:45,974 --> 00:14:46,964
you log in, go to
683
00:14:46,964 --> 00:14:48,044
timescale.com, click
684
00:14:48,044 --> 00:14:48,844
one button and you have
685
00:14:48,844 --> 00:14:50,044
a database running,
686
00:14:50,104 --> 00:14:50,634
you know, up and
687
00:14:50,634 --> 00:14:52,654
starting in two minutes.
688
00:14:53,414 --> 00:14:55,024
That takes, you know, I
689
00:14:55,084 --> 00:14:55,934
think I would describe
690
00:14:55,934 --> 00:14:56,904
our cloud in two ways.
691
00:14:56,914 --> 00:14:58,354
One is, it obviously
692
00:14:58,354 --> 00:14:59,404
takes care of all the
693
00:14:59,404 --> 00:15:00,694
operational complexity
694
00:15:00,734 --> 00:15:02,054
you normally have from
695
00:15:02,054 --> 00:15:03,784
operating Postgres,
696
00:15:03,884 --> 00:15:05,694
HA, replicas, backup
697
00:15:05,694 --> 00:15:07,154
restore, port and time
698
00:15:07,154 --> 00:15:08,834
recovery, upgrades,
699
00:15:09,144 --> 00:15:09,974
observability,
700
00:15:09,994 --> 00:15:11,584
monitoring, 24/7,
701
00:15:11,604 --> 00:15:12,484
all that stuff.
702
00:15:13,214 --> 00:15:16,074
But also it has, it is
703
00:15:16,484 --> 00:15:18,154
intentional that we know
704
00:15:18,154 --> 00:15:18,764
we're building these
705
00:15:18,764 --> 00:15:19,804
type of applications.
706
00:15:20,084 --> 00:15:21,004
So not only there
707
00:15:21,054 --> 00:15:21,934
are operational
708
00:15:21,934 --> 00:15:22,494
improvements.
709
00:15:22,864 --> 00:15:23,394
But there are also
710
00:15:23,394 --> 00:15:24,384
those like application
711
00:15:24,384 --> 00:15:25,114
level improvements.
712
00:15:25,204 --> 00:15:26,394
So these things
713
00:15:26,424 --> 00:15:27,594
like tiered storage,
714
00:15:27,594 --> 00:15:28,284
which you might have.
715
00:15:28,444 --> 00:15:29,254
You don't find this
716
00:15:29,264 --> 00:15:30,064
in something like,
717
00:15:30,084 --> 00:15:31,644
you know, RDS or
718
00:15:31,644 --> 00:15:32,254
something else.
719
00:15:32,354 --> 00:15:33,314
This is really built
720
00:15:33,314 --> 00:15:34,424
because we understand
721
00:15:34,424 --> 00:15:35,204
our problem domain
722
00:15:35,204 --> 00:15:36,294
and build a cloud
723
00:15:36,294 --> 00:15:37,414
product for it.
724
00:15:38,444 --> 00:15:38,804
Right.
725
00:15:39,094 --> 00:15:39,274
Right.
726
00:15:39,294 --> 00:15:40,664
And you said you
727
00:15:40,664 --> 00:15:42,784
can run it yourself.
728
00:15:43,454 --> 00:15:44,574
It's Apache licensed.
729
00:15:45,114 --> 00:15:46,394
Is there anything I need
730
00:15:46,394 --> 00:15:47,894
to be careful about?
731
00:15:47,984 --> 00:15:50,099
And like, how do
732
00:15:50,099 --> 00:15:51,009
I deploy that?
733
00:15:51,229 --> 00:15:51,889
Do I deploy it
734
00:15:51,889 --> 00:15:52,859
into Kubernetes?
735
00:15:52,859 --> 00:15:53,689
Does it run on
736
00:15:53,689 --> 00:15:55,539
Docker, like virtual
737
00:15:55,539 --> 00:15:56,419
machine or whatever?
738
00:15:57,179 --> 00:15:57,999
All of the above.
739
00:15:58,099 --> 00:16:01,069
You know, you could, I
740
00:16:01,069 --> 00:16:02,989
mean, software you can
741
00:16:02,999 --> 00:16:04,309
deploy in many places.
742
00:16:05,369 --> 00:16:06,069
We provide
743
00:16:06,089 --> 00:16:06,829
Docker images.
744
00:16:06,829 --> 00:16:08,959
We provide some RPMs
745
00:16:08,959 --> 00:16:09,899
that you could install
746
00:16:09,899 --> 00:16:10,749
into your thing.
747
00:16:11,589 --> 00:16:13,139
We ourselves use
748
00:16:13,139 --> 00:16:14,499
Kubernetes internally,
749
00:16:14,499 --> 00:16:15,149
and we know a lot
750
00:16:15,149 --> 00:16:18,059
of people, deploy.
751
00:16:18,439 --> 00:16:20,084
And we have a Helm
752
00:16:20,084 --> 00:16:20,784
chart, but a lot
753
00:16:20,784 --> 00:16:22,194
of people deploy
754
00:16:22,194 --> 00:16:23,094
it with existing
755
00:16:23,104 --> 00:16:24,934
Kubernetes operators.
756
00:16:25,124 --> 00:16:26,154
Kind of community
757
00:16:26,169 --> 00:16:26,679
ones built for
758
00:16:26,679 --> 00:16:27,449
Postgres, they work
759
00:16:27,449 --> 00:16:28,410
for Timescale as well.
760
00:16:29,990 --> 00:16:30,280
Right.
761
00:16:30,280 --> 00:16:31,659
You already hinted
762
00:16:31,669 --> 00:16:32,399
you're using
763
00:16:32,399 --> 00:16:34,009
Kubernetes internally.
764
00:16:34,439 --> 00:16:35,419
So let's switch to
765
00:16:35,419 --> 00:16:36,119
that because we're a
766
00:16:36,119 --> 00:16:37,939
Kubernetes podcast.
767
00:16:37,939 --> 00:16:39,799
And I love podcasts.
768
00:16:39,869 --> 00:16:41,019
So we can share about
769
00:16:41,029 --> 00:16:41,659
the infrastructure
770
00:16:41,659 --> 00:16:43,039
without I have to
771
00:16:43,039 --> 00:16:43,999
sign an NDA for the
772
00:16:43,999 --> 00:16:44,709
whole community.
773
00:16:45,499 --> 00:16:46,309
Sure, sure.
774
00:16:47,129 --> 00:16:47,639
So, you know,
775
00:16:47,639 --> 00:16:48,409
we're heavy users
776
00:16:48,409 --> 00:16:49,209
of Kubernetes.
777
00:16:49,219 --> 00:16:50,599
One of the things this
778
00:16:50,599 --> 00:16:52,819
allows us to do is, you
779
00:16:52,819 --> 00:16:55,169
know, operate at scale,
780
00:16:55,199 --> 00:16:57,849
where we have decoupled
781
00:16:57,869 --> 00:16:59,569
the problem of spinning
782
00:16:59,569 --> 00:17:01,949
up AWS instances, which,
783
00:17:02,079 --> 00:17:03,969
you know, often or other
784
00:17:03,969 --> 00:17:06,039
hyperscaler instances,
785
00:17:06,049 --> 00:17:06,959
which are often on the
786
00:17:06,959 --> 00:17:08,964
order of minutes from
787
00:17:09,044 --> 00:17:12,694
individual placements of
788
00:17:12,724 --> 00:17:13,864
containers and whatnot.
789
00:17:14,274 --> 00:17:16,514
You know, it's been-
790
00:17:16,514 --> 00:17:18,634
We've been using
791
00:17:18,634 --> 00:17:19,094
Kubernetes from
792
00:17:19,094 --> 00:17:19,534
the beginning.
793
00:17:19,534 --> 00:17:20,754
So I guess now since our
794
00:17:20,754 --> 00:17:22,854
cloud has been almost
795
00:17:22,854 --> 00:17:23,844
five years since we
796
00:17:23,844 --> 00:17:25,604
started building it,
797
00:17:26,504 --> 00:17:27,744
have obviously gone
798
00:17:27,744 --> 00:17:32,084
through the joys and the
799
00:17:32,084 --> 00:17:33,354
trials and tribulations
800
00:17:33,864 --> 00:17:34,794
of deploying
801
00:17:34,804 --> 00:17:36,234
Kubernetes at scale.
802
00:17:36,704 --> 00:17:37,794
One of the big things
803
00:17:37,794 --> 00:17:40,494
about timescale cloud is
804
00:17:40,494 --> 00:17:41,534
that we have decoupled
805
00:17:41,554 --> 00:17:42,544
compute and storage.
806
00:17:43,434 --> 00:17:45,944
So, customers, users
807
00:17:45,964 --> 00:17:47,684
can independently size
808
00:17:47,684 --> 00:17:49,084
their database and
809
00:17:49,494 --> 00:17:50,444
kind of at any time,
810
00:17:50,444 --> 00:17:51,274
change the sizing.
811
00:17:51,274 --> 00:17:51,964
So if you all of
812
00:17:51,964 --> 00:17:53,204
a sudden want to
813
00:17:53,204 --> 00:17:54,704
move from two CPUs
814
00:17:54,734 --> 00:17:56,664
to 16 CPUs, it's a
815
00:17:56,664 --> 00:17:57,334
click of the button.
816
00:17:57,774 --> 00:17:58,634
And that can be done
817
00:17:58,634 --> 00:18:00,244
with, in some cases
818
00:18:00,264 --> 00:18:01,784
in HA, no downtime.
819
00:18:01,784 --> 00:18:02,364
If you have non
820
00:18:02,364 --> 00:18:03,394
HA with, you know,
821
00:18:03,394 --> 00:18:03,844
typically something
822
00:18:03,874 --> 00:18:06,264
like 30 seconds of just
823
00:18:06,344 --> 00:18:07,684
replacing container,
824
00:18:08,164 --> 00:18:08,924
because it's decoupled
825
00:18:08,964 --> 00:18:09,764
from your storage.
826
00:18:10,204 --> 00:18:11,714
And then we manage
827
00:18:11,714 --> 00:18:13,014
storage as a completely
828
00:18:13,034 --> 00:18:14,264
separate tier that
829
00:18:14,264 --> 00:18:15,384
grows independently.
830
00:18:15,494 --> 00:18:16,144
One of the other
831
00:18:16,214 --> 00:18:17,134
interesting things
832
00:18:17,184 --> 00:18:19,684
about, again, enabled
833
00:18:19,684 --> 00:18:20,584
by Kubernetes, but
834
00:18:20,584 --> 00:18:21,204
also a lot of things
835
00:18:21,204 --> 00:18:22,314
we do ourselves is
836
00:18:22,314 --> 00:18:24,009
we, you know, normally
837
00:18:24,009 --> 00:18:24,329
when we think of
838
00:18:24,339 --> 00:18:25,179
databases, you think
839
00:18:25,509 --> 00:18:26,739
of, hard provisioning
840
00:18:26,929 --> 00:18:27,449
your storage.
841
00:18:27,449 --> 00:18:27,989
And you need to
842
00:18:28,249 --> 00:18:28,989
provision a disk.
843
00:18:29,009 --> 00:18:30,129
I want to provision
844
00:18:30,499 --> 00:18:31,299
a hundred gigabytes
845
00:18:31,309 --> 00:18:32,969
of storage or a
846
00:18:33,009 --> 00:18:33,889
terabyte of storage
847
00:18:33,889 --> 00:18:34,639
as the case may be.
848
00:18:35,069 --> 00:18:36,929
On our cloud, we
849
00:18:37,049 --> 00:18:38,159
hide all of that
850
00:18:38,199 --> 00:18:39,429
complexity from users
851
00:18:39,459 --> 00:18:41,319
and users purely have
852
00:18:41,329 --> 00:18:43,019
usage based storage.
853
00:18:43,039 --> 00:18:43,849
So what that means is
854
00:18:43,849 --> 00:18:44,769
they never think about
855
00:18:44,779 --> 00:18:45,639
allocating storage.
856
00:18:46,139 --> 00:18:46,679
They just start
857
00:18:46,679 --> 00:18:47,729
storing data with it.
858
00:18:48,129 --> 00:18:50,759
It scales as they need.
859
00:18:50,779 --> 00:18:52,009
We manage all that in
860
00:18:52,009 --> 00:18:53,509
the backend and they pay
861
00:18:53,509 --> 00:18:54,439
for only what they use.
862
00:18:54,699 --> 00:18:55,789
So if they're using
863
00:18:56,229 --> 00:18:58,819
496 gigabytes, that's
864
00:18:58,819 --> 00:18:59,609
how much they pay for.
865
00:18:59,609 --> 00:19:00,169
And if they turn
866
00:19:00,169 --> 00:19:00,479
on something like
867
00:19:00,489 --> 00:19:01,149
compression and
868
00:19:01,149 --> 00:19:02,329
it drops down by
869
00:19:02,599 --> 00:19:03,349
half their storage
870
00:19:03,380 --> 00:19:04,009
consumption, which
871
00:19:04,009 --> 00:19:05,239
is what often happens
872
00:19:05,239 --> 00:19:05,834
with our customers,
873
00:19:05,834 --> 00:19:06,969
they just pay for half.
874
00:19:07,369 --> 00:19:08,629
And so they kind of,
875
00:19:09,369 --> 00:19:10,279
we've made it easier
876
00:19:10,279 --> 00:19:10,809
and have allowed
877
00:19:10,809 --> 00:19:11,469
our users not to
878
00:19:11,469 --> 00:19:12,339
really think about
879
00:19:13,169 --> 00:19:14,189
managing those things.
880
00:19:15,429 --> 00:19:16,709
I think you mentioned an
881
00:19:16,709 --> 00:19:17,769
important thing and it
882
00:19:17,769 --> 00:19:18,909
was basically one of the
883
00:19:18,909 --> 00:19:20,369
questions I would have
884
00:19:20,389 --> 00:19:22,119
asked anyways, like when
885
00:19:22,119 --> 00:19:23,079
you have compression,
886
00:19:24,319 --> 00:19:25,859
you do not calculate
887
00:19:25,889 --> 00:19:26,439
the uncompressed
888
00:19:26,449 --> 00:19:28,039
storage, if I understood
889
00:19:28,039 --> 00:19:28,649
that correctly.
890
00:19:28,649 --> 00:19:30,959
But, you're calculating
891
00:19:31,009 --> 00:19:32,679
the actual storage uses.
892
00:19:32,689 --> 00:19:34,209
So if I have like a
893
00:19:34,209 --> 00:19:35,179
90 percent compression
894
00:19:35,179 --> 00:19:35,949
ratio, that means
895
00:19:35,949 --> 00:19:37,519
I'm paying like for
896
00:19:37,579 --> 00:19:38,879
10 percent of the
897
00:19:38,879 --> 00:19:39,789
actual data stored.
898
00:19:40,869 --> 00:19:41,889
Yeah, this is one big
899
00:19:41,899 --> 00:19:43,309
way, where in many
900
00:19:43,309 --> 00:19:45,079
cases, timescale turns
901
00:19:45,079 --> 00:19:46,229
out to be cheaper.
902
00:19:46,269 --> 00:19:47,234
Not only more scalable
903
00:19:47,234 --> 00:19:48,699
and performant, but can
904
00:19:48,699 --> 00:19:51,159
be cheaper than even
905
00:19:51,159 --> 00:19:51,989
something like using
906
00:19:52,029 --> 00:19:54,689
RDS Aurora is because,
907
00:19:55,599 --> 00:19:56,489
you know, we'll charge
908
00:19:56,489 --> 00:19:57,459
you for your storage.
909
00:19:58,229 --> 00:20:00,759
And so maybe on a per
910
00:20:00,769 --> 00:20:01,909
gigabyte of storage,
911
00:20:01,939 --> 00:20:03,189
we are charging more
912
00:20:03,219 --> 00:20:04,839
than RDS Aurora.
913
00:20:05,339 --> 00:20:06,859
But if you're only using
914
00:20:06,869 --> 00:20:08,279
one tenth of the size.
915
00:20:08,764 --> 00:20:09,664
You know, it obviously
916
00:20:09,674 --> 00:20:11,134
translates to savings.
917
00:20:11,144 --> 00:20:12,404
Not only again,
918
00:20:12,434 --> 00:20:14,474
operational and
919
00:20:14,474 --> 00:20:15,324
operational, some
920
00:20:16,264 --> 00:20:17,274
improvements, you know.
921
00:20:17,274 --> 00:20:20,084
We regularly operate
922
00:20:20,094 --> 00:20:21,564
with customer databases
923
00:20:21,564 --> 00:20:22,674
who are storing many
924
00:20:22,684 --> 00:20:25,314
terabytes of data and
925
00:20:25,374 --> 00:20:28,164
Postgres, you know, has-
926
00:20:28,854 --> 00:20:29,414
starts getting
927
00:20:29,439 --> 00:20:30,619
challenges at
928
00:20:30,619 --> 00:20:31,229
that scale.
929
00:20:31,969 --> 00:20:33,629
Not, you know,
930
00:20:33,629 --> 00:20:34,389
storage on disk and
931
00:20:34,409 --> 00:20:35,839
querying it, but the
932
00:20:35,839 --> 00:20:36,969
operational size.
933
00:20:37,509 --> 00:20:38,979
Try to take a backup
934
00:20:38,979 --> 00:20:40,139
and then restore from
935
00:20:40,139 --> 00:20:41,239
a, you know, try to
936
00:20:41,239 --> 00:20:42,839
use pgDumpRestore
937
00:20:42,839 --> 00:20:45,349
on a 10 terabyte
938
00:20:45,349 --> 00:20:46,609
disk and, you know,
939
00:20:46,969 --> 00:20:47,989
it's not very happy.
940
00:20:50,039 --> 00:20:51,029
Even if you use it in
941
00:20:51,029 --> 00:20:53,139
a binary mode, it will
942
00:20:53,159 --> 00:20:54,239
yeah, as you said, it's
943
00:20:54,239 --> 00:20:55,039
not going to be happy.
944
00:20:56,579 --> 00:20:58,739
So you said you're
945
00:20:58,759 --> 00:20:59,739
running on Kubernetes
946
00:20:59,739 --> 00:21:01,299
and you're hardcore
947
00:21:01,299 --> 00:21:02,899
Kubernetes users.
948
00:21:03,839 --> 00:21:05,914
So, we all know
949
00:21:05,934 --> 00:21:06,994
running a database in
950
00:21:06,994 --> 00:21:08,344
Kubernetes isn't as
951
00:21:08,344 --> 00:21:09,304
easy as it could be.
952
00:21:09,424 --> 00:21:10,154
So what do you think
953
00:21:10,154 --> 00:21:11,194
is like the biggest
954
00:21:11,384 --> 00:21:12,334
issue or the biggest
955
00:21:13,924 --> 00:21:15,434
like problem right
956
00:21:15,434 --> 00:21:16,984
now, running it at
957
00:21:16,984 --> 00:21:18,004
scale, making sure
958
00:21:18,004 --> 00:21:20,414
it's performance is
959
00:21:20,454 --> 00:21:22,064
on point and you think
960
00:21:22,134 --> 00:21:23,364
like stuff like noisy
961
00:21:23,364 --> 00:21:24,704
neighbor and, whatever
962
00:21:24,704 --> 00:21:25,324
you can come up with.
963
00:21:25,674 --> 00:21:26,244
Well, what do you've
964
00:21:26,244 --> 00:21:28,054
seen in real world?
965
00:21:30,514 --> 00:21:32,344
Yeah, I think there's a
966
00:21:32,374 --> 00:21:34,804
couple things going on.
967
00:21:34,804 --> 00:21:37,514
One is we,
968
00:21:41,094 --> 00:21:42,614
you know, we, the,
969
00:21:42,954 --> 00:21:47,204
some of the OS level
970
00:21:48,514 --> 00:21:49,874
performance isolation
971
00:21:49,894 --> 00:21:50,974
between instances
972
00:21:50,974 --> 00:21:51,764
we actually think
973
00:21:51,764 --> 00:21:53,014
works quite well.
974
00:21:53,574 --> 00:21:55,304
And we found
975
00:21:55,304 --> 00:21:57,459
that at least at
976
00:21:57,459 --> 00:21:58,509
that level, the-
977
00:21:58,559 --> 00:21:59,779
on the compute side,
978
00:22:00,119 --> 00:22:02,019
we have not run
979
00:22:02,019 --> 00:22:05,039
into, you know,
980
00:22:05,509 --> 00:22:06,079
it has actually
981
00:22:06,079 --> 00:22:06,989
worked out quite well.
982
00:22:07,429 --> 00:22:08,489
One of the big things
983
00:22:08,489 --> 00:22:11,089
that we don't have is
984
00:22:11,099 --> 00:22:12,399
we actually have storage
985
00:22:12,459 --> 00:22:14,270
isolation between users.
986
00:22:14,669 --> 00:22:15,589
So we've actually
987
00:22:15,619 --> 00:22:18,294
seen most of the, when
988
00:22:18,294 --> 00:22:19,324
people run into like
989
00:22:19,334 --> 00:22:20,704
noisy, when people
990
00:22:21,164 --> 00:22:22,234
have concerns about
991
00:22:22,234 --> 00:22:23,484
noisy neighbors, it
992
00:22:23,534 --> 00:22:26,274
often relates to, well,
993
00:22:26,464 --> 00:22:27,444
one of two things.
994
00:22:27,444 --> 00:22:30,684
One is, the fact that
995
00:22:31,084 --> 00:22:32,234
some architectures
996
00:22:32,244 --> 00:22:33,874
have shared storage
997
00:22:33,904 --> 00:22:34,834
backends that doesn't
998
00:22:34,834 --> 00:22:35,634
have actually good
999
00:22:35,634 --> 00:22:36,604
performance isolation
1000
00:22:36,604 --> 00:22:37,624
between customers.
1001
00:22:38,474 --> 00:22:40,424
And they don't
1002
00:22:40,434 --> 00:22:42,714
have the ability to
1003
00:22:43,134 --> 00:22:46,294
basically manage IOPS
1004
00:22:46,294 --> 00:22:47,004
and bandwidth on a
1005
00:22:47,004 --> 00:22:47,894
per customer basis.
1006
00:22:48,459 --> 00:22:49,049
And that is something
1007
00:22:49,049 --> 00:22:49,679
that we actually do
1008
00:22:49,679 --> 00:22:52,759
in the cloud, that we
1009
00:22:53,009 --> 00:22:54,369
also have the ability
1010
00:22:54,369 --> 00:22:55,689
to not only do we have
1011
00:22:55,779 --> 00:22:58,839
of isolated storage
1012
00:22:58,839 --> 00:22:59,709
per user storage
1013
00:22:59,709 --> 00:23:01,009
capacity, but we
1014
00:23:01,009 --> 00:23:02,279
actually can provision
1015
00:23:02,329 --> 00:23:03,659
IOPS and bandwidth on
1016
00:23:03,659 --> 00:23:05,259
a per tenant basis.
1017
00:23:05,989 --> 00:23:07,259
And what we naturally
1018
00:23:07,259 --> 00:23:09,319
do is we actually scale
1019
00:23:09,359 --> 00:23:10,859
IOPS and bandwidth with
1020
00:23:10,859 --> 00:23:12,079
your storage capacity.
1021
00:23:12,349 --> 00:23:13,619
So when you sign up
1022
00:23:13,619 --> 00:23:14,309
without doing anything
1023
00:23:14,309 --> 00:23:15,669
else, we start you on
1024
00:23:15,669 --> 00:23:16,779
a lower level and then
1025
00:23:16,779 --> 00:23:18,349
we scale it as your-
1026
00:23:19,619 --> 00:23:20,789
as your storage
1027
00:23:20,804 --> 00:23:21,774
scales itself.
1028
00:23:22,094 --> 00:23:23,024
But we also have the
1029
00:23:23,034 --> 00:23:24,204
ability to boost it.
1030
00:23:24,264 --> 00:23:25,764
So we have this notion
1031
00:23:25,764 --> 00:23:27,154
of which kind of we
1032
00:23:27,154 --> 00:23:28,064
internally called IO
1033
00:23:28,074 --> 00:23:28,824
boost, where we have
1034
00:23:28,824 --> 00:23:29,464
the ability to kind of
1035
00:23:29,474 --> 00:23:32,004
max out on a certain
1036
00:23:32,084 --> 00:23:33,564
customer basis, kind
1037
00:23:33,564 --> 00:23:34,814
of IOPS and bandwidth.
1038
00:23:35,234 --> 00:23:35,884
Obviously it costs
1039
00:23:35,884 --> 00:23:36,794
some extra to us.
1040
00:23:36,814 --> 00:23:38,484
We, you know, we pass
1041
00:23:38,484 --> 00:23:39,184
on some of that cost
1042
00:23:39,544 --> 00:23:40,474
to our customers.
1043
00:23:40,814 --> 00:23:41,384
But that actually
1044
00:23:41,384 --> 00:23:43,094
allows a user to kind
1045
00:23:43,094 --> 00:23:44,704
of start nicely and
1046
00:23:44,704 --> 00:23:45,744
then scale as needed.
1047
00:23:46,074 --> 00:23:47,794
You know, I think the
1048
00:23:47,824 --> 00:23:48,744
other thing I would
1049
00:23:48,754 --> 00:23:50,234
generally say with
1050
00:23:50,664 --> 00:23:52,954
Kubernetes is, you're
1051
00:23:52,954 --> 00:23:56,054
right in that it you
1052
00:23:56,054 --> 00:23:56,724
know, some of its
1053
00:23:56,724 --> 00:23:57,684
early promises are
1054
00:23:57,684 --> 00:23:58,724
meant for like these
1055
00:23:58,934 --> 00:24:00,144
stateless tiers of
1056
00:24:00,144 --> 00:24:01,784
horizontal nodes where
1057
00:24:01,814 --> 00:24:02,704
you don't actually
1058
00:24:02,724 --> 00:24:03,484
ever have to think
1059
00:24:03,494 --> 00:24:04,784
about the instances.
1060
00:24:04,784 --> 00:24:06,494
They're all independent.
1061
00:24:07,164 --> 00:24:09,584
And we've never really
1062
00:24:09,974 --> 00:24:10,794
thought of it that way.
1063
00:24:11,074 --> 00:24:12,344
We've, in the beginning,
1064
00:24:12,344 --> 00:24:13,054
we've actually had
1065
00:24:13,054 --> 00:24:13,824
to heavily invest
1066
00:24:13,824 --> 00:24:14,714
in writing our own
1067
00:24:14,734 --> 00:24:16,094
operators to manage a
1068
00:24:16,094 --> 00:24:17,064
lot of things because
1069
00:24:17,064 --> 00:24:18,364
we need to, you
1070
00:24:18,364 --> 00:24:19,354
know, we don't manage
1071
00:24:19,384 --> 00:24:20,544
thousands or tens of
1072
00:24:20,544 --> 00:24:22,194
thousands of database
1073
00:24:22,219 --> 00:24:23,049
that look the same.
1074
00:24:23,479 --> 00:24:24,779
We manage each one that
1075
00:24:24,779 --> 00:24:25,839
looks independently
1076
00:24:25,839 --> 00:24:26,769
different and has to
1077
00:24:26,789 --> 00:24:28,129
be managed separately.
1078
00:24:28,949 --> 00:24:30,859
And the other thing I
1079
00:24:30,859 --> 00:24:31,549
would say is there's
1080
00:24:31,549 --> 00:24:33,189
a lot of abstractions
1081
00:24:33,239 --> 00:24:34,059
in Kubernetes.
1082
00:24:34,089 --> 00:24:34,989
Let's take an example
1083
00:24:34,989 --> 00:24:37,009
stateful sets where
1084
00:24:37,089 --> 00:24:40,349
the thesis is that all
1085
00:24:40,409 --> 00:24:41,459
instances of a stateful
1086
00:24:41,459 --> 00:24:42,459
set look identical.
1087
00:24:43,429 --> 00:24:44,659
And that's actually
1088
00:24:44,669 --> 00:24:45,489
something that we've
1089
00:24:45,639 --> 00:24:46,959
both had to fight about,
1090
00:24:47,079 --> 00:24:48,329
fight with, and then
1091
00:24:48,329 --> 00:24:49,669
eventually kind of
1092
00:24:49,669 --> 00:24:50,589
conclude that it's not
1093
00:24:50,589 --> 00:24:51,989
right for us because
1094
00:24:51,989 --> 00:24:53,369
we actually want to
1095
00:24:53,369 --> 00:24:55,939
manage, even replicas of
1096
00:24:55,939 --> 00:24:57,519
a database separately.
1097
00:24:58,039 --> 00:24:58,939
So you could do things
1098
00:24:58,939 --> 00:25:00,009
like intelligent
1099
00:25:00,019 --> 00:25:00,979
staged upgrades,
1100
00:25:01,019 --> 00:25:01,749
staged rollouts,
1101
00:25:01,759 --> 00:25:03,869
staged resizing, which
1102
00:25:03,999 --> 00:25:05,299
certain abstractions in
1103
00:25:05,299 --> 00:25:06,209
stateful, like stateful
1104
00:25:06,229 --> 00:25:07,989
sets, which is meant to
1105
00:25:08,289 --> 00:25:09,289
make all of these things
1106
00:25:09,299 --> 00:25:10,869
identical, actually
1107
00:25:10,869 --> 00:25:11,809
aren't well suited for.
1108
00:25:13,229 --> 00:25:14,109
Right, right.
1109
00:25:14,889 --> 00:25:16,129
I think the last one
1110
00:25:16,329 --> 00:25:17,379
is really interesting
1111
00:25:17,379 --> 00:25:17,949
because that is
1112
00:25:17,949 --> 00:25:18,669
something that a
1113
00:25:18,669 --> 00:25:19,579
lot of people will
1114
00:25:19,669 --> 00:25:22,679
probably fight in
1115
00:25:22,679 --> 00:25:24,079
the near far future.
1116
00:25:24,229 --> 00:25:25,069
When more and more
1117
00:25:25,069 --> 00:25:26,249
databases move
1118
00:25:26,249 --> 00:25:27,009
to Kubernetes.
1119
00:25:28,154 --> 00:25:29,304
I didn't think about
1120
00:25:29,304 --> 00:25:30,264
it because I always
1121
00:25:30,694 --> 00:25:31,564
considered like the
1122
00:25:31,564 --> 00:25:32,624
replicas being the
1123
00:25:32,624 --> 00:25:34,684
same, but you're right.
1124
00:25:35,094 --> 00:25:35,884
If you want to do like
1125
00:25:35,884 --> 00:25:36,774
a rolling upgrade or
1126
00:25:36,774 --> 00:25:38,084
stuff, it's going
1127
00:25:38,644 --> 00:25:39,104
to be a little bit
1128
00:25:39,104 --> 00:25:39,724
more challenging.
1129
00:25:40,024 --> 00:25:41,384
Anyway, we're pretty
1130
00:25:41,404 --> 00:25:42,184
much out of time.
1131
00:25:42,524 --> 00:25:43,784
So one last question,
1132
00:25:44,224 --> 00:25:45,334
what do you personally
1133
00:25:45,354 --> 00:25:45,944
think is like the
1134
00:25:45,944 --> 00:25:46,944
next big thing?
1135
00:25:46,944 --> 00:25:48,414
What is like upcoming?
1136
00:25:48,424 --> 00:25:49,524
What is already
1137
00:25:49,524 --> 00:25:51,044
here, but growing?
1138
00:25:52,184 --> 00:25:54,784
I know the answer, but-
1139
00:25:55,354 --> 00:25:56,514
Well, let me-
1140
00:25:56,964 --> 00:25:57,674
Maybe this is the
1141
00:25:57,674 --> 00:25:58,294
answer you thought,
1142
00:25:58,294 --> 00:25:58,954
but I'm going to give
1143
00:25:59,494 --> 00:26:00,804
a back to the future.
1144
00:26:00,944 --> 00:26:02,589
So, you know, Timescale
1145
00:26:02,599 --> 00:26:03,839
started by building time
1146
00:26:03,839 --> 00:26:05,409
series analytics on top
1147
00:26:05,409 --> 00:26:06,729
of Postgres, and about
1148
00:26:06,729 --> 00:26:08,009
a year ago, we launched
1149
00:26:08,019 --> 00:26:09,099
our AI product, our
1150
00:26:09,099 --> 00:26:10,069
vector search product.
1151
00:26:10,070 --> 00:26:11,289
And kind of open
1152
00:26:11,289 --> 00:26:11,869
sourced it under
1153
00:26:11,869 --> 00:26:12,879
the Postgres license
1154
00:26:12,909 --> 00:26:13,889
just a month ago.
1155
00:26:13,890 --> 00:26:14,889
A lot of really
1156
00:26:14,889 --> 00:26:15,849
interesting to do
1157
00:26:15,859 --> 00:26:16,829
what we call PG vector
1158
00:26:16,829 --> 00:26:18,059
scale, which is scalable
1159
00:26:18,069 --> 00:26:18,869
vector search, and
1160
00:26:18,869 --> 00:26:19,799
then PG AI, which is
1161
00:26:19,800 --> 00:26:20,929
a lot of you do AI.
1162
00:26:21,419 --> 00:26:23,699
Things like OpenAI,
1163
00:26:23,700 --> 00:26:24,729
Cohere, Olam
1164
00:26:24,829 --> 00:26:25,529
Embeddings directly
1165
00:26:25,529 --> 00:26:27,249
in your database.
1166
00:26:27,599 --> 00:26:29,289
More broadly, I think we
1167
00:26:29,289 --> 00:26:31,659
are bullish on Postgres.
1168
00:26:32,009 --> 00:26:33,059
And what that means
1169
00:26:33,059 --> 00:26:34,369
is that, you know, we
1170
00:26:34,369 --> 00:26:36,269
think that 99 percent
1171
00:26:36,299 --> 00:26:38,619
of developers' problems
1172
00:26:39,059 --> 00:26:39,669
can be solved with
1173
00:26:39,859 --> 00:26:40,859
Postgres for a database.
1174
00:26:41,159 --> 00:26:41,659
Now there's going to
1175
00:26:41,659 --> 00:26:42,909
be always that 1%.
1176
00:26:43,359 --> 00:26:43,979
There's going to be
1177
00:26:43,979 --> 00:26:45,609
the, Hey, I'm building
1178
00:26:45,619 --> 00:26:47,439
Netflix, Uber, Google.
1179
00:26:47,449 --> 00:26:48,299
They're going to build
1180
00:26:48,299 --> 00:26:49,959
custom, but that's not
1181
00:26:49,969 --> 00:26:51,549
what most companies do.
1182
00:26:51,579 --> 00:26:52,839
And that's both startups
1183
00:26:52,869 --> 00:26:54,109
and actually, you
1184
00:26:54,109 --> 00:26:55,259
know, we deal with
1185
00:26:55,259 --> 00:26:56,029
some companies that
1186
00:26:56,029 --> 00:26:56,819
are one month old.
1187
00:26:56,889 --> 00:26:57,339
We've deal with
1188
00:26:57,369 --> 00:26:59,464
companies that were
1189
00:27:00,424 --> 00:27:01,934
built in the industrial,
1190
00:27:01,944 --> 00:27:02,604
first industrial
1191
00:27:02,604 --> 00:27:04,044
revolution, right?
1192
00:27:04,054 --> 00:27:05,344
So we have the large
1193
00:27:05,394 --> 00:27:07,084
gamut of companies
1194
00:27:07,084 --> 00:27:07,714
that we serve.
1195
00:27:08,634 --> 00:27:10,504
And for many of them,
1196
00:27:10,505 --> 00:27:12,698
the reliability,
1197
00:27:12,698 --> 00:27:15,064
usability, the
1198
00:27:15,124 --> 00:27:16,404
ecosystem of Postgres
1199
00:27:16,414 --> 00:27:17,454
is so powerful.
1200
00:27:17,514 --> 00:27:18,094
You know, they have
1201
00:27:18,104 --> 00:27:18,704
people who know that
1202
00:27:18,704 --> 00:27:19,234
they have people who
1203
00:27:19,234 --> 00:27:20,064
trust that they have,
1204
00:27:20,894 --> 00:27:21,574
if they want to use
1205
00:27:21,574 --> 00:27:22,224
our managed cloud.
1206
00:27:22,224 --> 00:27:22,664
If they want it
1207
00:27:22,664 --> 00:27:23,734
themselves, there's
1208
00:27:23,744 --> 00:27:24,764
lots of options.
1209
00:27:24,834 --> 00:27:26,359
And so, we're very
1210
00:27:26,359 --> 00:27:27,319
bullish on that.
1211
00:27:27,779 --> 00:27:28,959
And, you know, we
1212
00:27:28,989 --> 00:27:30,479
continue to basically
1213
00:27:30,499 --> 00:27:31,699
think about how we
1214
00:27:32,049 --> 00:27:33,269
then, like I said, make
1215
00:27:33,329 --> 00:27:34,529
Postgres powerful for
1216
00:27:34,539 --> 00:27:35,449
all these different use
1217
00:27:35,449 --> 00:27:36,969
cases where it could
1218
00:27:36,969 --> 00:27:37,599
serve these types of
1219
00:27:37,599 --> 00:27:38,569
demanding applications.
1220
00:27:38,579 --> 00:27:39,899
So kind of expect
1221
00:27:39,909 --> 00:27:40,939
to see, you know, we
1222
00:27:40,939 --> 00:27:41,839
started by in time
1223
00:27:41,839 --> 00:27:43,059
series and analytics.
1224
00:27:43,059 --> 00:27:44,059
We built an amazing
1225
00:27:44,059 --> 00:27:44,909
cloud platform
1226
00:27:44,909 --> 00:27:45,579
for Postgres.
1227
00:27:46,119 --> 00:27:46,899
And in doing so, we
1228
00:27:46,899 --> 00:27:47,519
built, like I said,
1229
00:27:47,519 --> 00:27:48,569
a cloud platform for
1230
00:27:48,579 --> 00:27:50,079
Postgres, not just
1231
00:27:50,119 --> 00:27:51,269
a cloud platform
1232
00:27:51,289 --> 00:27:51,969
for time series.
1233
00:27:52,469 --> 00:27:53,089
And so expect
1234
00:27:53,089 --> 00:27:53,469
more from that.
1235
00:27:53,479 --> 00:27:53,939
All right.
1236
00:27:53,999 --> 00:27:54,359
Fair enough.
1237
00:27:55,059 --> 00:27:55,449
Fair enough.
1238
00:27:55,499 --> 00:27:56,179
That was not the
1239
00:27:56,179 --> 00:27:56,999
answer I expected.
1240
00:27:59,069 --> 00:28:00,389
Everyone else said AI.
1241
00:28:00,559 --> 00:28:02,699
You kind of made
1242
00:28:02,699 --> 00:28:03,329
me sad here.
1243
00:28:03,809 --> 00:28:06,679
Well, AI, I actually,
1244
00:28:06,729 --> 00:28:08,189
I mean, AI,
1245
00:28:08,189 --> 00:28:08,979
but maybe I have-
1246
00:28:08,979 --> 00:28:10,589
Let me get take two
1247
00:28:10,589 --> 00:28:11,549
on that question.
1248
00:28:12,129 --> 00:28:13,739
I think five years
1249
00:28:13,739 --> 00:28:14,519
from now, we won't be
1250
00:28:14,519 --> 00:28:15,239
talking about building
1251
00:28:15,239 --> 00:28:16,479
AI applications.
1252
00:28:16,479 --> 00:28:17,099
We'll be talking about
1253
00:28:17,099 --> 00:28:18,069
building applications
1254
00:28:18,069 --> 00:28:19,069
where it will, they
1255
00:28:19,069 --> 00:28:20,199
will all incorporate AI
1256
00:28:20,209 --> 00:28:20,839
where it makes sense.
1257
00:28:21,599 --> 00:28:23,789
And so, you know, I
1258
00:28:23,789 --> 00:28:24,539
think we're going to
1259
00:28:24,539 --> 00:28:25,819
have a lot of people
1260
00:28:25,819 --> 00:28:26,679
talk about being AI
1261
00:28:26,679 --> 00:28:27,489
engineers and whatever.
1262
00:28:27,499 --> 00:28:27,929
I think this will
1263
00:28:27,929 --> 00:28:29,299
happen, but I think this
1264
00:28:29,299 --> 00:28:30,399
will actually recede
1265
00:28:30,609 --> 00:28:31,359
because this will be
1266
00:28:31,419 --> 00:28:33,469
another thing in the
1267
00:28:33,469 --> 00:28:34,849
tool belt of developers
1268
00:28:35,039 --> 00:28:35,879
where what it means to
1269
00:28:35,879 --> 00:28:36,899
be a modern developer.
1270
00:28:38,469 --> 00:28:38,799
All right.
1271
00:28:38,819 --> 00:28:39,539
I like that.
1272
00:28:39,949 --> 00:28:40,729
That's a beautiful
1273
00:28:40,729 --> 00:28:41,779
last sentence, I guess.
1274
00:28:42,579 --> 00:28:44,356
So, we're out of time.
1275
00:28:44,526 --> 00:28:45,039
Thank you, Mike,
1276
00:28:45,039 --> 00:28:45,599
for being here.
1277
00:28:46,289 --> 00:28:46,929
Thank you for being
1278
00:28:46,929 --> 00:28:47,769
an awesome guest.
1279
00:28:47,999 --> 00:28:50,029
And for-
1280
00:28:50,924 --> 00:28:51,424
And for the
1281
00:28:51,424 --> 00:28:52,494
audience, thank
1282
00:28:52,494 --> 00:28:53,354
you for being here.
1283
00:28:53,384 --> 00:28:54,944
Hope to see you
1284
00:28:54,964 --> 00:28:56,174
next week, same
1285
00:28:56,174 --> 00:28:57,144
place, same time.
1286
00:28:57,804 --> 00:28:58,604
And thank you very much
1287
00:28:58,604 --> 00:28:59,374
for being here as well.
1288
00:29:02,474 --> 00:29:03,224
The Cloud Commute
1289
00:29:03,274 --> 00:29:04,284
Podcast is sponsored by
1290
00:29:04,284 --> 00:29:05,764
Simplyblock, your own
1291
00:29:05,764 --> 00:29:06,724
elastic block storage
1292
00:29:06,724 --> 00:29:07,714
engine for the cloud.
1293
00:29:07,884 --> 00:29:09,004
Get higher IOPS and
1294
00:29:09,014 --> 00:29:10,304
low predictable latency
1295
00:29:10,384 --> 00:29:11,204
while bringing down your
1296
00:29:11,204 --> 00:29:12,524
total cost of ownership.
1297
00:29:12,694 --> 00:29:18,994
www.simplyblock.Io