What you're about to hear is an interview that I had with legendary software developer, race car driver, business owner David Hannah Meyer Hanson. We talk about SQLite in the beginning, and then we talk about stoicism and conceptual compression and the one person framework. We talk we talk about it all. If you want to learn more about SQLite, I am creating a course, high performance SQLite dot com, and you can find everything you need to know about SQLite Lite there. Enough about me.

Let's roll the interview. I tweeted at you, like, an hour ago, and and here and here we are. So I I tweeted at you because I saw Daniel Vassalo talking about their instance of Campfire, and I'm I'm a member of his community. And so, and I saw that he was running stuff in the SQL SQLite command line, and I was like, yeah. I should do this now.

It's been on my list. I'm just gonna tweet at him. And I said, hey, DHH, do you wanna talk about this? And you're like, yeah, let's do it today. So here we are.

Thank you so much. Yeah. My pleasure. This is one of the advantages of having a mostly empty calendar. You could do things when they pop up.

So Yeah. I'm really excited about SQLite, so I love talking about, things that I'm excited about. So let's talk about it. So speaking of, before we dive in, your video looks amazing. Your audio sounds amazing.

Is this your new Linux pieced together machine that is just working perfectly? This is my Linux machine. I will credit, though, my, Shure microphone and my Sony camera. Those two things just pluck right in, especially that Sony camera. No drivers.

No nothing. Just USB c straight in, and it pops up as a as a webcam in the OS I run it on. But this is running on Linux, and it is kind of amazing. It just works. It just works.

Well, that's that's wonderful. So speaking of just works, SQLite, it's good now. It's been good maybe forever, but now we're all discovering it again. You know, the guy wrote it in in the year 2000, and we're finally discovering it. So the reason I wanted to talk to you is because y'all did this big, you know, once.com, like, hey.

We're changing everything again. And the first product that came out was Campfire, and Campfire ships with SQLite. And so I kinda wanna hear about a little bit of the behind the scenes of how you ended up making that decision and kinda what some of the ramifications have been from there. Sure. So I think what's really interesting about SQLite is, as you say, it's been around forever, and it's had its niche.

This was a kind of database you would insert into a, standalone application that would just run for 1 user. And that was sort of the niche it's owned for a long time. People have used it for a bunch of other things, but I think a lot of developers had that in mind. Unless I'm developing a client application that's just for 1 user, SQLite is not for me because you can't use it on multiple machines at the same time, yada yada. And then what happens is computers get really fast and they get really wide in the sense that they now have a lot of cores and the SSD drives are fantastically fast.

And all of a sudden, the preconditions for using SQLite for more than just one user are there. Again, I'm sure people were able to do this in the past, but now it feels more accessible in a way that just kind of intersected exactly at the right moment for us with Once. Mhmm. So Once is run SaaS, essentially run web software, but on your machine. And that sets it up in a environment where it's not single user, it's multi user.

That's the whole point here. You're not gonna chat with yourself. You're gonna chat with other people, but it's single tenant. Mhmm. And I think that's really the switching point that as I observed it with SQLite is that there's a bunch of web software that now makes more sense, could make sense as single tenant software that you run on your own machine.

That's obviously what we're trying to explore with 1. Then there's another path of this that I think is also interesting, which is to use Lite in the beginning of even a multi tenancy setup just to get rid of a bunch of complexity, maybe get rid of a bunch of cost. We can talk about those two things. But when we set out to do once, we had a bunch of things that were unknowns. First of all, how are we gonna get this on people's machines?

My god. Do they need a special machine? And then we've dug into Docker. I'm like, oh, actually, this fits really nicely if we just build a bit of tooling around it, if we build an auto updater. That's sort of like if you're auto updating your operating system or a single user, application on your machine.

Okay. That kinda works. But what do we do about the database? Oh, shit. Do we have to now run a second docker image that then runs my sequel or postgres?

What if it gets wedged? There's just a bunch more moving parts. And what we're really trying hard to do with Once was to make this so simple that it kinda couldn't break. Because if it was gonna break, people were gonna write us in, and the business model of once just wasn't designed to support that. We sell Campfire for $399, a one time cost.

There's not a lot of, not a lot of room in that. Room in that. Yeah. Exactly. For someone to go, like, can you help me debug my Mhmm.

Postgres instance? No. I I can't help you with that. So I was really gung ho about the idea that we were gonna just take out moving parts. How can we take out more moving parts, more moving parts?

How can we simplify this so much that it's a single docker image? And if it somehow gets wedged, you just restart it. Mhmm. And there's no dependencies. There's no docker compose.

There's no any of these other things. And SQLite, of course, just fits beautifully with that. So we started exploring it early on, and we almost abandoned it. Really? Because we dug in.

And especially at the time, I think we weren't versed in SQLite. There's some defaults in the SQLite database that are suited for its historical purpose that isn't so well suited for web applications. One of one of its great strengths is its great weakness. It's extremely backwards compatible and the defaults are kinda bad now. So yeah.

Yes. At least they're not suited for multi user web software. That wall is not turned on by default and there's a handful of other things you gotta turn on by default. So first, we had to find what those things were. And that's what's so interesting about what's going on with SQLite.

The general awareness of what's required to use that database for the kind of stuff we're using it for is just spreading like wildfire. Like, literally, 1 year ago, I was trying to figure things out. Like, how do we do this? There wasn't that much information about that specific use case. And now there's so so much more information.

And it's it's expanding, and we're trying to change, and not just trying, we have changed rails already to make it such that the SQLite you get out of the box is configured in the right way, in the way that works very well for for website ops. So anyway, we had to go through that. And then we ran a bunch of, performance tests on it, and we found that there were a handful of things that we had to tweak. These were things around, long running transactions. A few other things were the standard, to be honest, inefficient way of doing things sometimes in rails, bit in a way with SQLite that wouldn't have bit with MySQL.

Mhmm. Because especially on the transaction thing, you really don't wanna do you really never should. But, you don't wanna do a lot of computation inside of your transactions. You don't wanna do a lot of callbacks. You don't wanna do anything that really takes a lot of time because as soon as someone goes, like, I wanna have a transaction and it's for right, There's contention, right?

There's one file and and we gotta do all this, stuff. That's where SQLite's limitations come in. But they really aren't that big of limitations if you just flip your thinking a little bit. And to give you a specific example, in rails, we have something called callbacks where when a new model is being saved, it can call back and then it could do a bunch of work. And that callback happens inside the transaction you're being creating in.

So if you go back and you do a bunch of stuff in that transaction where you're pulling things from the database and maybe you're working on it a little bit and then you go back, that's a long running transaction in the SQL like sense of it. It doesn't doesn't usually matter with with MySQL or Postgres. You don't notice those things. But we switched a handful of invocations that were written in that naive style to use insert all, which is not new, but relatively recently certainly recently refined API for doing bulk operations with active record, the, object relational mapper we have in Rails. Mhmm.

Where everything just happens in one execution. Right? Like, we're not fetching a bunch of, objects and we're not asking them to fetch data and then write the data. It's just very efficient. Mhmm.

And so we we had to find what those points were, and we found them basically by stress testing the whole thing. We set up this old rig to simulate what's gonna happen if you have 10,000 users on one box and they're all trying to chat at the same time. Where is the contention? And it took I don't know how long it took. It didn't take that long to figure out, okay, here are the hotspots.

Here's what we gotta do with those hotspots. Now that we know those hotspots are and we've, identified, SQLite is no longer actually the, bottleneck. It ended up being other things that were the bottleneck, like WebSocket connections, stampedes, those kind of things. But we ended up in a situation, which was kind of the dream situation, where we could imagine a very active chat instance with 10,000 users on single box. So now we had a envelope where we could go from, I think our minimum requirements is like 1 vCPU, 2 gigabytes of RAM, that'll support, I think, 500 chatters simultaneously or something like that.

These are quite, aggressively low, benchmark numbers because we were saying, like, each chatter is someone who says something in a room every second, which that's not how it is for most chatters. Right? But, anyway, so we can go from that on on, like, a cloud VM droplet style thing, and then all the way up till you can run the same piece of software for 10,000 users on a single box. Because that is the constraint. Right?

SQLite enforces the constraint on you. This is gonna run on a single box. You're not gonna have Mhmm. 5 application servers that are all trying to access this one file. That doesn't work.

But where we've gone from with SQLite is 10 years ago, how many users could we get on one box at an affordable, not exotic hardware kind of level? I don't know what the number was, but it was a lot less than 10,000. I'll tell you that. I mean, just the number, of course, you have access to and and all these other hardware advancements weren't present. So some of the rediscovery of SQLite is that the future has caught up with what it's capable of doing.

It's allowed its envelope to be so much larger because computers are so much faster. And that's one of those things I find so fascinating. We've explored this domain with other things. We've done, solid q and solid cache, which now instead of using RAM for, job management and for caching, it uses SSDs because some of the fundamentals have changed. Like, what was the speed of storage 10 years ago versus what is the speed of storage now?

A lot of technologists, I think, are not keeping up with some of these things that actually do change, but they change sort of gradually and suddenly there's a new capability drop where you can go, oh, SQLite works in production, works on a real system where people chatting on with thousands of concurrent chatters. That's kind of amazing. It's amazing that we can use the progress of technology to simplify the stack. Now Mhmm. I like MySQL a lot.

I've been using MySQL for literally 25 years. It's a great database. It works very well for Hade. It works very well Basecamp. These are very large systems where we have massive amounts of application surface.

So that's fine. That's that's still there. No one's taking that away, But we're now being gifted this opportunity that one style software, single tenant software, early stage software can run on SQLite and have essentially no apologies about it. I feel like a lot of your a lot of your career has been really focused on, like, eliminating complexity, especially needless complexity. I don't wanna talk about TypeScript, but we could talk about TypeScript.

But eliminating complexity, you've got this concept of, like, conceptual compression. And I feel like SQLite has kind of fit into the DHH world and the and the the narratives that you have throughout your whole career, but especially right now with the cloud exit as well. Because you can imagine, hey. You buy this software, but make sure you sign up with some cloud hosted database provider. And it's like, oh, well, shoot.

That's kind of against the point. And so I feel like this all kinda happened in stream with your current and historic, like, thought processes, and it just removes this entire piece of complexity from the stack. Did that, like, did that light you up inside to to be like, it's just a file. There's no there's it's just a file. It no.

It's amazing. And it's amazing for exactly the reason you say. It's the, conceptual compression of what even is a database? How much do I need to think about this thing? I mean, if you're setting up and you're running a demon, a long running process that has to be fed and tendered to and cared for, that is that's just gotta fit inside your brain.

Like, that's a bubble in here. Right? And that bubble, whether it's large or small, it takes up room. SQLite does not take up room in the same way. Again, there's a couple things you gotta know and you gotta set some things up and then But on an operational date basis, there's just a lot less to think about because it is just this file.

A lot of things that are complicated or required more learning or skill to operate these I was about to call them historic databases. That sounds like that's not what it is. But these traditional SQL database, let's just call them that, It's just, it's wonderful to be able to pop that balloon. And then, of course, on top of that, there are just use cases like we have with Once where it's just like a perfect fit. Like, we're giving software to to other people to run.

They have to run it on their own machines. They it just can't have the moving parts because if one of the parts breaks, as we've talked about, that's gonna be a support burden. And then the model doesn't work. So I'd actually say SQLite is one of the supporting pillars of why we're able to do something like once. Another supporting pillar is Docker that we've been able to take whole systems and put them into a single, container, and now you can run those.

There's a bunch of factors where I would not have attempted once, like, 10, 15 years ago. I remember talking to the GitHub crew when they were doing GitHub Enterprise in the early days. And I took one look at what that required back in the day before Docker, before SQLite, before all these other things. And I just saw it like, wow. That's a lot of work to be able to have a piece of soft web software that you install on on customers' own computers.

I wish it wasn't so hard, but we're not gonna touch that. And we it's actually something we've been asked for countless times, over the years. In fact, even the White House at one point, I think when Obama just got elected, someone from the White House reached out, oh, we've been using Basecamp for this, that, and the other thing. Can we run it inside the White House? And it was one of those things where, like, that's a very patriotic thing to do, support our government and let them run our software.

And we just had to say, no. I'm I'm sorry. I can't do that because we're just not set up to do that. So it really came at a great time for once. And I also think it comes at a great time for the industry.

I think we we we're sort of being pulled in both these directions where on the one hand, the web in terms of its complex or conceptual complexity is getting worse. Like, it's getting more complicated. There were ever more things you could know about, dive into, become an expert at. It's daunting. Yet at the same time, we also have these fundamental improvements in the underlying technology where you have to know nothing to reap the benefits.

SQLite as sort of chaperoned by faster hardware, more cores, SSDs is one example of that. Mhmm. Another example, of course, I've been, hugely fan of is no built. This idea that browsers themselves have gotten incredibly good. Just in the last 3 years, browsers have just taken huge bites out of the complexity that's involved with front end development.

And we're still sort of, I don't know, catching up to that, some faster than others or some more willingly than others. Perhaps you would say. I'm very willing to let, for example, a browser engine, eat some of the complexity that I've been used to dealing with on the front end. And I'm very happy to see that faster SSDs and more cores is eating up the complexity that does involve running a database. And all of these things are coming together at the same time, and they must.

They literally must. Because if these things are not enabling us to compress the complexity, heads are just gonna explode. Mhmm. Or building for the web will no longer be feasible for the individual developer. And that to me is I will stand on that barricade until the last straw, the last fight, the last boss battle of complexity here.

We cannot give up on the Internet being something that individual developers can build for and be competitive on. I built literally the entire business we have at 37 signals from Basecamp forward on that premise that I, as a single developer, could know enough about enough things to be competitive with the biggest companies in the world. And I think that is more than ever just crucial that we don't hand over the Internet to a handful of super conglomerates who can have these supersized teams and can have these very thinly sliced specialties where, like, oh, I am a front end, framework engineer something something. And I will be one of 19 other slices to create this one product, inside a big company. And I think, unfortunately, and this is what's so interesting, SQLite is obviously open source.

A lot of these other tools that we're using are open source, but even within open source, there's a bit of a battle where a lot of open source software is coming from large companies. And that's great in some sense. Right? Like, we want large companies to give back, and we want them to contribute to the ecosystem. But what can also happen is that their frame of mind, their viewpoint is contributed with it, and we end up in a place where we actually don't really wanna be on closer reflection.

And that's what I love about SQLite 2. I think the team behind it is something like 3 or 4 people and they don't make an outside contribution. They've been working on it for, like, 20 years. And I'm like, amazing. Amazing that something like that not only is is feasible, but to me is sort of a high watermark bar for, like, one kind of development.

I mean, Rails is, of course, is not that. I mean, we have 6,000 contributors or 7,000 maybe at this point. It's a very different kind of things. But I love the fact that something like SQLite can be so good, so universally recognized, and it's literally the work of, like, 3 or 4 people. Hey.

I hope you're enjoying this. Just as a reminder, you can learn more about SQLite at high performance SQLite dot com. I'll get out of your way. Back to the interview. It it is wild.

And if you read if you read through the documentation, the doc the docs are written by, I assume, the one guy, d Richard Hipp. He goes by initials as well, so you'll have that in common. You also have in common that he writes his docs with, like, a point of view. Like, they're they're funny, and they're conversational, and they're engaging. And especially when you get to the, when you get to the section about types and how how SQLite is just like, not whatever you want to put in here, we'll take.

We'll we'll take we'll take anything you want to put in here. At the very bottom, he's like, we have introduced strict tables. Basically, like, if you're into that kind of thing. It's kind of like the the tone that he he puts in there. And so I do I do really appreciate, I think it's I think it is 3 guys.

So I appreciate their, like, dedication to it. It's the it's the archival format of the Library of Congress, for goodness sakes. So and they're like, they have committed to supporting it through 2050. And I imagine they'll reach 2050 and be like, oh, we're not actually gonna give up. We just, you know, we just thought that was far away, so we said that.

What's so amazing about that story to me is it's such a beautiful counterpoint to this hysteria that open source is in a great crisis and that the whole Internet rests on, like, 3 dudes and that's somehow terrible? No. It's amazing. Can form the basis of something that's used by billions of devices around the world. That's not a flaw.

That is a celebration of human creativity, ingenuity, carrying the meaningful burden, all of these other things. And I I love that, at least in my head, as the counterpoint to this hysteria, they're like, oh, open source is in such a crisis. What open source needs is just like more and more money, bigger, bigger teams. No. They don't.

They need, We need less. We need less. And SQLite is to me sort of on the pedestal of that example of like, would SQLite be better if somehow Microsoft gave them 20 developers to add to that team, to add a bunch more features and do it? No. No.

It would be worse. It would be worse. And not because of Microsoft, but just because of the dynamics of that. Some pieces of software, and I'm thinking about another piece of software right now, Redis, who for a very long time was also run by 1 dude Yep. Who Until it wasn't.

And then what happened? And then what happened? He stood the line, and then he went off the barricades, and other folks took over, and then that went in some other direction that I'm not particularly fond of. Right? Mhmm.

I go like, I hope the SQLite crew never does that. They seem extremely principled, so I I doubt. At this point, you know, 24 years after, I I doubt they're gonna, you know, sell it off to Microsoft at this point. And one of the, like you talk about the single person framework. I think you, you know, you had a keynote recently and a big slide that was like the one person framework.

There's something pure about that, and I find that in in SQLite too. One of the quotes from the creator is if I had known that you're not supposed to write your own database, I wouldn't have. I I wouldn't have written it. But I I didn't know that. Like, I didn't I didn't ask any experts.

I didn't know you weren't supposed to do this thing. I just had a need and a curiosity, and I just I just wrote it myself. And that feels that feels like that feels old school to me. And I'm curious from your point of view, maybe stepping just a a half step outside of SQLite. You've talked about SQLite and browsers and Docker and the one person framework.

Like, what what do you see coming for the 1 or 2 person team that's like, hey. I wanna I wanna run my own SaaS. You know? We talked for a long time about there's a million Italian restaurants. You don't have to take over the world.

You just need a little thing to so, like, what it what do you see you know, I guess y'all are executing a little bit on that on once. Like, you're having a little fun doing the the 2 man thing again. But, like, what do you see for the individual out there with these new They have to control complexity. Complexity is the thing that will eat you up and spit you out when you are a small team. You can't do all the things.

You can't have all of these moving parts because they all need oiling, they all need tender, they all need maintenance. You need to reduce, reduce, reduce, reduce. And this is why SQLite excites me so much. I mean, talk about no moving parts. They're literally just a file.

Just a file. You could say one file, but at these days, it is 3 files on it and with the wall and so on. But it's 3 files. It's not a big thing. That's beautiful.

To me, no build has that same quality. Right? What if you just wrote text file and wanted to add something to it, no pen is still working. And it's still working. And you opened up that text file and wanted to add something to it, no pen worked.

It would work. It would literally work. And that's the beauty of the Internet. If you were disciplined in like 1995, how you built things, 1995 how you built things, it would still run today. Like literally 30 years later, it would still run today.

And then you look at what is considered perhaps in some circles the best practice way of setting things up and it won't run-in 5 minutes, let alone 3 months. Inconceivable that it will run-in a year from now because it has just atrophy through the dependency trune and like all of these things. And I've, invested in a handful of, startups in Denmark, and I I see some of it there where I go, like, you're a tiny team. You no. That's not the thing you should be running.

Mhmm. That's not the thing you should be spending your time on. You should be spending your time on as a single or tiny team of developers, creating value, which really I actually hate that word. You should be spending your time programming features that your customers will care about. Yes.

Right? Like that is the thing that's gonna set you apart. You're gonna have a very different velocity than some big honking corporation. Even than 30 times signals. Like, we move substantially slower now than we did at 4 people.

We can do more things at a different scale and with more users and so on. But if a dedicated team comes in and picks very simple tools and they operate in a box of 3, 4 people and they commit to the simplicity of that, they're gonna run circles around almost anyone. Again, not on all the parameters. This is the whole blue ocean strategy thing where you you pick the things you're gonna be better at. But if you pick the things of we're gonna double down on simplicity, we're gonna double down on some tools that don't constantly churn over.

It's incredible what you're capable of doing. And this is the great sort of two way split, which way western man. Where on the one hand, you have the path that says it's never been better. Browsers have never been more capable. The basic tools have never been more amazing.

Ruby, to take just one example I care about, has never run faster. The language itself has just gotten 3 times faster since Ruby 2 is running on computers that are literally orders of magnitude faster than when I did it on a single box in 2004, and was able to build Basecamp off that. Right? So the capacity and the capabilities that you have today are just mind boggling. But then the second road goes like, oh, what if we took all those spoils and just squandered it on casinos and pokers and blackjack and nonsense.

And you end up in this way where you're like, no. You took all the spoils and you feathered them away. There was nothing left in the end that most users care about. And this is one of those great. I mean, I get into, I was gonna say fights, but let's just use a polite word, debates on Twitter and the internet often.

And sometimes it'll be about these topics of simplicity and some folks will point out, like, Oh, you're running no build on your front end. That means you have a 100 100 files. Like, this is gonna be terrible, and it's gonna be slow. And I'm just like, no. If it's fast for the user, that means you factor in all the things and the download and the this and the that and so on.

They're not gonna care. Mhmm. You're gonna care. I'm gonna care because simplicity for me is the enabling fact that it allows me to do all the other things I care about, like running feature teams with 2 people. That's the kind of stuff that I care about.

If if the output of that is so good that the majority of folks don't notice the difference, Or if they notice the difference, they don't value it in a way where they're gonna pick one thing or the other. I'm not talking about, like, let's go back to the stone age and we're gonna build everything like Craigslist. Although Craigslist, I would like to say, is an example of the amazing resilience of literally not changing something since 1995. Right? Like, it looks identical almost.

Mhmm. And for the kind of people I've met who use Craigslist, I've never heard someone say like, I wish it had a purple gradient. Mhmm. Like that. Or a loading or a loading skeleton.

Or a loading skeleton or any of these other things. Right? So I think a lot of this, anguish and existential dread, certain quarters of the web development in particular feel, it's all self inflicted. That doesn't mean it's easy to route around, but it is it does mean at some fundamental level, it is optional. Now contrast that to developing mobile applications for iOS, for example.

There's just a tool chain and a setup and machinery and framework that you handed to you. And, I mean, you can question it. Good luck with that. You're gonna take what you're given, and you're gonna have to build something with that. And you don't have a lot of choice in the matter.

The web is so freaking amazing because whether you want Postgres or MySQL or Mongo or SQLite, Mhmm. No one is any wiser. It all gets compiled down to a h a piece of HTML that's sent off to the user. And if that piece of HTML is fast enough, well designed, solves an interesting problem, they will clap in their little hands and pull out their credit card from their wallet and slap it down on your form. Mhmm.

That is so amazing and so unique in literally the history of computing and certainly the history of computing as it is today, that it just blows my mind on a regular basis how little appreciation there is for that fact and how little we collectively do to embrace that. How awesome is it that you can write Ruby, you can write Python, you can write Go, you can write Elixir, you can write JavaScript, you can all these things PHP. Connected it to SQLite. You can connect it to MySQL. You can connect there's literally a trillion permutations of how this stack can be.

And some people look in that and go like, that's awful. Oh, it would be so much better if there was just one dictator at the top, maybe Saint Tom Cook here, that could just decide what should be right for everyone. And we should no. No. No.

No. No. Absolutely not. The amazing thing is the transport layer is HTML, is HTTP, is these sets of protocols that allow us to use whatever we want, allow us to rediscover things like SQL, like the gem that's been hidden in one corner of the development community for, like, 20 years, and then suddenly another corner of the community goes like, what you got over there? That's one mighty fine gem.

Can I have a taste, please? So I I I think one of my questions for you is, how do you, at this stage, keep that, like, how do you keep that front of mind? Like, you specifically, how do you keep, like, knocking down complexity? Because I feel like a lot of developers get sucked into the borg where they'll go work for they'll go work for somebody. Doesn't matter who.

They'll go work for somebody. And like you said, the slice of the stack that they operate on is, let's say, JavaScript build. That's it. They don't do front end. They don't do but they just do JavaScript building.

And here you are, you know, however many years into your career, and you haven't been, you know, you you run your own thing, which helps. But you haven't been sucked into the borg of complexity. And I do feel like a lot of developers like to play with Legos, I think. And so they like to be like, hey, I'm gonna put this together this way and do it again this way and just have fun focusing on that, which isn't inherently bad. But if you are trying to ship something to get paid and change your life, like, well, you should focus on that instead.

So how do you specifically keep like, hammering down the complexity? I keep thinking that what I'm doing now is gonna blow up lot of companies go out of business all the time. It is the most common thing over the long run for a company to do. It is to go out of business. Very few companies are around for even 5 years.

Fewer still. 25 like we've had with 37 signals. We've been blessed with a very good run that could end at any moment. And what I think is, do you know what? I wanna be prepared.

I wanna be prepared for the day where it's over. And the day it's over, I I gotta do something new. I gotta start over from scratch, and I wanna be able to start over from scratch with these 2 devices. These two hands, that's it. I wanna be as capable, at least, not even as capable.

I wanna be more capable than I was in 2004 when these two hands created the technical infrastructure of Basecamp and set things up in that way. So I'm constantly prepping. I don't mind borrowing that term. I am prepping for the business apocalypse in my little world. Like, it might be a broader sense of the world.

Like, there might be more things that go wrong at the same time, but I'm just gonna be prepared for me. And I find such a satisfaction in knowing through both sort of trust in my own abilities, but also regular exercise of the capacities that I have to build things with tiny, tiny teams. And when I say tiny teams, I mean, 1 person, 2 people, 3 at the most. Because I can imagine in my head that if this thing goes bust and, for example, I go bankrupt, again, things happen all the time, people go bankrupt all the time. I gotta start over.

I have no capital. I have no company. I have just what's in here, and I got these 2. What can I do? Can I get back?

Can I, can I create things that are valuable and so forth? I wanna ensure that that's true because if I ensure that that's true, I can sleep so much better. I mean, in itself, it's also enjoyable. I just like being capable and feeling capable and building capacities. And then obviously giving those to people who really do need it, who literally don't have anything else than their their head and 2 hands, that's really rewarding to see.

But it's also one of the things that allows me to look at my my life's work really with 30 sim singles and go like, do you know what? What a great run it's been. But also, if it was over tomorrow, I'm not gonna be shattered. I'm not gonna be despotened. I'm gonna be capable.

And, like, a week after you've nursed the wounds and licked your chops of this thing blowing up, all right, I'll get back to it. I'll build more stuff. And I'm not gonna let the train get away from me because I've seen that. I've seen that when entrepreneurs were they've had a successful thing. And sometimes, it's not even a catastrophe happened.

It's a celebration. They sell their company. And now they're back at square 1, and they gotta start over. And the train left their station. Like you're too far behind.

Oh, I used to know the thing. I don't no longer knows the thing. So now for me to even get started, I gotta get a bunch of people. I probably gotta get some investment because I'm not gonna risk all my own capital. All these things, and I go like, oh, man.

No. I don't want that. I want my personal capacity to be intact. I wanna be in shape. I wanna be in shape where, like, if suddenly I gotta start running away from a tiger.

I think I don't know. Maybe that's some, DNA programming there. Right? You got, like, do you know what? I I could just get fat and lazy intellectually.

Mhmm. And then suddenly if a sabertooth shows up, I'm gonna be screwed. Mhmm. Yeah. I that is I'll I'll be honest.

That is not where I expected you to go, but I I love it. That is amazing. Do you have do you have time for, like, 2 or 3 more questions? Sure. Yeah.

Okay. Yep. So you talked about, you'll you'll have to forgive me because I'm not a Rails developer. I'm a Laravel developer. So, spiritually, we're cousins, but I don't know the specifics.

So you talked about solid q, solid cache, and then you brought up, Redis with their most recent whatever they're doing. Is there any or does it already exist, or are there any plans to drive any of the queuing or caching from SQLite as well? Because that's something I'm looking at on the Laravel side. We have queue drivers that talk to the database, and I'm thinking that would be great for a a separate SQLite database so it's not contentious, a separate one. And even, like, for caching, we could do something like that.

So where are your thoughts on even further eliminating active record compatible back end, including SQLite, active record compatible back end, including SQLite, as the storage for caching. And this is straight out of the how fast the storage become. It's become fast enough now that the advantage RAM has does not actually matter in terms of the milliseconds, in terms of serving the caches. And we did a bunch of studying and tests on this. Because one of the other advantages you get is not just comp a complexion of, complexity in that you don't have to run a separate process.

You also get more capacity. Storage is still orders of magnitude cheaper. So you get orders of magnitude more, which means that let's say you're you're starting a droplet here. It has 2 gigabytes of RAM. Yeah.

But it might have 50 gigabytes of storage or a 100 gigabytes of storage. That's a lot of space you could store computation in since you don't have to redo it. That's what c Solid cache is. And I really want to set it up as the default out of the box for Rails 8 that Solid Cache is using SQLite by default and exactly as you say, it's using a separate file so that you don't have to intermingle the caching stuff with the system of record stuff, yet you use the same kind of simplicity and you don't have to run a separate setup. And we're doing the same thing with Solid Job.

So Solid Job is the same thing. Let's take, an infrastructure that very often ran against something like Redis. A lot of job engines run again Redis or other in memory stores. Let's point it to a database instead. It actually affords us a bunch of, advantages.

There's greater introspection. You can use standardized tools with it. There's more space to do it. It has some other trade offs in terms of, sort of the operations of it. And there, SQLite is perhaps a little bit behind.

There's been some advantages or advances in Postgres and MySQL 8 forward that allowed some of the query structures you need for a job engine to be a little more efficient. But at the low end, it also doesn't matter. So at the very early stage, especially for experiments and and small scale deployment, you can still use the SQLite database as the back end for queuing, and SolidJob does that. So it's kind of a 2 pronged approach of trying to take 2 of the key components of a modern web application, caching and job running, and say, Do you know what? You don't need an in memory store to do that.

You don't need Redis to do that. You can put that in the same databases you use for everything else, whether that's MySQL or SQLite with separate files. Man, I am so glad I asked. I love that so much. And I just wanna, like, highlight that maybe 5 years ago, if you told someone on Hacker News you were using any database as a as a queue driver, they would be like, you're doing everything wrong.

And now not only are we doing it, we're pushing it all the way to SQLite, baby. It's we've come so far with the ability to to use that kind of stuff. And I love it because Laravel, 11, the default driver for the database is now SQLite. And it just makes like, it it makes the onboarding story a lot easier. It's like, yes, you can if you need to.

I don't know if you will. If you need to, you can graduate. Because a good thing about SQLite is everything you do there is probably gonna work in Postgres or MySQL. Maybe some finicky differences, but the ORM should abstract all of that away. But it gets you, like you can start, and you're started.

You don't have to spin up MySQL or Postgres or Redis or anything like that. So I do I do love to hear I do love to hear was our early embrace in the rails community. I forget when we did it, but this many years ago now that SQLite became the default for rails new. Exactly for that reason, that you could do Rails new and you can start working without having to know the other stuff, without having to know, oh, how do I set up my SQL, and how do I I do all these other things? Because I think, one of the things about com conceptual compress compression is that it benefits people who are who wanna do it all, who wanna be 1 developer shops.

They need to know a fair amount of things, but it also really benefits people who are just starting, who know nothing, who who more than anything just need a handful of success experiences Yes. Where they do stuff at the keyboard and stuff happens on the screen. And they go like, wow. I did that? I built that?

I remember all the way back in 9th grade, this is 1994, I think. I went to this computer lab at a university that was connected to the Internet. And do you know what they sat us down to do? Not browse the Internet, make your own web page. And it had HTML open in this editor, and I did a little blink tag and I saved and I went to the browser and like, holy shit, the text is blinking.

I did the blinking. I made a blinking experience. Life changing experience. And I think that's one of the things I'm really protective of in the rails setup, that we should give more people that life changing experience. That doesn't mean that everyone who tries rails will become a professional developer and so on, but they will have an experience of power that I think is just invigorating for any human.

Like, I did a thing, a thing happened. That is really a gift to give to someone else. And SQLite is a huge help in that regard. Yeah. Not not everyone that sits down to do Rails news is gonna be a professional developer.

But it's not gonna be because they couldn't get MySQL working or they couldn't get Postgres working. It might be for some other reason, which is great. But it's not gonna be because of that. Okay. Last thing before I let you go, y'all just launched or or teased or unveiled your new once.com product, and it looks super interesting.

I do a lot of writing myself. And so I would love to hear you explain the vision, for this new once.com product. Yes. So this is once number 2. The first product was Campfire as we talked about.

That product was and is 3.99. This new product, and I'll put that in actually, I won't put it in quotation marks. It is a product. This is a product company making a product, but we're giving it away for free. So it's called Workbook, and it is to solve a problem we've had, where there's a lot of software in the Internet that allows you to publish 1 page.

You can push put it on Gist. You I write to, hey, world. There's newsletters. There's blogging things. That's a very well served, domain.

Not so well served is if you want to publish multiple pages that fit into a broader context, what we usually call a book. Here is a concept I want to explain to you, for example, and it's gonna take like 90 pages. We've written a lot of books at 37 signals starting all the way back with Getting Real. Actually there was another book before that called Defensive Design. But if we take Getting Real, which was published on the internet, was self published in 2,006, it is exactly that kind of problem we want to make easier to solve.

Because we were using, I think, 4 different kinds of platforms to create these kind of web books, whether that is Getting Real, which is on getting real.basecam.com, or our employee handbook, which also is a book. It has, I don't know, 25 individual pages in it or something like that. We've written a number of other books or manuals, really. We've written manuals for Kamal, our deployment tool, or some of the Hotwire stuff. And like, it's all this stuff that's kind of convoluted to set up and it's kind of full of configuration and full of technical stuff.

And we just go, why doesn't this exist as just a one package? One package, you put it, you install it, not a software as a service. Right? Like, maybe there are software as a service things that do this, but I'm not even interested in that. I'm not gonna run something like getting real on someone else's thing.

Sure. I wanna publish for the Internet on my own server because I know and trust that I can keep that running literally for decades, not gonna atrophy, but I wanna make it easier. So that's what we've done or are doing with workbook. We're creating it. I think we have about 7 books ourselves, from getting real to work handbooks to internal manuals like our ops runbook, our programmers book.

We have a bunch of these internal, manuals. Some of them were also actually just kept in, in GitHub as markdown files. And, like, we were using that to navigate around, which is actually surprisingly capable solution to do it with. A little janky, not so pretty, has some other drawbacks. But, that's that's the premise of workbook.

Make it easy to create books for the Internet, multiple paces that belong together and can be published in one location. We're gonna make it as a just like we did at Campfire, It's gonna be a thing that's literally one command to run on your own server. You'll have work workbooks set up. You'll be able to lock straight in and do all your your writing and and set up for that. It just won't cost you anything.

And it's source included. So just like with Campfire, we're also giving the source away. I intentionally here don't say open source even though I really like open source as a term because we're not trying to start necessarily another community project where we're accepting pull requests and gonna maintain that and so forth. And also because the thesis of once is finished software. Mhmm.

Not necessarily on day 1, but that there is a principle of we can arrive at a finished piece of software that's just done. It does not need more features. It does not need more stuff. It may occasionally need a security update. Okay.

Fine. That's great that you can still push that on. But it's it's conceptual sort of manifestation is done. Like, it is it's not gonna have more buttons and more bells and more whistles, and Workbook hopefully can get there even quicker than Campfire get. And then we could give it away for free, and it won't be a huge burden on us to maintain it even though, of course, we will if there are issues with it.

And we are getting to build a bunch of novel interesting tech for that as well. We're building a new text editor from markdown called House. I just actually announced that today on Twitter, which is something else than what we normally use in our products. We use a WYSIWYG editor called Trix that we also build ourselves. And that's built into Rails through something called ActionText, so you can really easily get WYSIWYG editor set up with drag and drop and file upload and all these other stuff.

But there's a bunch of, especially technically minded people who don't like WYSIWYG. They like Markdown. I'm one of those people. I really like Markdown a lot for my own writing. And we're basically gonna put that into this product and then also release that as an open source, gift to the world.

So that's gonna be Workbook. I don't have a specific launch date on it, but on once.com will be all the updates for when that comes out. And you can, of course, also check out, Campfire in there. And, we'll share as much of as possible about that. I think the other thing that excites me about the whole once brand is source included.

Mhmm. Very often in the open source world, you can find a 1,000,000 source code examples for infrastructure software. Oh, you wanna learn about how an optic relational mapper is built? Great. There's here's about 12 different repositories you can dive in.

You want to learn how a commercially resilient product is built? Oh, no, sorry. Good luck. Vast majority of that is closed source. It is proprietary.

I mean, the same with us. HEY and Basecamp, they're not open source. They we don't have any plans to make those open source. Those are our sort of commercial trade secrets. I mean, not really.

But just this sense that, there's a plethora of open source software in at the infrastructure level, far, far less at the application level. And this is one of the things I've really enjoyed with Campfire for, customers who buy the product. They obviously they get the source. We recorded, walk throughs of Mhmm. Both Ruby level and at the CSS level that people who who buy Campfire get access to.

And we could do more of that with Workbook because in part, there's no ticket fee. So someone could get at least that. I mean, Workbook is a substantially smaller product than Campfire. It doesn't Campfire is, is a very full featured chat. And to build that in a modern competitive, this could be a Slack alternative for some people way, is It's actually a substantial body of work.

Workbook is a little more modest in its ambitions. It doesn't mean it solves a, problem that's necessarily less, modest or needed, but it just means that the technical scope of it is a little smaller. But anyway, I love open source. I love view source. I mean, I learned so much as I said, my first experience with the internet, it was first making my own tag blink, and then it was literally going to, I think, yahoo.com or something and go view source.

How did they do that thing? Mhmm. Oh, you can use a table and you can put little 1 by 1 spacer GIFs in there to align things. Amazing, mind blown. We don't have that these days on, for example, the front end.

Far too many operations are using minification, obfuscation, web packing, chunking, ES building, just blobs. Right? You get a blob. Oh, I'm gonna request, or I wanna learn how they build Gmail. Yeah.

Good luck sorting through 22 megabytes of obfuscated JavaScript. You're gonna learn nothing with that. With Hey, for example, we did the opposite path. Hey is all no built on the JavaScript side, which means that all the individual files are just there. No source map.

Mhmm. Just readable as individual files. And Work book and Campfire take that one step further. It's view source, but for the back end. Yep.

I love that. I love I love that y'all are doing this source available thing. I love I think a lot of people bought Campfire just so they could look at how DHH codes a rails app. I mean, it's it's a great, like, it's a great learning experience. And, you know, I would buy if Taylor released something like that, Taylor Otwell, I would buy it in a heartbeat and just look at it and be like, oh, so that's how he does that kinda thing.

And I think it's a great it's a great way to teach. It's wonderful. Same. I mean, there's all sorts of commercial software where I'd go like, I'd love to know how they built that. I wish I could do VueSource on a bunch of more stuff.

So hopefully this can start at least on the front end, I kinda feel like it doesn't need much tipping there. This is the other reasons why I'm excited about node build and let's get away from all this, transpiler, compiler Mhmm. Bonkojungko, because we can get back to VueSource. And at least that part of learning how the web works, you can learn how the web works by looking at successful major mainstream things and realize, oh, it's actually not that complicated. Mhmm.

That's the way they did that thing. Oh, okay. Yeah. I could do that too. Well, from SQLite to stoicism, to no build, to losing everything in bankruptcy, this has been this has been a delight, and I can't express how grateful I am that you were like, yeah.

Let's do it right now. This is yeah. So I'm My pleasure. Thank you so much. And if people wanna follow you, if they're somehow not following you already, I imagine Twitter slash DHH is probably the place to go.

That's a great place. I took a bit of a break, a few years back from Twitter. But I'm I was again, I don't know how I feel about that. But now I'm back on Twitter, and I do tweet a lot. But otherwise, I have, dhh.dk has links to both Twitter and the LinkedIn and all the other stuff in the books and whatnot in the products.

Perfect. Well, thanks again and we'll see you online. Alright. Thanks.