dnsUNFILTERED: Richard Hipp, SQLite

[00:00:00] Mikey Pruitt: thank you everybody for joining us on another episode of dnsUNFILTERED. I'm joined today by a very special guest, Richard Hipp, the basically the inventor of SQLite. He's had a long history in the world of technology. He built the most fundamental database and the story of how it was built is interesting.

But Richard, why don't you tell us a little bit a little bit about yourself and how you got started in tech.

[00:00:27] Richard Hipp: Yeah, sure. Thank you for the introduction. My name's Richard and I live in Charlotte, North Carolina. I took a PhD from Duke University in 1992, but recognized immediately that I was not a good fit for the academic world, and so I started a business just building bespoke software for people.

This was back when we still use dial up. Okay. And I started, I did that for a number of years, and in the course of doing that, at one point I I needed a, an embedded SQL database engine. And there, by embedded, it's built into the same process. There's no separate server and there was none available.

And so I thought, oh, I'll just write my own. And how hard can that be? And so I put together SQLI and I put it out there as open source thinking it would get about as many downloads as every other bit of open source software I'd ever put out. There would five to 10 downloads per year, but it went viral.

And after a while, companies started calling me up and said. Can we purchase support for this? And I was thinking, why would you wanna do that? You can make money on open source software. Who knew? How much would you charge for that, sir, let me get back to you on that tomorrow. And then I frantically searched around looking for, some kind of reasonable price.

Anyway, long story short, it, it turned into a business. I haven't done any bespoke software for decades. Business since then has been purely supporting and continuing the development of SQLite. SQLite started in the year 2000. But we really didn't really turn into a business until about 2004.

So it took a few years to catch on, but since then, i've been able to support a small team and we work on it full time and it has been so much fun. The Open Secret that's really cool. The open secret is that nobody on our team. Has any formal training in database technology.

Really, that's how simple SQLite is.

[00:02:54] Richard Hipp: It's gotten a little bit more complicated over the years. It's a constant struggle to keep things simple. But

[00:03:00] Mikey Pruitt: yeah. Wait, one one quick clarification. Do you say SQL light or SQLite? I've actually heard lots of pronunciations.

[00:03:06] Richard Hipp: No, you can pronounce it any way you want. I say no, I

[00:03:09] Mikey Pruitt: wanna pronounce it the way you pronounce it.

[00:03:10] Richard Hipp: I say SQLite. Oh, okay. Like a mineral sql. That is the only

[00:03:17] Mikey Pruitt: pronunciation I've never heard. SQL I very cool. So the name of your company is achi. You get, you run it with your wife and a small team, and you guys have been able to, build such a robust, error. Not error proof of course, minimal error is based on a massive, extensive testing suite that I understand is pretty comprehensive.

[00:03:42] Richard Hipp: Yeah. That's the key I've discovered and see when I first started this journey oh, there's something about PhD programs in the United States. When you come out of one, you have this idea that you know everything and that you can do no wrong. And I that's the lesson that I took out.

Oh, I had that. I was definitely thinking that I knew everything and you just have to spend a few years in the real world to get the right correction on that.

[00:04:11] Mikey Pruitt: So yeah, it doesn't take long. You get slap in the pace pretty fast

[00:04:15] Richard Hipp: anyway. But even when I was writing SQLI, I thought, I can write software that doesn't have any bugs in it.

I felt like SQI was just bug free. And then in the early two thousands it started being adopted by all these cell phone companies and for use in handsets, and they were, there were hundreds of millions of devices being deployed with it. And it turns out that when you deploy a hundred million or a billion instances of an application.

A lot of really obscure bugs will pop up.

I was shocked and we, there was this a period of time there where we were just getting all kinds of bugs and about that same time I had a contract and with an aerospace company and I learned about DO 1 78 B. This is the engineer or quality control spec for avionics or avionic software.

It's been superseded by DO 1 78 C now, but it's essentially the same thing and you have to pay for these. And I wasn't willing to pay to get the new version, so I'm still using B. But it defines a number of things to, to for safety critical software. And one of the things it talks about. Is 100% Mc DC test coverage or modified condition decision test coverage which is complicated, but it basically boils down to every branch.

Instruction at the machine code level both falls through and the jump is taken at least once within your test. And I thought I'm gonna implement this. And my idea was that, oh I'll do that. Then I can sell D 1 78 B artifacts to aerospace companies and make millions of dollars.

So the second part of that did not really play out, but it didn't matter. Sales that been zero. Okay. That didn't really work, but it took a year to really develop this test suite and, that was a hard year. I was working long, long days, six days a week. But at the end of it, this constant stream of bugs that we were getting from Android just stopped it.

It was it. I was shocked at how well that level of testing actually worked and, of course the original idea was to keep the test suite proprietary 'cause we were gonna sell it. That, that didn't really work out. But we, I've kept it proprietary because that's our, that's the company assets.

That's our intellectual property. The ES light source code itself. Is in the public domain, anybody can take it. They can fork the source code.

And we do have a lot of tests that are there in the public release, but they don't provide the full coverage that our proprietary do. And, but anybody can fork it and take it, but they can't get a hold of our test suite.

And that gives us a little bit of leverage that kind of gives, keeps us in control. I wish I. I wish I could claim that I had the idea of doing it that way from the beginning. But

[00:07:36] Mikey Pruitt: it wasn't in your business plan at the beginning.

[00:07:38] Richard Hipp: No. No. Really, no, it was not in my business plan at all. No, and I had no idea that you could do something like that.

It just, it worked out. It's I'm, I call it divine providence. I didn't. I didn't plan this. It worked out really well. I, if I had it all to do over again and know now what I knew, then I don't think I could have done any better.

[00:07:57] Mikey Pruitt: I would agree with that. And if for those listening that are not very familiar with SQLite, it is, sorry.

SQL Light, it is basically the most widely used database on the planet. It is near, it's the backbone of most apps on mobile devices. It's used in a lot of places, a lot of embedded places. And you manage it with a small team. You're not, you, it's open source, but there's no like public contributions, like you and your team manage all of the commits essentially to the source.

[00:08:32] Richard Hipp: Now let me correct that slide. That's a common misconception that we just refuse all contributions, and that's not strictly true. The thing is, it's in the public domain, and so in order to take a contribution, we have to make sure that contribution is also in the public domain. And so we do occasionally take contributions, but there's a lot of paperwork, there's a lot of hoops that you have to jump through in order to, you're making me,

[00:08:58] Mikey Pruitt: you're making me want to ask the question.

Who is it that's contributing to the source of SQL light?

[00:09:05] Richard Hipp: Some big companies who contributed to it, I imagine. We, there is code in the tree that was contributed by Apple, and there's some that was contributed by Google. And we had meetings with lawyers and there were signatures, and I've got documents in my fire safe right across the room over here that show that this is in the public domain.

And there's a list. I think it's 20 odd people who have contributed over the years.

[00:09:30] Mikey Pruitt: Yeah. And I think the point is like Sq, SQL light is, it's a global. Treasure, for lack of a better term, like it's very important to our tech, our com computing world.

It's usually the backbone, the database for like local apps, like a lot of Apple apps use it, which is why they would wanna contribute to the source. And I was really curious to ask you about this idea of simplicity. Like the SQLite is a C library. It's basically a single file database.

At least it appears that way when you're utilize, utilizing it. Very simple to operate. Very much like any other database of that nature, but there's this simplicity that only it has versus others. There's no server to run, nothing like that. And this idea of simplicity with your business the SQLI code itself, the deployment, and, this idea of simplicity, like simplicity is just like a timeless has timeless appeal a fine watch or something. I'm curious. And I and addition to that, I have seen this proliferation in recent months, maybe years of, not escal making a comeback, but in a way it is being a lot more, becoming more mainstream.

Like it's now included in the download for Rails eight. And other software frameworks because people have recognized its ability to, its simplicity and that perhaps this hyper scaling world is not always necessary.

[00:11:12] Richard Hipp: Yeah.

[00:11:12] Mikey Pruitt: So can you talk a little bit about that?

[00:11:14] Richard Hipp: Sure. Of course, the original idea was of the slogan was SQLI is not meant to replace Postgres.

It's meant to replace F Open. In the sense that a lot of people, maybe not so much now, but 10 or 20 years ago, people would, I've gotta store some data. I'm gonna open a file, write some data in my proprietary format that I just now invented and save it that way. And that was real common. I did it all the time myself, but my argument was, a better choice would be distorted in an SQI database.

So we weren't competing directly with the client server databases. They had more concurrency, but over the years and sq that's the purpose SQLite serves. And so that works really well on a mobile phone. How many concurrent users do you have on your mobile phone? Do you really need to support a hundred concurrent users?

So Sqli works really well in that we used to sell it as the SQL database for for edge devices, the database on the edge, other database engines. They would work in the data center, in, in the big server. And the lovingly attended environmentally controlled data center. SQ likes working on little raspberry pies out in the elements, out on its own.

No, no d no database administrator. A weatherproof,

[00:12:39] Mikey Pruitt: weatherproof enclosure. And an antenna.

[00:12:41] Richard Hipp: That's right. That's where it was used. And it was designed for that purpose. And what we found more recently is that with computers have gotten so fast that, and it's arguably gotten better and faster itself.

For many applications, SQLI is a sufficient replacement for the traditional client server database. Now, the advantage of a client server database, and I use Postgres as an example all the time, is that you can really scale it up much better, much bigger. You can have multiple concurrent riders and we've got all kinds of enterprise features.

Hot bail over and backups and so forth, and sgl, I just doesn't do those things because that's not really part of its mission. But the increasingly there, there's so many apps out there, the machines have gotten so fast that what SGL Light does do is sufficient for most use. So for the example, the SQ like website itself is of course backed by.

SQI that would be of course. And we get, I dunno, 10 10 requests per second of for non-static files that have to involve the database on average. Each one of those does on average about 200 queries. So we're getting up 2000 queries per second. And this is on just a rented shared server at line.

It's not a big machine and we get tens of thousands of visitors per day loading about 10 gigabytes or more content per day. So it's not a huge website, but it's not trivial either. And there are a lot of websites that are much smaller and they can easily use sq. The advantage of Carolina is, as you pointed out, it's so much easier to administer, there's less to install.

You can have in your head at one time an idea of everything that's going on. The idea is that each of us has a limited amount of bandwidth in our head. And the more of that bandwidth fraction that you use to think about how you're configured your database, the less is available to solve the actual problem you're trying to solve.

[00:15:08] Speaker 3: Right?

[00:15:09] Richard Hipp: And so if you can simplify the database that you don't have a separate server to deal with and config files and all of that, it's just a file on disk. That just, it simplifies the mental model to the point that you can think more deeply about the core problem. You can better solve your customer's problem.

A, a key differentiator of SQLite is the database file itself is a single file on disc. If you're working with MySQL, a Postgres or SQL server. Where is the database exactly?

[00:15:44] Mikey Pruitt: I like, especially if it's like running in a Docker container or something. You're like, I can barely find these

[00:15:49] Richard Hipp: files. Can you point me to where that database is?

If I wanted to make a tar ball of the database, how would I do that? Like even a simple backup that's not real, that's not a real clear thing. Whereas with SQLite I've got an icon on my desktop that is the database. And if I wanna move it somewhere, I just drag it. It's that simple. And it's, it, people are discovering that, having that simplicity of the mental model to be able to point to something, say this is the database, really helps them to think deeper about the problems we're working on.

Of course, the cost of that is that it doesn't scale as big because an SGL database is limited. In size to how much you can store in a single file. Whereas Postgres, you can spread the database across multiple disks or whatever you need to do in order to have truly massive databases.

[00:16:47] Mikey Pruitt: And, but you can optimize SQLI for speed, like using the wall mode and some of the other I'm just scratching the surface on this for an app that I was trying to build, a personal app that I was trying to make and I was like.

And it didn't need all of the performance, of course I wanted to give it a shot and it's working and it's fast and it's great.

[00:17:10] Richard Hipp: Yeah. As, go ahead. So many things. Wall mode seems a right ahead log. So the default behavior vest light is that it uses what's called a rollback journal at the beginning of each transaction.

As you start modifying the databases before it modifies a page, it makes a copy of that page. Into what's called a rollback journal. And so if the transaction fails, if you have to roll it back, or if you take a power loss or something like that on recovery, then you've got the original database and you can restore the database to its original content.

Write ahead log is the opposite, where it, instead of. Store making a copy of the original content. It writes the new content into a separate log file, the write ahead log or the WOW file. And then later on there's a separate operation called Checkpoint, which takes the new content and folds it back seamlessly into the original database.

So write ahead, log is a better approach. The default is still rollback though, because. Write ahead log requires a small amount of shared memory between every process that's using the database. And that works fine as long as all of your database users are on the same machine.

But if the database file is on a remote disc and it being accessed by two or more machines, they obviously cannot sheer memory.

And right ahead. Log won't work there and you'll get database corruption.

[00:18:44] Mikey Pruitt: But the funny thing is with sq LI being the nature that it is, and I've seen this with no SQL databases, it's if you had a multi-tenant app, which most apps are like, you have an account, blah, blah, blah.

[00:18:55] Speaker 3: Yeah.

[00:18:55] Mikey Pruitt: You could have a database for that account.

So they're technically the only people writing to that database.

[00:19:02] Richard Hipp: Sure. For. Does anybody really have multiple posts sharing them the file system of your phone? Don't think so. Not using at the same time. For sure. Don't, that's not a typical scenario. So Yeah, and people argue we should make the right head log mode or wall mode default.

But if we do that, I'm there. There are people who have their databases on a an NFS mounted dis somewhere, and they will suddenly start breaking and. I just I'm hesitant to do that. Just put the database with the code. It's fine. Yeah. But no, once you turn the right head log mode on for a particular database file, it remembers you only have to do that one time.

And so it remembers moving forward. And that's what most people do. And I believe that. You mentioned that it's now in Rails eight. And amongst the things they needed to figure out in Rails, the Rails people, was that, oh, we need to make sure when we create new databases, they're in wall mode.

Otherwise we don't get as good performance. Did I mention that wall mode does give better performance or for right performances,

[00:20:14] Mikey Pruitt: right. And the and the thing is, and I wanna call this out to the audience. I pitched this to Richard saying that I wanted to talk about the simplicity and how it's becoming more in vogue in the text sphere these days.

With. Things like SQL light making a resurgence and rails eight batteries included frameworks, type of stuff. And you were like, I don't know how much I'm gonna be able to contribute to that conversation. But I don't think you've made, maybe you just realized that maybe you haven't yet, but I'll call it out.

That you're, strategy with this whole database is the strategy that is now in vogue. People are finally catching up to you, 24 years later. You're ahead of your time then, and you're ahead of your time now, sir.

[00:21:02] Richard Hipp: Let's just say I need to keep things simple so that I can keep it in my head.

Okay. I just,

I I don't do well with excess complexity. I need to keep things simple for me.

[00:21:14] Mikey Pruitt: Yeah. And that's the case for everything like development, computers, technology, all getting very complex. And it's nice to see this resurgence happening. But I am curious what do you think people make as like misconceptions when they're thinking of, like going to build something, not necessarily an application but like maybe a, just a business in general.

What do you think some of the mistakes people make are?

[00:21:39] Richard Hipp: For building a business. Oh, you're you don't want to come to me for business advice. Okay you, that would be a mistake.

[00:21:47] Mikey Pruitt: You accidentally have a successful business.

[00:21:49] Richard Hipp: Oh, no. Yeah. It's divine providence. That's the only reason we're successful.

Okay. It's not by any skill of mine. No. It, I think being keeping things simple is, I think that's always been an important thing and this is why computers exist, is to keep things simpler. I don't know why people want to layer on complexity that just boggles the mind. And really there's a struggle.

There's a constant struggle and sq do we add this new feature? Which might be useful to some people, it's another API to keep up with. And there and once we add a new feature, I've gotta support it forever and it becomes more and more complicated. And so this is a constant battle.

The original version 1.0 of Lite had five APIs. There were five entry points into the library.

[00:22:51] Mikey Pruitt: I was like, read, write, update,

[00:22:53] Richard Hipp: delete, open, close. An exec I think and may, maybe one, a couple others. I don't remember what they were, now there's over 200 different ways to interact with the library.

And how do you keep track of all of that stuff?

[00:23:07] Mikey Pruitt: I understand you have more test code than act the code base, oh yes. The test suite is larger with your. Was it MMO, md? What'd you call it?

[00:23:17] Richard Hipp: MC, the aerospace. Yes. We have 100% MCDC test coverage. And yeah, we, when we, it takes an hour, a little over an hour running in 24 cores to run the entire test suite.

[00:23:34] Mikey Pruitt: So there's. There's all this pressure for you to add new features. Apple calls you like Uncle Tim calls up and says, Hey Richard, we really want this thing. Like how do you, I've

[00:23:45] Richard Hipp: never actually talked to Tim that I love, I'm sure

[00:23:47] Mikey Pruitt: I know someone from Apple. It's funny,

[00:23:49] Richard Hipp: we matriculated at Duke at the same time.

We probably bumped into each other at some point, but I don't know.

[00:23:58] Mikey Pruitt: But Apple calls somehow. Yeah. And they contact you and say, we would like to add this new feature. They maybe provide the code to you this is how we would like to improve it, and you and your team have to weigh this. Yeah.

Do we wanna do that?

[00:24:12] Richard Hipp: Yeah,

[00:24:12] Mikey Pruitt: exactly. So how do you manage that? How do you assess that it's worth adding or not?

[00:24:18] Richard Hipp: You have to, we have, there, there's no cut and dry formula. I don't have an algorithm to determine what to do. You have to weigh the advantages and disadvantage. For one thing, I have promised to try to support the code through the year 2050.

[00:24:33] Speaker 3: Yeah.

[00:24:34] Richard Hipp: So I got 26 years more of support. So anything I put in, I've got a support or, we're not even at the halfway point yet. And there's a lot of things that have gone in over the years that I deeply regret putting in.

[00:24:50] Mikey Pruitt: That you now can't remove,

[00:24:52] Richard Hipp: that I now cannot remove. Exactly. But, and so I look at those lessons.

I say, do I really wanna support this for 26 years? Is it, and I have to think, how many people in the world is this going to benefit?

What is this? Is this feature gonna solve more problems than it creates really? And I think and solve more problems than it creates in the long term. Yeah, it might solve one problem right here today, but what about all the problems it's gonna create across the next 26 years is we have to maintain it and there's bugs in it and we have to fix those and so forth.

And that's. I wish I had a good solution for how to decide what to do. That there has been feature creep. And so the interface has become much more complex over time and we've got like hundreds of compile time options that you can select. 'cause some people can go, oh, we really need this obscure feature.

I can give it to you as a special compile time option. That's all by default. And we do some of that. But even then, we have a bunch of if deaths in the code, which make the code hard to read, so

[00:26:05] Speaker 3: You,

[00:26:06] Richard Hipp: you've got to be mindful of that as well. I don't know. A part of the solution is to keep the design very simple and flexible to begin with and to the ability that you're able to foresee the future.

That helps. And I did. Part of that, accidentally. Some of it I did not do it very well. There are places in the file format that I desperately wish I had done differently so that we could extend them at this point. But it is what it is we have to live with the choices I made back in the early two thousands.

[00:26:46] Mikey Pruitt: I would say they're mostly good from what I can see. I'm sure get a little nervous every day when you have to look at that code again.

[00:26:54] Richard Hipp: The point is the database file itself is a well, well-defined format, and there have been multiple people who have written independent implementations for reading that file.

There could be people who've written ways of writing that file that I just don't know about. But there are mul independent implications of the reader based only on the spec, not looking at the code. And you can take a database file from 2004 and read in very la latest SQLI and it works fine and to some extent going the other way.

You can take a modern database and read it and write it using it. 2004 version of S two alike, as long as it doesn't use any of the newer features that we've added.

But there were a lot of mistakes like that. In 2004 all the Macs were still running Power pc, which is a big Indian processor, and the internet is big Indian.

And so I made the database big Indian. Of course since then, everything has little Indian has gone a little Indian. And so whenever you're reading and writing dude, you're always doing a by swapping, you wouldn't believe how many CPU cycles we spend by swapping in and outta the database. Why didn't I make it little Indian to begin with?

[00:28:16] Mikey Pruitt: Maybe in 2051 you can fix that.

[00:28:19] Richard Hipp: I don't know. If it had gone the other way, if the world had gone to Power PC rather than Intel, that would've been a good choice maybe, but I don't know.

[00:28:30] Mikey Pruitt: It sounds a lot like you're, this idea of simplicity is really just like our humanity, like what you could, you talked a little bit about, a little bit ago about the bandwidth of your brain essentially, and like you probably have most of the SQL like code base in your brain, or at least know like where to find sections and things like that.

But once there's pieces that won't. There's no room for, and you can't write tests for that are, that you feel comfortable with, then it's like off the table. That sounds like maybe the algorithm you're using, perhaps

[00:29:00] Richard Hipp: That's certainly part of it, yeah. That's not exactly the algorithm, but we'll take that as a good first approximation.

[00:29:07] Mikey Pruitt: You're like, not bad. Not bad for marketing, dude.

[00:29:12] Richard Hipp: No. When this comes up, I ask people, I ask the team, Hey do we really want this? What are alternatives and we talk about it for a while. A lot of times we'll come around with a way of solving the problem without changing code.

Wow. An example of this four or five months ago, somebody came in and said, look, you really need lateral joins in SQ a lot. And so I created a branch and I implemented lateral joint.

It's still on a branch. I have not landed it on a trunk. It works great, but I can't really come up with a compelling reason to use lateral joint. I've asked around, Hey, does anybody really need a lateral joint? Is this, it's part of the SQL standard. Okay, but does anybody ever really do it?

[00:30:07] Speaker 4: Why? Why? Why should I complicate the code with this?

[00:30:13] Richard Hipp: I keep the branch up to date. Every now and then I merge from trunk into the branch so that it still works, and maybe it'll land on trunk at some point, but I'm torn once, once I merge it onto the trunk and it gets into a release, I'm stuck supporting it until the year 2050. Do I really want to and I haven't reached a conclusion.

The algorithm has not yet converged.

[00:30:36] Mikey Pruitt: I see. Let's dig more into the idea that you just said about fixing the problem without changing the code. So in, in the example you mentioned, you're wrote some new code but have yet to merge it into the, to the core. But what are some other things that are.

Like not fixing the code that solved the problem, like documentation, things like that. What, right?

[00:30:59] Richard Hipp: Document things better show people how to solve their problem without the feature they're asking for. Show them how to use existing features to solve their problem.

[00:31:08] Mikey Pruitt: Yeah, so we use, we at DNSFilter, we have a application we do DNS resolution.

And a lot of times people ask us for feature X or Y and a lot of times it's if you use feature Z and R in this way, you get feature X. And they're like, but we want x

[00:31:27] Richard Hipp: And I come make, yeah, but I wanna support this for 25 more years. If you're gonna pay me to support this for 25 years, we'll talk otherwise.

[00:31:37] Mikey Pruitt: So SQLite is really about its com lack of complexity, which results in very high reliability. So do you think this simple by design naturally leads to reliability?

[00:31:54] Richard Hipp: Let's call it an. No, not natural. You can still have very simple software that's very unreliable. And that's, and it's also possible to build complex software that is very reliable. I was gonna, my second thought was, oh, we're gonna say that simplicity is a necessary but not sufficient condition for reliability.

But I think that simplicity and reliability are correlated strongly. I think the best thing to do is to keep things as simple as possible. I saw I was watching a, another an interview on YouTube. Somebody was walking, some podcaster was walking through the SpaceX facility with Elon Musk and Elon Musk was saying, and I thought this was a great idea.

He said he's constantly pushing engineers to take things off of the rocket. And he says, if you're not having to add back about 10% of the stuff you're taking off, you're not taking enough stuff off.

[00:32:56] Speaker 3: And, you

[00:32:56] Richard Hipp: know, I don't,

[00:32:57] Mikey Pruitt: so simplicity is it's strongly cool. Crazy, but

[00:33:00] Richard Hipp: even crazy people have great ideas and he does land rocket ships.

[00:33:03] Mikey Pruitt: Yeah, that was very important.

[00:33:05] Richard Hipp: He's worth listening to, yeah. Take stuff off. What can you reasonably remove from this product? And it still do its fundamental job.

[00:33:12] Speaker 4: What is your

[00:33:13] Richard Hipp: core functionality? What are you trying to what? What is the problem that you're really trying to solve, and do you really need this other feature in order to solve that problem?

[00:33:24] Mikey Pruitt: A hundred percent. Simplicity is strongly correlated to reliability?

[00:33:29] Richard Hipp: I would say so, yes. But

[00:33:30] Mikey Pruitt: simplicity is also a struggle in itself to retain, and that's, but you

[00:33:36] Richard Hipp: want, the point of this is to improve humanity or to promote the flourishing of humanity. And so you want, you get all this feedback from a lot of people saying, we need this, we need that, we need this and you want to provide for these needs.

But sometimes it's better to say no. What I have discovered as in being a leader of an important project like this is that the most important words of a leader is no, it's very important to say no. And looking back over the years, I haven't said nearly as much as.

[00:34:17] Mikey Pruitt: That's definitely gonna be a clip from this episode. And I, and real quick I seen a, I guess an interview with Elon Musk. One, a reporter was walking around with him around the, SpaceX facility, and he was telling him like, you know how things operate. And the reporter said, I forget exactly, but he was like, why don't you just do you know this thing?

And Elon goes. Huh. And he like walks away and goes to tell some engineer, what the reporter just told him. So it's solutions can come from any angle.

[00:34:51] Richard Hipp: Yes. And that happened. I'm, that's happened to me actually. Yeah.

[00:34:56] Mikey Pruitt: Fun story there or nothing you can say.

[00:34:58] Richard Hipp: It's just a story.

It's not worth repeating. No, I but no, I've I was talking to back years ago, I was talking to I was in in Virginia talking to a OL remember America Online?

[00:35:11] Mikey Pruitt: Oh, yeah.

[00:35:12] Richard Hipp: And they were out of, thereby Washington, just west of Washington I forget the name of the town. Anyway, I was up visiting them and I was talking about this or that feature, and I was talking about, and I was talking about some new feature I put in sql.

I in mid-sentence I read this, no, there's a bug in this feature that's not. Logically sound, you're like, I'll be right back. And I, without breaking stride, I managed to shift the conversation around and then go back and take that new feature back out. But similar kinds of things. Yeah. Just some people have come in and said, Hey, have you thought of doing this?

And I said no, that won't work, and here's why. And. Oh wait, maybe that will work.

[00:35:48] Mikey Pruitt: As you're explaining why it won't work, you start to realize, actually that's a great idea. Work. Actually, I say that to my son, he's three. I'm like, that's a great idea. What are, things that just to get him a win, give him a win.

So we

[00:36:00] Richard Hipp: appreciate all the feedback we do.

[00:36:03] Mikey Pruitt: So let's talk about the adoption of ESQLite real quick before we go. I don't know how many installs there are. Maybe you do, but it's a massive deployment base. The code's free, available, easy two to install. You can run a simple command and get it in almost any software package.

How do you think that adoption happened? Like it's probably the most well used database on the planet. How do you think that happened? Plenty. I think it was accidental, but there has to be some, yeah.

[00:36:31] Richard Hipp: I'm gonna claim that there are more instances of SQLite running right now than all other database engines combined.

Of course, I can't prove this, but think about it. There's, multiple instances running in your iPhone as we speak or your Android phone. They're running in this web browser that we're using to record this podcast. They're in all of your devices. They're probably in your microwave oven, it's certainly in your car.

They're everywhere. There have been a couple of studies of this and roughly speaking, half of the file system io on Android and on iOS is first approximation. Files I is either media files, videos and audio files and stuff, or else it's SLI databases. Now there are other things happening as well, but they're insignificant in comparison.

Yeah, it is the most widely used ever. How did that happen? And o of course, once again, I'm going back to divine providence. I wish that I could say that I had planned it this way and it was gonna work out, but we had the right product at the right time. It was there, it was starting to mature just as iPhones were taking off, or just as cell phones were taking off.

Android and iOS were just starting to spin up. When when SG Lite was getting started and it was the only SQL solution available on the phone at that time. I say that there, I think there were some others that were obscure.

[00:38:15] Speaker 3: Yeah,

[00:38:15] Richard Hipp: early on I got a call from Symbian os.

Do you know about Symbian?

[00:38:22] Mikey Pruitt: Yeah, they were one of the other handset makers, like Motorola or something,

[00:38:26] Richard Hipp: right? Yeah. That was the operating system in Nokia phones for a long time and several other brands as well. And they're based out, they were based out of London and they called me up and said, Hey, we wanna have a meeting.

Can you fly to London? And apparently they had. They had their own proprietary database. They wanted to move to an SQL solution, and they found 10 to 10 different SQL solutions with their database on Ian Os. And they had a big bake off where they were gonna test the performance and features of them all.

And as they tell me the other nine, they had talked to the vendors and gotten them to help optimize it and do well on their benchmarks and stuff. And I'd never heard from 'em. They didn't talk to me. But SQ still won. And we came out on top and they wanted to make SQ the default database in os.

And that, that was, part of what helped me convert and make SQ into an actual business. But the point is there were several others at the time, but SQ was sufficiently better that. We were able to beat out all of the competition and today is, are there any other SQL databases that compete with.

SQLI, yeah, sure. There's a lot of maybe

[00:39:49] Mikey Pruitt: homegrown one-off type of things maybe, but yeah,

[00:39:52] Richard Hipp: there's a lot of client server databases. There's, there, there's still definitely a place in the ecosystem for Oracle and SQL Server and Postgres and my sq l Those are very important products.

We're not, I don't claim to replace any of those, but are there any other embedded s. I don't think there are. If there are, I don't know about them.

[00:40:12] Mikey Pruitt: So a little bit of divine intervention, a little bit of right place, right time. That simplicity mindset that you just like as a person.

[00:40:21] Richard Hipp: If there's no I'm utterly convinced that if I had set out to actually make this happen, I would've failed utter.

It

[00:40:27] Mikey Pruitt: would

[00:40:27] Richard Hipp: never happen. Richard,

[00:40:30] Mikey Pruitt: you're crazy. This is never gonna work.

[00:40:32] Richard Hipp: Yeah, no, it is crazy. And people and part of the reason it was successful I mentioned earlier that none of the teams has any formal training in database technology. At the time, all the database technology was happening at up in Cambridge, at Harvard and MIT or out on the west coast at uc, Berkeley.

And if you weren't. Plugged into one of those schools, you really didn't have access to the information. We didn't have Google back then. We couldn't just Google and pull up the papers. You had to actually go to a physical library and pull books and articles, and I went to the local university library and there was nothing that I could find.

And so I had to invent SQLI entirely on my own. And, which was good because if I had studied the literature, I would've quickly realized that this was. Impossible for one person to do that would've given up the task from the very get go

[00:41:28] Mikey Pruitt: and that no one would probably use it.

[00:41:30] Richard Hipp: Yeah. And it would never work, right?

So I would've never attempted it if I had known what it was I was getting into.

[00:41:37] Mikey Pruitt: Yeah, the best things are accidental from what I've seen. I'm curious. So I've seen cloud hosted subscriptions for ESQLite these days, which I think is crazy. It's an odd thing to have. I don't really

[00:41:49] Richard Hipp: understand that.

[00:41:51] Mikey Pruitt: But are you've seen them too? So I'm like, yeah. And actually when I was, trying to get some of the performance features teased out of my Python code, they had good articles on how to use SQI, performance and blah, blah, blah. Which was helpful, but I was like, but I, why would I use this cloud thing?

But anyway, my point is there is, there's something happening where, things like SQLI are. Becoming a cloud hosted, solution. Somebody's gonna be providing this to people. But I'm curious, like what else do you think is around the bend for SQLI, until 2050 at least.

[00:42:30] Richard Hipp: You're asking me, I didn't predict sq I was gonna be successful.

You're like, have no idea. I, SQLite in rails eight by the default. Really? I'm honored. I really am. Who knew that was gonna happen? I don't know what the future holds.

Every MO for the longest time. I thought this has been so much fun working on SQLI and getting to develop it, because really at the end of the day, I'm just a coding, gee I write, I really enjoy writing software. Even if I had to have some other job, I'd write software on the weekends just because I enjoy doing it, the fact that I can get paid to do it, that's just really special.

Every morning I wake up and think this'll be the day somebody comes out with a revolutionary new product that makes SQLite obsolete and the business will kinda shut down and that'll be that. But it's been a fun ride. And I think this like every morning, but so far we're still here. I don't know.

Will somebody come along tomorrow and have the revolutionary product that replaces this to like maybe. But I if, and if I knew what that was, I'd try and beat them to it. But I dunno what that is.

[00:43:45] Mikey Pruitt: I accidentally did this. Maybe I'll accidentally do the next thing. I don't know. Yeah. So I'm curious one last question.

You have a lot of simplicity and reliability baked into your business, into SQLite and your corporation is HWAC i.com, which is Ed wci,

[00:44:07] Richard Hipp: that's the official name is Hip, Wyrick and Company, Inc.

Achi is the acronym. Wyrick is my wife's last name.

[00:44:19] Mikey Pruitt: Yeah, your wife Ginger plays a role and she's like a musician from what I can tell.

[00:44:23] Richard Hipp: She is music faculty at the local university and a musician, but it's a, we're yin and yang, a musician and a coding geek. But but it very complimentary roles and I picked up so much music, living with her for decades out of mine and. And she's picked up a lot of computer stuff.

So any musician in town they know to call Ginger to find out if any musician in town has a computer problem. They end up calling Ginger to get the solution to Good to you. 'cause she's picked it up. She's not a programmer or anything like that, but she's picked up so much stuff and she can explain it to them as a musician, whereas I could never explain it to them.

[00:45:07] Mikey Pruitt: She can translate it into English, basically, is what you're saying.

[00:45:09] Richard Hipp: Exactly. She translates into human.

[00:45:12] Mikey Pruitt: Yes, human. What do you think some of the habits are that you have that, accidentally made this a successful endeavor?

[00:45:20] Richard Hipp: Oh yeah. I could do a real lecture on that. Oh here, just some design rules solve more problems than you create.

That's the key to success in anything. Solve more problems than you create. And if people would do that more, they, the world would be a better place. And the other. They're not willing to take the blame when they do something wrong. It's always somebody else's fault. My life isn't going well.

It must be somebody else's fault. Who can I blame? Even if it isn't your fault, you ought to take the blame yourself. If you want to work past it, you've got to you, you've got to take responsibility.

[00:46:10] Mikey Pruitt: I am waiting on a third one. I feel like there's one more and one more hat on there.

[00:46:13] Richard Hipp: Oh yeah. You've given me if you've given me five minutes notice, I could have made a list, but

[00:46:18] Mikey Pruitt: I don't really have any other questions. Richard, is there anything else you wanted to say? I think you really ended it on a high note, like how to, just be the type of person that.

Has their life set up in a certain way that allows success to happen, to free your mind from the things that are unnecessary scaling your database, for example, that give you the freedom to just be the person that can achieve success. And you've done that and congrats on that.

[00:46:45] Richard Hipp: Thanks. It's, we've, and I speak for my whole team in this, and I talked earlier about how I just enjoy doing it. And I really, I shouldn't speak for other people. The whole team really, I think is the same way. We're the kind of people that we program because we love doing it and that we can get paid.

Doing what we love doing is just unbelievable. It's kinda a professional athlete, think, a lot of people pay good money to play golf. A few people get paid to play golf. Exactly. We're in those lucky few.

[00:47:21] Mikey Pruitt: Exactly. Richard, thank you for your time today and thank you for SQLI and it's continued success and the continued success of you.

But yeah, I just appreciate your time and hopping on this tiny little podcast for DNSFilter.

[00:47:35] Richard Hipp: Oh, thanks for hosting me.