Hello, dear listeners, Bailey here.
Today, we are diving into the fascinating world of web three and
decentralized databases. Join us as Andy
and Frank interview Brennan Lanay, the founder of Quill.
Quill is the 1st decentralized, Community owned SQL
database solution for building advanced dapps and protocols.
From the demand for web3 solutions to the nuances of trustless
applications, we delve into it all. Don't be
alarmed at Frank's absence early on in the show. He
shows up later. As an added bonus, for the
first time in data driven history, Andy does the intro.
So sit back, relax, and get ready to embark on a journey that
will expand your understanding of the ever evolving landscape of technology and
data. Now on to the show.
Hello, and welcome to Data Driven, the podcast where we talk about
artificial intelligence, Machine learning, data engineering,
and all things kind of related to to those topics.
Frank usually does this introduction. That's why I'm kind of skipping through
it. I'm trying my very, very best to not say,
in any of these. Frank's gonna join us a little bit later.
He had something else he needed to do. Our guest today
is Brennan Lamy. Did I say that right? Brennan, both names?
That is correct. Yes. Awesome. And, Brennan, I usually
go to LinkedIn and read through the lengthy
bio. And and here we go. Brennan is a
founder and dev. That's a pretty lengthy bio. That may
be the shortest LinkedIn bio ever, Brennan.
Yeah. I would say, I I don't know. I'm still working on stuff to
put there. But I I'm open to
suggestions. I'm open. Awesome. No. I I think it's great. I think,
you're spending your, your time wisely And you've got your
priorities, pretty much aligned there. You're you're you're doing the
work and then later once you've done the work you can come and fill in
the blanks. That's the goal. That's the goal. Awesome.
Well, why don't you tell us a little bit more about yourself? Maybe what you're
working on, your company? Yeah. Yeah. So, I mean, my name
is Bruno Marney, and I am the founder of Quil. So it's just
k w I l, kinda like the Quil that you, that you can write with.
Cool. And Quill, we are building, decentralized databases.
So relational databases, specifically. Okay. And
really the niche that this This fits into. I don't like to say
that it solves an existing problem, because I think it more
allows people to Capitalized on previously uncapitalized opportunities
and solving some, you know, massive problem. But what a
decentralized database is for is It allows you to build new types of
applications with different trust assumptions. And it it also
allows you to accrue value from your data in new
ways. And so this very much falls into the web three space. I'll
sort of give a high level overview here, and then, Andy, you can sort of
choose where you want to go deeper. But with Quill, you can build
data stores with, complex access control rules,
complex guarantees on the scheme of the data, who's able to write to it, How
they can write to it, when they can write to it. And you can set
this for parties that don't trust each other. So maybe you and Frank are competitors
or maybe you have to agree on some sort of, legal standard and collaborate in
that way, but in all other sense of the word, you are competitors.
And so this allows you to convene around a shared data store with rules
set beforehand. And you can now use this, in real
time to power both of your applications. So kinda at
a high level, that's what we're doing. There's some really interesting caveats In value
accrual as well, but I can sort of jump into anywhere that you want me
to. You know, I'd love to hear more about the value.
Yeah. So the the the real value of this so
it might be helpful with an example. I'll try to high level, and then I
can sort of dive into a couple examples we see right now. But so,
you know, the a lot of companies use data as a moat.
Data protects them from their competitors, but this also means that
you can't collaborate on data in a lot of ways that you might like.
And I think a cool example of this might be user identification
data. So this is pretty low hanging fruit. And for what it's worth, I don't
think it's, a particularly interesting example, But it is basic.
Things like Reddit, Spotify, and Instagram, they they all have the
concept of follower relationships, but they all have different
applications otherwise. And I think in a better world,
no matter what application you go and use, you would have the same
follower relationships and the same interests on all those different platforms if you
consented so. That is a massive, identity problem, so
you now need a way to your identity across those as well as your your
follower relationships and your interests. And all of those
companies are maybe somewhat competitive with each other.
Maybe not totally, but they are somewhat competitive. But in an ideal
world, they would be able to convene around some of the same sets of
data To power their application, this does give them less of
a data moats effect, but it does make the experience much more
convenient for your for their users. Okay. So
now, once again, I don't think that is the most compelling, application,
but, that's like a very high level example. It's a
good example. I was able to follow it. And, you know, it's always a good
sign. Yeah. Right. Glad to hear. I,
So I'm concerned about, as a person who moves data,
I'm a data engineer, and I'm concerned a little bit about,
Personally identifying information, not picking on your example, I
promise, from the for the user's
perspective. And then also,
that, you know, there's there's legal, stuff that goes along with
that in some fields. I do, I do
health care. I do financial. Those insurance. Those all
both health care and legal come together there. Sorry. Healthcare
and finance come together in insurance companies.
And so It you said something
that I found compelling. You said that you could convene around the
data, but you could do it in such a way Where you share
just what you wanna share, I think. And then, you, you
know, you've got a firewall essentially or some kind of separation of
concerns Between that and the rest of the data. So could
you elaborate on that a little bit and, you know, specifically
with, With regard to regulations?
Yeah. So I I think we can sort of split this up into 2 different
topic areas. So one of them is the the logical way of accessing data.
So This is like your application business logic. Should Frank be
able to should he be able to see my name, my age, my social security
number, and what can he see from this dataset? But then
also there is, there's sort of a an issue of
legal regulations. So whether that's GDPR or, you brought up health
care data. A lot of health care data, it matters where physically that
data is being stored. And so to sort of jump into the first one, this
actually gets to really the of our application or maybe one of the cruxes of
our application, which is configurable access control
for your data all within a single a single file or you
can you can do it across multiple files, but the the idea is that you
can do it in a single file. So we have our own language. It's a
DDL language, data definition language called Cuneiform.
And so with Cuneiform, it allows you to do a lot of, you know, regular
SQL DDL for tables and And things like that, but it it
also allows you to specify more complex access controls.
So who can write data? Who can read data? What data can they read from
this? And then we're also working with a couple partners right
now designing a system of role based access control.
So you can assign different roles, roles might apply to different individuals,
or to different companies or really however you want to administer
these roles. And these define, like, with business
logic defined in cuneiform what a specific user is
allowed to access. Moving a bit more
to the regulatory side, this is less of a
question of the actual features of our product itself and more
of, a deployment issue. So you can sort of
think of our when you're using a Quill database,
it's distributed across multiple databases. And we
work with clients to help them distribute those databases as needed,
for their application. And this is, across an entire spectrum. So
On one side of the spectrum where there are no data privacy rules, you
could actually have a network where anybody is allowed to come in and sync this
data from your database. They're able to To get these updates in real time,
and then they can directly join in foreign key and, subquery
against this in their own application. And this obviously no
data, like, no legal restrictions, no access control
restrictions. It's like a totally public, read only dataset.
And then on the other side of the spectrum, you might have 2 companies that
wanna convene on health care data. And that health care data might need to
be geographically located in the State of Texas or maybe in the
case of GDPR, it needs to be, 1, it needs to
be located in European countries, but, 2, they also need to be able
to identify what companies are responsible for storing this data
so they can go after them to make sure they delete it. And so we
can also make sure that, as opposed to the other example
that you are gating who is able to store this data, Where
they're storing it, are you KYCing the other people that are running this
physical infrastructure that is, holding the data for your database?
And we work with clients sort of across that whole spectrum on what they need
for their specific deployment topologies. Well, that
sounds Complex. I think that's the first word that comes
to mind on that, but it also sounds like,
an interesting collection of problems that we have with data.
One of the reasons I get employed as a data engineer is
to solve these kinds of problems where we keep data in one location,
we set, we sometimes ship data to other locations
so that other people can use copies of it. An advantage
that leaps to mind, based on your description, Aquil
is you don't have to make a bajillion copies of the data. You are
able to just share, it sounds like, access. And you're,
defining in in this language that is it, you you pronounce it, I
believe, cuneiform? Yeah. Yeah. Cuneiform. Isn't that the Egyptian
characters For hieroglyphics. Am I getting that
right? Or Yeah. So Cuneiform, it was the 1st written
language. I should now ours is Quill for us is
spelled with a k. It's Unifor, also spelled with a k. Other than that Interesting.
That's kinda cool. I I like it. And, yeah, it sounds
like Based on the problems you're trying to solve, that it would
also be a very, very flexible
and and very, cool language to to learn. And
and I'm just curious if somebody, someone like me so I'll use
me as an example because I would like to know more about it. Is there
some way that I can get in and play around with Quill, get a feel
for it? Yeah. Yeah. So just ide.quill.com.
So IDE and then Quill, k w I l.com. That pulls up
an IDE. It also gets preloaded with 3 different, Somewhat
basic examples, for a type of application you might build on
Quill. So and I'm just pulling this up right now as a reference, but we
have, like, an example video game that's storing data. We have, a
token. We operate a lot in the cryptocurrency space, and then also
an example social network. And all these show how you would use Cuneiform,
to to do this. And it's it's very straightforward. If you know if you're
familiar with the SQL 90 2 standard, I am fully confident you'd be able to
look at this and tell me exactly what is going on in this Application. It's,
it's pretty straightforward. Awesome. I'll take your word for it.
And and I'm fascinated by the idea, the, just the whole idea
of this. A little bit of company background. I'm just curious how long has Quill
been around? So Quill's been around for a little over 2 years
now. Started under a different name and doing something different,
actually. So, we're building a decentralized
social media. So, decentralized communication platform trying
to incentivize serving of data in, areas where
you're not, where you're disincentivized through data. So think Non
Western countries where there's enforced censorship,
and our goal was trying to serve data in those areas. No. That's
a massively hard problem, and there's Yeah. So many,
so many issues with, I mean, consistency and the Cryptographic,
like, verifiability of that data that, we we were trying
to solve that. And in solving that, we sort of solved this,
Database use case of building this decentralized database. And we ended up just running with
that instead because it was much more applicable to, A
wider variety of applications than just the specific one that we were
building. And so we spend about the 1st year building that
social. And then Last, January or February,
we, or yeah. Last January or February, we transitioned to
just doing the database specifically. Okay. Well,
I love the pivoting. I just do. I think that's always a good
thing to go with. And, you know,
I've seen many companies kinda go through these phases where
they'll do exactly what you did. They'll start out trying to solve 1 problem, realize
there's this other niche That they could really serve.
And then later, sometimes even expand back out. That
happens sometimes as well. But I'm old and I've seen a lot
of companies, so that that kind of
happens. Well, so we talked about,
Cuneiform, which is a language. You guys, I guess, invented that?
Yeah. You know, it's It's it's it's really a DDL
language. Like, it's not a whole, like, you know, full, full
language, but it's yeah. It's useful for defining access control. But, yes, that
was That was an old house. So talking about access
control, I know one of the, you know, one of the challenges to that
is Row level or even cell level, you
know, the access control. How how fine a grain do
y'all go to? It's a great question. So, there's sort
of 2 things I can touch on there. So the answer is technically
both. So, with Quill, or with with Cuneiform, we
have this concept of actions. And action, you
can sort of think of it like a function that Anybody can call. It's like
a it's an RPC call that anybody can call or you can set rules for
who's able to call it, and it executes some query against the database. So
this can be an insert statement. It can be a select statement. And so you
might have a select statement that is able to get some users
data, and maybe from May maybe it gets some data from a
few rows and retrieves a couple of the columns within that row. And so in
that way, you can sort of make custom access control for columns.
And then another thing we have and, let me know if this doesn't make sense
because this is a bit more of, like, a web three native concept.
But we have we call it a caller modifier. And so what this is
is that when you're interacting with Quill, you have a key pair, and
this is how we do User identification. And
so, when you are using, when you're using this key pair,
it takes the address of that sort of thing like a public key On
that, either you're signing your, your your your insert statement with
or your update or your select or anything else. And it can
use that Public identifier as a
parameter in an action. So, let's say we have an
application that is storing a list of user data. Let's say let's say it's
just storing your your name and your age and you're identified
by your by your key pair. You might only be able to go
and update the row where the, where the
caller matches your key pair. And so that means that You and Frank
can both have rows in the same database, but only you are able
to update yours. Only he is able to update his. You can also set access
control restrictions on Who is able to read from which ones?
Okay. Does that make sense? It does. That's a great example.
And, you know, especially using, like, customers slash
people table. And I I I'm I'm
impressed by the answer itself. I mean, that's that's a hard problem
to solve as well. So, and doing that and then
when we talk about user access, is this something that is
designed for use? Obviously, it's happening between
companies. You talked about competitors. Is this is this
setting in the wild Or are there, you know, ports open to the
big bad web? Sorry. Could could you restate that
question? I think I might have misheard you. That's okay. So I know you mentioned
that, the database and the access control controls access
between, competing entities, maybe companies that
compete with each other, But they wanna share some portion of data.
So I'm wondering, does is Quill hosted in such a way
that it can be accessed From the, you know, the web at
large, the entire interweb or Internet rather. I said
interweb. I was thinking that and going, don't say it. Don't say it.
The entire Internet. And and and if
so, you know, what are your concerns about
security? Yeah. So that's a great question. So,
once again, this does sort of come back to the the 2 prongs of,
Cuniform access control and then Mhmm. General network
access control for your database. So cuneiform access control, you can
sort of think of this like a rest API where, they they can you
know, It's a client server architecture and anybody can make
calls to the actions you have defined. So maybe it's get the
Get the most recent, you know, record inserted into the database,
or in into a table. May maybe that's an action you have and anybody can
call that and get the most recent record. And so in that way,
you have, I mean, configurable access control. So you
can make that totally public where anybody's able to access that. You can also
make it so only a specific white list of individuals
that you want are able to access that. And right now, how we identify those
individuals is with Key pairs. So,
now we're not specifically tied to the key pair structure. This is just,
it it's really just what our, early clients have needed, and so that's why we
use key pairs for, user authentication. And
then getting To, like, the general because you had
also asked about, people, just anyone in the Internet being able to access
this data. This gets a lot more into network
deployment topology. And so with this, you might have
a database network Where you know everybody that's running these, you
know, the infrastructure for it, and they are running that closed. So, you know,
like a private Postgres or, you know, MySQL server,
nobody like, you are the only ones that are able to access that or you
know everybody who's able to access it. But on the on the I guess
the flip side of that, you can also Run a version where anybody
can come and hook into your data, and it doesn't really cost you anything
extra. So the white list in that case would just be
everyone? Yeah. So, I I think a a
useful way to think about it would be in that case, everybody is able to
see the logs that are coming into your database. So Mhmm. You
know, we have the the actual consensus layer. So we don't use wrap. You
can sort of think of it like a wrap consensus layer. And then below that,
we actually have the data storage. So, they can
essentially come and be a part of that consensus layer. Maybe they can
only, read from it, But, they can come and read from these logs
before they're executed on the database. When you use Q2Form,
that is defining access control for them coming and accessing your
database. They can't see all of the logs. Does that make sense?
It does. And it's a interesting and and very powerful
sounding, paradigm that you've That you've surfaced there. And
it's not that I'm not throwing off on traditional relational databases
when I say that. It's, almost like a combination
of What you would expect from relational databases
or maybe even NoSQL databases, but built
on top of that is a little bit more beef In the
access control space. And that, you know, has
typically been the, kind of the purview of the application
developers. They manage that part. And it sounds like you've
baked that right into your, your database control.
So I I like that a lot. They're part of it.
It's a really interesting trade off because, you know, a lot of early
databases and this is true for, I would say, you know, I mean, Most major
ones, I believe SQL Server, but I know Oracle, MySQL, and
Postgres, they have baked in user access control that most people don't
really use. Most people actually go for access control, you know, at
their on, like, their API layer. Mhmm. But for
our case, because of the unique Environments that this is being used into, we
need to bake an access control logic in a different way than these
databases already do, but we need to bake that in directly to the data
itself. And that is what allows us to sort of open up
new use cases that previously were not possible. Go ahead.
Again, sounds very Powerful. And, I imagine
business is growing. Yeah. Yeah. It's going quite
well. That's that's excellent to hear. I always,
I enjoy hearing success stories. They, they inspire me as
well. Gosh. I'm trying to think of
Some more stuff about it. I got I got my head around the basics, I
think, but it's gonna be I know me. It's gonna be, like, 8 o'clock tonight.
I'm gonna go, I should ask him this. It's
all good. Yeah. I think you're running this 1 this 1 solo without Frank right
now. So Well, yeah. And Frank thinks, So Frank thinks differently,
than I do. We're we both started as,
developers and then we moved into data.
And in Frank's case, I had to beg him for about 10
years to get him to go into data, specifically business
intelligence, Because Frank is an artist at heart,
so he already does pretty pictures, you know, and I still can't color in
the lines. So I was like, you can do this whole analytics thing,
Frank. You've got a good eye for it. And he got there. It was
just he kinda Came around it at a different way. And he's told me about
a 100 times, you were right. Should've done that years
ago. But, And he's a he he
because of the way he thinks, it's it's different than the way that I
think. I kind of approach I don't know. I'm not saying right or wrong. I'm
not Comparing and contrasting. It's just different.
And and I work with a number of people in in different fields where
It's it's very productive to work with. Frank's as a Frank's more of
a data scientist, but he's also a data engineer. He's old school data
science. And I I work, of course, I
work well with him. We were we were friends before we started working together. And
then, a handful of database administrators, I
find it because I whenever I see a problem that needs to be solved,
my developer roots are my first response. That's my knee jerk.
Let's go write some code, you know, to do this in some language and try
and figure it out that way. And my DBA friends are all, well,
You know, we can store some business logic here in a view or a store
procedure and access it that way. And it's it's it's
a different approach. I but I'm You know, I know enough
about both to be dangerous, I'd say. And that's why I'm I'm very it's
very appealing to me. I I've done a little bit of web work, there
for a while. Not not in your
league. I built a website that began to get a little popular
and I hired a web developer to take a look at it
And he looked at it. He cut he his first response to me was, this
looks like an engineer built it. And I'm like, I am an
engineer. That's I thought I took it as a compliment. You laughed because you know
it's not a compliment. Yeah. It's interesting.
We I kinda suffer from the same thing. You know, very very
engineering focused. We have a very engineering focused culture. Like, everyone at our
company writes code, even the guy that does our finances and payroll.
Wow. Everybody here is now in different amounts,
obviously, but Sure. Everyone writes code, and so when it gets to a bit
more of the creative side, I I don't wanna say
we we struggle there, but it's where we have struggled a bit in It's something
we've gotten quite a bit better at. But, yeah, we you can tell our
applications were built by engineers. They're it might not be the prettiest
thing in the world, but they're they're very Pragmatic. Yeah.
Absolutely. So And and see, I don't even notice, when I
see things like that. I don't I don't even notice them. But Frank's back so
we have to stop talking. Well, talking bad about him. We can talk about him
still but we only have to say the good things. Welcome back, Frank. That's
funny. Thank you for your patience. One of these days, I will explain all
of this publicly to our listeners and And whatnot, but,
there's a good reason for my absence there. Yeah. No.
I heard about, it it I heard this funny thing, and this is how Andy
and I met where, you know, you You said these apps look like they're written
by engineers. And that's kind of this back and forth
Andy and I have about, like, Design and whatnot.
So Rank food designer. Yeah. So Brennan
was explaining to me that everyone at Quill codes.
Really? Even the even the finance people. Interesting.
Well, Fortis, we're we're a 7 person team. You know, it's not like we're a
we're a huge company. But, yeah. Everybody I mean,
everybody knows how to code and writes some amount of code.
They might not have done that when they came in, but they they picked it
up in one way or another. How do people react to that? Do they like
the idea, or do they kinda bristle? Or you tell them in the interview
That, hey. We're doing this. So it's interesting. We it's
not like we hire people, like, yeah. You will learn to code when you come
here. It it's almost just an inevitability. We're we're solving a very
technical product for a very technical group of users. Right. And
so it's sort of inevitable that, you know, you're you're gonna learn how to
How to code to some extent, working in that job,
really no matter what, like, what role you have. And so it it's not like
a hard fast rule. We have the company where you to learn how to code.
It just it inevitably has happened every
time. So Interesting. Yeah. And Frank, the
I'll give you my understanding of a synopsis of of
what what their database does.
It's It's like a relational database, but built
into it is this user access control. And
it's, like, coupled, to that to the extent that they
can do not only row level, but row column level security and
access control. Interesting. How do I do, Brennan?
Yeah. No. I I'm I I I think that's good for a high level overview.
I think it's good for a high level. But I'm happy to sort of jump
into any of the specifics that you'd like, Frank. So
so tell me, How do you
how does that work? You do role level control or cell level control? Is it
is it role based access control, attribute access control,
Some combination? Yeah. So,
kind of neither. So, we do authentication with key pairs. So
anybody who wants to use a database, they have to have a, a public
private key pair, like an e c v e c d s a key pair.
And you can set rules for what keys are
able to do what in your database. And and so we have
our own language for defining this. We call it cuneiform. It's
cuneiform was the first ever written language. We thought that might be fitting
for our our language. And so our language, it's a it's a DDL language.
So, it sort of specifies the structure for your database,
and then all of your DML is done with, SQL.
But, with this DDL language, you can specify what
we call actions, and you can sort of think of these like RPC calls or
functions Where, they they're gonna execute some
DML against the underlying database. So this could be an
insert or an update or a delete or it can be a select. And you
can set all these interesting rules for who is able to do this, when
they're able to do this, do they have to transfer some sort of
value and able to do this Either once or every time they do it,
or do they have to have, some role that applies to them that
allows them to do this? And, You know, since we're able to identify
people by their key pair, when Andy comes in and uses
and, you know, interacts with the database, I can tell that he is distinctly different
from you, and I know what Andy is allowed to do. And there's even
a small amount of programmability that can be fit into that. So, you
know, when Andy is hitting one of those actions or RPC
calls, that might give him, results or
allow him to do certain things that you would not be allowed to do if
the database is configured that way. Interesting.
Interesting. So you have really fine grained control over what who can
do what? Yeah. You know, I I might hesitate to
say Fine grained because it's
it it is fine grained. You can really set whatever, however you
can think to specify what someone can do in SQL, you can you
can really do that with access control. But we don't implement
it with a fine grained approach. I think a lot of the time, databases that
are really trying to iterate on the access control front,
they they get really into row and column level
access. And that's not quite what we do.
We sort of see our role as, you know, an iterating for access
control on 2 different layers. The first one is on the actual consensus
layer. So, you know, if you think in a traditional data system, this is where
your raft consensus logs are are sitting before they get executed on your data
layer. We don't use Raft, but, so that is the
1st place where we able to have access controls. So this is, you know, network
wide access control, Who can read what data coming in?
And then secondly, we define, and this is for more
client server access control, or for people that are trying to
read from the database, at any point in time, but you can think of
this I don't wanna say like a REST API, but a little bit more like
a REST API than traditional database where you can have
preset queries and, preset functionality that
certain people are able to do or Certain groups of people are able to do
in certain instances. But the ways
that you can combine these things, You can you can you can
combine it to do very granular access control, but that's not really where
we attack the problem. Where did you get the idea for this?
Because this is fascinating. Yeah. So it's interesting.
It's been a little bit of a of a of a ride. So,
we started by building a a decentralized
communication platform. So really trying to incentivize,
serving data in places where you're otherwise disincentivized. So
think non Western countries where there's enforced censorship or IP
blocking. How can we incentivize people to use things
like HTTP tunnels to, spread data? Not
really hard to build a business on that. And so sort of how we
iterated from there was we took the data infrastructure for that, and we started
providing that as a stand alone service. And this is actually where the access control
part of this Really interesting. We started talking to a
lot of projects that, you know, they're building some sort
of data store. They have some data intensive application, but they're not
looking to build that as a data moat. They're looking to build that as a
composable, you know, data building block that other applications are
able to directly import. Just like how you import a line of code or, you
know, a package of code into your application, you should be able to do that
with data as well, assuming you you're applying to all the different access
controls. And so what we're helping a lot of customers do
now is they can take their different datasets and,
people whether they're collaborators, clients, or competitors,
they can use that data in the ways that, that that
the, you know, originator the original data creator specifies.
And then also they can set interesting mechanisms for how value accrues
back to them. But it's really just been a process of
iteration from, You know, that initial idea of building shared
data stores and then, building more complex access
control mechanisms on top of that.
Does that make sense? No. It makes a lot of sense. It's a fascinating it's
just fascinating, because every time you think that we've we've we've Kind
of solved all the problems, particularly in the in the in the
data storage, in the data querying side of things. There's a whole new
layer that gets on call unfolded, and There's just enormous
opportunity, and, it's really cool because, like, I'm reading your bio, and, like,
you were still in school when you started this company, like, that's and you you
started Your first company when you were 16, and you had
15 you had 15 employees before you even go on 15 or
16 employees before you even go on to college, man. That's that's impressive,
I have to say. Yeah. I mean, I appreciate it. It's honestly just been a
lot of being in the right place at the right time. Not my first company.
It was not a tech company. It was Digging holes and, cutting
down trees and digging up bushes in Idaho.
But that was that was my first company. And then this
one, I started, during COVID on a gap year, from
college. But Very cool. It's honestly just been,
Being in the right place at the right time and, doing something that people find
interesting. That is so cool. I mean, like, you think
about the last couple years, A lot of people would say, oh, it's a terrible
time to start a business, but we've seen a couple of instances where it's actually
turns out to be a really good, like we talked to a bunch of folks,
some, So probably by the time this goes out, the shows will be out, but,
like, this whole there's this whole opportunities that I think are
just popping up left and right because of data, Because of AI,
because of, you know, distributed applications and stuff like
that. There's just it it's We're gonna look back on the
as these as the good old days of entrepreneurship and and opportunity.
Yeah. Hopefully. And and, you know, I I I would say that is actually,
like this the last, year, maybe
18 months has been probably the only time where we could have
started a a, a product like this. So
particularly in the growth of web 3. A lot of our beachhead markets
are sort of bridging that gap from, the traditional
space to web 3. We find a A lot of
our initial partners, they have a lot of their clients are
based in the traditional world, but their data engineering problems
are uniquely solved by what is provided in web 3. And
there's enough demand for this, for our specific solution to
to warrant a product. You know, it's only really existed in the last,
year or so. And so yeah. I you know, whether
or not this is a good time to start a business, I would say, 1,
I don't know, but also, I don't think, I I care too much. Like,
the need for what we are doing has really only just started existing, But it
very clearly does exist, and that's that's something that's pretty exciting
about it. So you said web 3, and I It's interesting
because when when most people think of web 3, they think, they
think blockchain. Right? And thanks to SPF that is kind of
cratered, I would say, although I I I am still don't
the crypto kids better not hate on me, like, I'm still a believer in blockchain
as a whole, as as an idea. I don't think I think currency is only
one of the things that you can do with it. And
2, the the the metaverse. Right? And obviously, I think the
metaverse, Obviously Facebook is stumbling on it like but
but it's interesting that the data portion of it is probably more
relevant than any of the other 2 and you don't hear the negative press about
Kind of this distributed data stores in into the,
I I just interesting. I think that you're part of the web 3. Have
you found that the labeling yourself part of web 3 has been a,
has turned from a positive to a negative, basically? Yeah.
I think so. Yeah. You know, some people, they might get
kinda turned off on it. You know, you might talk to a candidate, and when
we say we're because we do classify ourselves as a web 3 company.
Right. And when we say that, they're like, oh, like, you know,
I I don't really believe in that cryptocurrency stuff. And I I I
think that's fine, but I don't think web 3 is cryptocurrency.
Right. I mean, web 3 is a new type of distributed application
or distributed databases, honestly. We do,
I I I would say not just distributed, permissionless. Decentralized
Mhmm. List. That makes sense. With Web 3 applications were able
to relax a lot of the trust assumptions that are
made in other applications, in particular trust assumptions Between
the client and the server. And so
that's like, just forget about cryptocurrency and the metaverse
And tokens with dogs on them and everything else, that is what web
3 is. It is relaxing trust assumptions in, you
know, otherwise More traditional, you know,
client server and oh, not in client server, but it's just like general,
computer architecture models. And so that's what we are doing. You
know, I don't really care what the price of cryptocurrency does. I don't own any
cryptocurrency. Right. We're just building, you know, trustless
applications. That's a good way to put it because when you, you know,
you're obviously your company's doing well and and and and you're growing and
and you've had a pretty, you know, good run. Well, so you just said web
3 and I'm like, but but you're doing well.
I was like, but but but then then then then like, you know,
after you That's why I wanted to ask that. Now you explain it. You're right.
Like, web 3 is, you know, it's kind
of like, kinda like Beyonce. Right? Like, nobody hardly anyone remembers
What group she was part of. Right? I think, God, Destiny's Child.
There were like 3 or 4 singers in there. Right? But but, you know, one
of them one of them Has the the the fame and staying
power, the other ones not so much, no disrespect to them, if the
weird off chance that they're actually listening to a show About AI and data
science, but, you know, no. I just it's just interesting, like,
you know, and we think of all these technologies, like, I'm old enough to remember
1 web one o. Right? And all the crazy ideas,
particularly one of them was, you know, downloading Java
applets. Right? Downloading software from The Internet and
running it locally. Right? Well, that's called the app store now, we don't even think
about it. Right? But obviously, there are a lot of things that failed in that
era. Right. Same thing with web 2 point o, we're kind of saw that kind
of come and go, and I think the same is gonna be true here, you
know, like, you know, did we really need, You know, sock
puppets to sell us stuff, you know, sell us dog food. Right?
And but, you know, I remember very early
on there was a startup called, they were all the Java people
who made Java basically, started a company called Castanet or
Rumba, I forget Which one it was. But their big thing was they wanted to
create what we would call an app store, but for applications.
Right? And and that idea Resurface somewhere completely
different and now it's just part of, like, just the daily world we live
in. So it's it's interesting. I think that We always seem to
remember the Hindenburgs of history, but not necessarily
kind of the The the the the stuff that actually does work
out. Oh, absolutely. And I I think that'll be the the case with,
you know, web 3 as well. A lot of the
people, in particular, a lot of the really loud people that we're that we're
operating in web 3, you know, now that the The the prices of things
are down. They've kinda gone on to whatever the next thing it is they're gonna
do to try to make a quick buck. But the people that are building really
useful and interesting things, Most of them will stay around. You know, some of
them will fail. You know, businesses fail. But,
you know, it's something I've noticed, because I was also here when web 3 was
really popular, right, when when working in web 3 was the cool thing to be
doing. And something I've noticed is that The
people that are building actually useful applications and solving actually
hard problems, they're still here. You know, they're not
as loud as the other people that were here Or but that that's fine.
Like, the the actual core problems that we want to
solve are still being solved, and and I I think that there's a lot of
value in solving those problems. And so,
there's less people, but there's a higher concentration of High
quality people building in the space now, and I think that's what matters. Well and
now that it's quieted down some, y'all can get more work done. That
is, very true. That's very
true. Yeah. Which has also been quite
helpful. Well, we are gonna transition, to
the questions part. I hope you got a copy of Questions in advance. If you
didn't, I put them in chat. So if you'd like to, peruse
them. The very first one is, I think you've explained
it, But, it's a it's a softball,
for you. How did you find your way into data? Did,
data find you or did you find data? Yeah.
So I kinda inadvertently found my way into data. So I wanted to
solve this other problem that was present in the messaging
application. And, that really required me to dive I
don't wanna say super deep into data. It required me to dive super deep into
a few things, but it was in building
infrastructure for that that I found that there there was a real
opportunity if I went and, you know, doubled down and went even deeper into
data. And so, you know, for me, it was really just
kinda looking at, at what the market wanted, you know, when we're
working with design partners and potential customers, What is their feedback? And it
kind of pointed towards going deeper into data. And so that's how I found my
way into it. Nice. Interesting. So what's
your favorite part of your current gig?
So I would say, like, the the team I work with. So our
team is really tight knit. Most teams now are remote.
Almost every startup now is a remote startup, especially in the,
you know, quote unquote web three space. We're in person. So,
you know, the entire team is in the room right next to me. And, honestly,
we're all really close. We all really believe in the problems we're solving. We do
believe we're building a better and more fair Internet. And so that
makes it really fun to work here, you know, even if the hours might be
a little longer than they would be at another job. It's
it's really fun to work here. We all really get along, and, we work well
together. And so that's certainly my favorite part. And you're in Austin now. Right?
We are in Austin. Yeah. Our team is a really thriving tech scene right
now. Yeah. Yeah. If you're if you're young and work in tech, it's the the
place to be. And so it's very Awesome. Awesome.
So we have 3 complete the sentence statements, not really
questions. The first is when I'm not working, I enjoy
blank. Yeah. So I am I'm a
not a I live in Texas, I guess, not as much. But, I'm a really
big skier. So I grew up snow skiing. That's
cool. Yeah. I I'm from Idaho, and so it's kind of a
common thing there. And so, yeah, I did a ton a
ton of skiing growing up. I do, I ski raced. I do backcountry
skiing now. So a lot of, like, hiking, skiing, like, like, avalanche training, stuff
like that. Yeah. I would say that if I, you know, if
I was no longer working, and I I couldn't,
You know, I I love what I do, and I would do it, you know,
even if I wasn't making money doing it. But if I was no longer working,
I would probably go skiing. Very cool.
Another complete the sentence. I think the coolest thing in technology
today is? Yeah. So,
I'm I'm a little torn here. I think either,
permissionless networks. So, I mean,
people usually think of this as cryptocurrency layer ones, but I
think it extends sort of beyond that. But Any network that is permissionless and
allows people to it it functions as as a protocol,
and it doesn't have biases towards individuals. I think that's really
interesting. It has a lot of potential, or SQLite. I really like
SQLite. I think it's a really awesome piece of technology. I know it's
Not exactly the newest thing, but I think it's still of the things I've
worked with, SQLite is really cool. Nice.
Alright. Our last one, I look forward to the day when I can use
technology to blank. Oh, interesting. Interesting
question.
I think for me, I I'm really looking forward
to being able to use and I I I think we're we're almost
there. But being able to use,
AI programming to help us write unit tests and get full
context of our code base, I've been using GitHub Copilot
for, I think, maybe 9 months now, 8 months now, and it's
honestly changed my life. It's I don't know if you guys have
used GitHub Copilot. Would highly recommend trying it. It
has just my productivity has skyrocketed. And
now it's only able to handle a fairly small set of context. Like,
I believe it only has context for the file or maybe a couple of the
most recent files you've worked in. But, you know, there
there have been a couple, demo models, and, unfortunately, they're in private beta
right now. But where there are AI AI models that
can help you generate unit tests, and they can read through an entire
package of code you've written and see, oh, you might have a security vulnerability
here, or, Are you sure you actually meant to expose this in your
public API? Just those are sort of a lot of the foot
guns I still find myself running into. And I think we're almost at the
point where, that that, is is solved.
Wow. Very cool. Would highly recommend trying out Copilot if
you haven't. It's been it's been pretty crazy. I will check it
out. Yeah. I've done a couple of demos with it, you know, just to
it's kinda like, you know, walk through, follow the instructions type stuff.
It's not the same as when you're trying to solve a real a real problem,
real world problem. So I know enough to know that. I was still
impressed, But I haven't yet taken it to that next level.
Yeah. You know, it it's not super useful for writing large blocks
of code. Mhmm. It is useful as autocomplete.
So, I mean, like, a place I use it,
most of our stack is in Golang. Golang has pretty verbose error
handling. It's really helpful with that.
Like, just with that alone, it's doubled my productivity because it pretty much handles all
of the error handling for me. Wow. So That's impressive.
Very cool.
Share something wait. Which question did we
do? Yes. Just share something that's next in that list, But that's
my list, and it may be out of order. No. No. No. It is. Here's
something, different about yourself. But remember, we like to keep
our Itunes, clean rating. Yeah.
Oh, man. That's a that that's I think that's the toughest
one yet. I I had scanned through these
questions before the podcast, but I, I
did not think of this one.
Man, let me think about 1 for a sec. I don't
know. If you don't mind me asking, what would, what would your answers for this
be? And maybe that'll help me come up with something. Oh, I mean, like, one
of 1 of mine was, because we did this on on each other. We should
probably reupdate, Andy. Because I used one of my
first jobs was I was an EMT in the Bronx. Okay.
Yep. And for me, I I have a similar one to Frank.
I played guitar in a country rock band. Okay.
Wow. That's that's really cool.
Oh, man. I already brought up the the skiing thing. That one's tough.
I mean, how did you here's here's 1. I'll help you out. Like, how did
you start a landscaping company? Like like, when you were 16, like, how many 16
year olds do you know that just say, you know what? I'm gonna, Like, how
did that happen? Like This is impressive. Sure. Yeah. The the thank
you. I appreciate the help here. No problem. It's,
so I I grew up in Idaho, and we were we're a ways outside of
Boise. And so we had quite a bit of land, and it wasn't, you know,
nice. I mean, it it it built around. It's just like a Great place to
live, but it wasn't like, like like you know, we had to do it
like firebreaks, you know, a lot of irrigation work, things like
that. And so, growing up,
we wouldn't you know, me and my brothers were really young, we had a guy
who would come and help us do that. But as we got older, we started
our family did it ourselves. And he hired me,
and I would just kinda help him as an extra hand. He did this for
people all over. And I just kinda had a realization not that far into the
job. It was like, man, I could definitely do this myself, and I think I
could, you know, probably pay myself a little bit better.
And so I just, I I started small, started
with 1. Like, I didn't immediately quit my job or anything. I did quit my
job fairly quickly. But, I started with a couple small clients
just seeing if it was something I can handle. None of it was rocket science,
and so I figured that out. I started scaling up more
from, like, you know, mowing lawns to fire
breaks And digging in drainage ditches, a little bit of demolition work.
It's just a a bit higher margin. But, yeah,
honestly, just started 1 step at a time. I got 1 client. I got 2
clients, and then I got 10. I had a couple buddies that would
come out and help me. And it was just really you know? As opposed to
a business like like this one where it's, It was very technically focused,
and you're raising VC dollars and things like that. This was, I I
I worked out of a Ford Escape until I could afford a pickup truck. And
then I bought a pickup truck, and then I So it was it was it
was a little bit of a different process. But, yeah, that was kinda how I
got into it. No. That's cool. That is cool. Do you listen to
audiobooks? It's funny. I just saw that question.
I just got an Audible subscription 2 days ago.
Wow. Yeah. One of my coworkers recommended a book to me, And
I don't have a lot of time to actually sit down and read, but I
walk a lot. And so, I got Audible for that. So,
I'm It's a really good book. Would really recommend. It's called
Children of Time. It's like if you're into sci fi Mhmm. It's like a
postapocalyptic sci fi book where, they're humans.
They've they've left Earth, and they're, I I forget how far, but they're
they they've been traveling for, like, 2000 years, and they're now trying to recolonize a
new planet. And it's just sort of all the I
don't wanna spoil too much, but, it's about that. But it it's it's really
good. If you like sci fi, I would highly recommend. I'll check it out.
And, you can check it out too to our listeners.
Audible is a sponsor of the show, and you go to the data driven book
.com Or the data driven book .com depending on how you want to pronounce
it. Andy assures me that that link is
working and, I have my faith in Andy.
It was working a couple of hours ago. We did another recording. It's a
2 recording day, and it's working then. Yeah,
no, no. It could have been, it could have been my setup. Cause I was,
I was doing some weird stuff with DNS to get something else working on. It's
always DNS Frank. It's Always DNS.
So where can people I'm sorry. Go ahead, Andy. That's okay. You you do it,
Frank. I was gonna say the same thing. Where can people learn more
about you and what you're up to? Yeah. So, I mean, the first one is
just our website. So quill.comkwil.com.
I've also got a Twitter. That's probably the easiest way to get to me. So
my Twitter is just my name, so Brennan underscore Lamy.
But you can also find links to Quill's Twitter and inevitably to
to mine as well on our website. So I would say the biggest one is
just go into quill.com. It's probably the easiest.
Okay. Excellent. That sounds good. Yeah. And, any
parting thoughts? No. I don't think so. I mean, really, thank
you thank you all for having me. I it it's hard to find
people that, are as passionate about, you know, weird data engineering problems as I
am, and so it's really been a pleasure. Awesome. We're
happy to talk to other people who are into Data engineering, too. Well, that was
quite the show. Alright. I'll let go of it. It's always good to hear a
good entrepreneur origin story. One last thing
before you go. We know you're busy and we appreciate you
listening to our podcast. But we have a favor to
ask. Please rate and review our podcast on Itunes,
Stitcher, or wherever you subscribe to us. You
have subscribed to us? Haven't you?
Having high ratings and reviews helps us improve the quality of our show
and rank us more favorably with the search algorithms.
That means more people listen to us, spreading the joy.
And, Can't the world use a little more joy these days?
So, go do your part to make the world just a little better and be
sure to rate and review the show.