After his first child was born, Matt Wonlaw (@tantaman) imagined giving his son life advice. What kind of life did he want his kid to lead? At the time, he was working for Facebook, and he decided that his own life needed a change in direction. So Matt started vlcn, aka Vulcan Labs, a research company that develops open-source projects like CR-SQLite and Materialite. vlcn has an unusual business model – Matt receives donations and sponsorships from users and clients. It’s all part of his mission to rethink the modern data stack for writing rich and complex applications. Contributor is looking for a community manager! If you want to know more, shoot us an email at eric@scalevp.com. Subscribe to Contributor on Substack for email notifications! In this episode we discuss: One reason that software is still too hard to write: Object orientations How CR-SQLite allows databases to be merged together and Materialite provides Incremental View Maintenance for JavaScript Why coding directly to relations can provide a more flexible and efficient approach to building applications Matt’s decision to build vlcn as a research lab rather than as a startup Thoughts for the future on PGLite Links: vlcn (Vulcan Labs) CR-SQLite Materialite fly.io PGLite People mentioned: Johannes Schickling (@schickling) Matt Wonlaw: I've always been looking for simpler ways to do things, I think like a lot of engineers are trying to find simpler ways to do things, and yeah, trying out different programming models and whatnot. I guess there's a quote, "I'd rather help people write programs than write programs." Eric Anderson: This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson. Today, we get to talk with Matt Wonlaw, who's the creator and principal at Vulcan Labs. Welcome, Matt. Matt Wonlaw: Thanks. Nice to be here. Eric Anderson: I don't know if you've ever called yourself the principal of Vulcan Labs. I just made that up. Matt Wonlaw: Yeah, no. I guess, founder, but it's a one-man show, so titles don't mean much. Eric Anderson: We're going to talk about all the things Vulcan Labs does. One of those things is an open source project, CR-SQLite. We've talked a lot about SQLite on the show lately, so excited to have you. But I want to start, actually, maybe with Vulcan Labs 'cause I think that's the right umbrella for this conversation. You're living the dream in many respects. Tell us about what Vulcan Labs is and how you got into it. Matt Wonlaw: Yeah, I think software is too hard to write. The first 80% starts pretty easy, as the saying goes, it's that last 20% and for some reason, it takes forever and everything turns into that spaghetti code. And I was trying to figure out what is it that makes software so hard to write? Is it just like engineers are bad and we need to study harder or is it the tools we're using are the wrong abstractions for the job? They're just not up to today's applications. And I came to the conclusion that the tooling is wrong, and I guess Vulcan Labs is my experiments and explorations in what should the modern dev stack for rich applications like a Figma or a Notion or Spotify, if you were to build those, what primitives do you need to build those? I guess, as a preview, the solutions I've landed on are CR-SQLite. It's basically an extension for SQLite that lets you merge databases. So think of Git for databases in a way, so that's to facilitate collaboration and multiplayer. The other is Materialite. So this is bringing incremental view maintenance to embedded databases 'cause a lot of queries, you want to be able to subscribe to a query rather than always being request response 'cause then like a UI, you want to know instantaneously what has changed rather than every time someone makes a change, recoding the database. And then the last two things, one is tree SQL. So I think the relational model is the right model, but if you're using a relational model, how do you pull a tree of data out 'cause a lot of times your application, it needs a hierarchy, not some flat set of relations. So if you think like a issue tracker, you might have an issue and that issue has labels and maybe has comments, you might want to pull those as one document. And yeah, the last thing is better integration between the host language and the database. So you have full static typing end-to-end. Eric Anderson: The high level idea of, "Software is still too hard to write," is I think a good first principle. I think we can all agree. Is there some fundamental reason for that or is this just a blocking and tackling exercise? We just need to make it easier in a thousand different ways. Matt Wonlaw: Object orientation is a big culprit I think. So I think when we model our data with OO, we're bringing some implicit assumptions to the data that we don't realize. So one example is a chair, right? You're going to model a chair in your program. You're going to say your chair is a piece of furniture. Well, that classification of chair as furniture is very dependent on the perspective of the viewer or the person using the chair. Yeah, in my normal life, a chair is a piece of furniture, but if it's really cold outside and I don't have heat, maybe my chair is firewood or if I need to break out of the office, maybe my chair's a battering ram. If I need to block a door, maybe the chair's a barricade. It has all these different roles depending on the context of the viewer. And I think software, as it gets older, gets new requirements that change those fundamental perspectives and your data model, when it's this OO way, it is not flexible enough to adapt to that. So I think OO is one culprit. Can we code directly to relations? And that got me started down the relational DB path. And then I realized there's other problems here like relational databases are built for this era of request-response. Like you think about the early LAMP stack kind of world where every time a user visited a site, you would request from the database, get all data and show stuff. Whereas if you're building some rich UI like a Spotify, you don't want to have to request to the database every time you make a state change. Every time a state change happens, it should just update, kind of like call you back reactively. So that's kind of where the Materialite project was born of SQLite. And these databases are still in this request-response paradigm. They really need a subscription paradigm where I can say, "Set up all my queries that my app needs and subscribe to them." 'Cause yeah, applications have very static set of queries. If you think about WhatsApp, it has a query for your threads, your messages, your contact list and those queries don't change every time you open the app. It's really the data that's changing the queries that are static. So for these sort of apps, you need a database that really handles the static query case and dynamically changing data case. Eric Anderson: So you have this broader realization that software could be easier in a lot of ways, and if you start identifying these culprits, you're mapping them into projects, was this all happening before you started Vulcan or did you lead to start Vulcan and you're like, "Now what do I do," and happen into this? How long has this been a motivator for you? Matt Wonlaw: Ever since I started coding, I've always been looking for simpler ways to do things. I think like a lot of engineers who are trying to find simpler ways to do things and yeah, trying out different programming models and whatnot. I guess there's a quote, "I'd rather help people write programs than write programs," if that makes sense. I'd rather write infrastructure for people. I was doing a lot of that at Facebook and whatnot, but I just wanted to do something that had broader applicability to the whole world and could be open sourced. So after I had my first child, I was thinking in my head, "What am I going to tell him how to live his life?" I was like, "Oh, I'm not living this life," I would tell him. Yeah, I took the plunge and decided to leave my job. But I've always been sort of like keep the fire movement of aggressively saving and stuff being a thing for eight years. I had enough to just take that plunge. I was fortunate enough to be able to do that and work on this stuff full-time. Eric Anderson: People tell themselves, "Oh, if I had more financial security, I would do X or Y. That's my true passion." And I challenge them a bit like, "well, Is this true passion of yours really so commercially in-viable?" 'Cause presumably, that passion probably produces some value for society. And I think most people when they realize that, they're like, "Yeah, actually, if I did do this thing I love, it wouldn't be so terrible." And it sounds like you came to that conclusion eventually. Matt Wonlaw: Yeah, yeah. That was part of the motivator is like, "If I quit, I'm doing something. It's going to produce money at some point. It's not like I'm going to be living on my savings forever." And I think, yeah, after a year, a year and a half in, some people found CR-SQlite Fly.io specifically and they did a pretty significant sponsorship. And then some people found Materialite and were like, "Oh, we need this in our database and yes, contract to hire." So yeah, money is coming in and it's more than I expected. So yeah, it's been pretty good. Eric Anderson: I'm curious now that you've been through this, Matt, what do you think about the future? I'm remembering one of your tweets where you kind of thought, "Oh, a lot of people are chasing this problem area now. Maybe it's time for me to move on to something else." I get the impression that you see yourself as kind of operating at the frontier. Matt Wonlaw: Yeah. So what I spent most of my time on was CR-SQlite, which is this concept of can you model SQLite tables with CRDTs so that you can merge databases? The idea would be like this would make collaborative software or software can go offline and come back online. Really easy for developers. They don't have to understand CRDTs themselves, they don't have to understand syncing. They just set up their table say, this column's last-write-wins, this column is some tech CRDT and they just write to their database and the database handles all the merging for them. And when I started that project, I think there was just Automerge and Yjs, those were two other projects in the space of CRDTs and collaboration and data syncing. But then I guess a year later, we saw ElectricSQL, PowerSync, SQLSync, Replicache. So there was endless entrance into this data syncing space. And yeah, I guess I've never really questioned myself like, "Why do I feel like once it's saturated, I need to move on?" I guess I feel like other people are solving it. There's more interesting stuff to solve next. So yeah, after I saw so many people working on that problem, I knew in my own apps and apps people have been writing with CR-SQLite, there was this question of I'm using SQLite as my data store, but I have to build this object model on top because I want to be able to react in realtime to mutations. So I was like, "Okay, this seems like a problem where we could have incremental views and subscriptions, where you could subscribe to your queries rather than having to create this separate layer to handle notifications of writes." So that's kind of where I got into incremental view maintenance and Materialite. Eric Anderson: You and I have talked a little bit about SQLite and then on the show, we've covered quite a bit. I want to make sure we cover as much as you're interested in covering SQLite 'cause I think it's been an interesting ecosystem for the last little bit. What have you found interesting or what are some topics we should cover today? Matt Wonlaw: Well, I guess my latest conclusion is SQLite might not be the right fit for today's like Figmas or Notions like the next set of rich UIs. And why I think that is 'cause, as I said earlier, if you think of an application, the queries are pretty static and the data is what's dynamic. So we really want a facility for doing subscriptions against the database, like for the WhatsApp example. I have a query for my messages, a query for my threads, a query for user status. I just want to subscribe to all those and anytime that data changes, notify me so I can update the UI. With SQLite right now, you can't subscribe to anything, right? You've got to either pull on some interval or you've got to add some layer on top of the database to handle this for you. And once you add a layer on top of the database, you end up with all the same problems that DB was solving for you, right? A database gives you nice transactions and concurrency control, but if you're going to add a new layer on top, well, you're going to have to think about transactions, concurrency control, and implement all that there. So it would be better if it is in the DB itself. And then, I guess, I briefly touched on the object model is the wrong one. It'd be great if you could just code directly to relations. I think that might be a little wild idea to some people, but if you're coding directly to relations, you need your database to be as fast as memory. So when you write, it finishes as fast as setting a variable. When you read, it's as fast as reading a variable off the JavaScript heap if you're using JS. And SQLite where every transaction when you commit it has to be durably committed before you can do another operation, I think that's a fundamental problem for if you want to just code directly to relations, where I don't think all commits need to be durably committed before you move on to the next commit 'cause there's plenty of cases in an application where it's fine if you lose the last few commits, if you think of Spotify or something, right? Not every single interaction needs to be durable immediately, and if you can get rid of that durability for every single commit, you can go a lot faster. Eric Anderson: Maybe I shouldn't ask this question. What does this coding directly to relations mean? Is this like a graph-like idea or to map it with terms that I've explored before? Matt Wonlaw: Yeah, so I guess if you think of Spotify, you have your tracks, you have your Play button, you have your timeline of what's currently where you are in the track. Somehow you have to get the data to those components, essentially the Play state. So when you press Play, all the things can update and show the correct state. And if you're using an object model, maybe you're passing that down to all the components. But if you're coding directly against some relational DB where everything's flat and laid out, like this global data store where every component can just issue a query for the data it needs, so literally just issuing some query for the data it needs and then subscribing to that query. And I guess coding to relations has less of this perspective problem of that chair example of if I need to find something that's firewood, well, I can just query for anything that's made of wood and chairs will come back and that's fine. Eric Anderson: Maybe it's worth pointing out. One of the things that's interesting about what you're doing, I think it's kind of orthogonal to the way a lot of the software is developed today, which is individuals have a specific problem in a company, they build some software to solve that specific problem and then they explore whether it can be generalized to a lot of people. And I think you've separated yourself from a specific application and said, "Here's a general problem. Can I come up with a general solution and then explore whether it can apply to certain people's specific problems?" Is that fair to say you're taking the reverse approach to say Uber open source or Google open source? Matt Wonlaw: I started... So I guess I'm pulling on my, been doing software development for 15 years and I've noticed these recurring patterns and all sorts of systems we've had to build. So I guess it's pulling on this history of experience in these problems I know I keep dealing with and thinking through why does state management keep coming up as a problem? Why is model view controller always turning into a mess eventually? And I do have this old project I used to use, it's like to validate and test my ideas, Strut.io, it's like this old presentation editor. Yeah, there's some grounding in reality and use case. Eric Anderson: Okay, so you went down the SQLite journey, built CR-SQLite, Fly got excited, but over time you came to the conclusion that maybe SQLite isn't the right abstraction. Have you come to similar conclusions for your other projects? Matt Wonlaw: So I guess the short answer is not really. I think the other projects still seem like they're bearing a lot of fruit. SQLite, I had reservations at the beginning, but the old adage, "Don't write your own database," and all these things, coming from Facebook where they're very pragmatic about how they do things. I was like, "Yeah, that culture was instilled in me, so let me make the pragmatic choice here. Let me pull SQLite off the shelf and see how far I can get with it." And then just after a while it was like, "Yeah, I don't think it's going to get all the way to where I want to get it to." And I think part of that is I've been targeting the web platform specifically and I just didn't realize how much of a tax there is crossing from JavaScript to WASM and back and there's a huge performance hit just in that. And maybe if that performance hit wasn't there, I could still continue with SQLite, I'm not sure. Eric Anderson: Do you come out the other door, if SQLite isn't the answer, is there something else you lean towards? Matt Wonlaw: What I'm leaning towards is just fully investing my time in Materialite and building that up to just not just be incremental view maintenance, but also a regular database under the hood. Yeah, I am leaning into, yeah, I guess, I will build my own database. The upside of that is Materialite actually has the most interest from people financially, so it'd make sense for me to do that too. Eric Anderson: I've noticed a little database trend of late where folks seem to not build databases from scratch in the form factor we're used to as much anymore as they borrow this from Postgres or that from ClickHouse. And that database ends up being a federation of database components then like a single monolith. And I'm curious as you approach Materialite, is that going to bear out or... Matt Wonlaw: Yeah, I think so. So that's also one of the things that finally pushed me over the edge to maybe I can build my own. I don't know. I feel so arrogant saying this, maybe I can build my own database, but I guess that's why we do hard things, right? We do 'cause we don't know they're hard. But there's a guy at Triplet, I think their founder, he's like, "Yeah, building database probably isn't that hard these days 'cause we have all these key-value stores in B-tree implementations, you can just pull stuff," as you said, "off the shelf." So yeah, that's what I've been doing and the browser has IndexedDB, which is pretty decent abstraction for a key-value store to base the database off of, so I don't have to solve the writing to disk and the durability and all these things. I just really am dealing with that key-value interface. Everything below that is already solved for me. Eric Anderson: If Materialite goes the way you want, is this a database in the sense of a local database like a SQLite or is this a distributed database, I don't need Postgres anymore? Matt Wonlaw: It'll be a locally embedded database like SQLite, but ideally with collaborative features, right? I think SQLite was built at a time where everybody just had one computer, but now you have multiple devices and you might start work on your phone and continue it on your laptop and then finish it later back on your phone and you want that data obviously to sync between all of them. So I think, yeah, it'd be really cool if an embedded database of the future knew how to sync or merge itself with other copies of itself, so you do- Eric Anderson: Got it. Matt Wonlaw: ... 'Cause I guess going back to Strut.io, when I first quit, I was like, "Oh, I think I can resurrect this old project and make a bunch of money real quick with it." But that project didn't have multiplayer or syncing, so I was like, "Okay, let me just go add that real quick." And I was like, "Oh, this is a mess and that's why I think there's a market here with CR-SQLite." And that's how I started building CR-SQLite, "I think there's a market, let me just go build that general solution." To all that say, syncing is hard, it would be great if something like at the database layer could handle that for developers, so they don't have to be experts in distributed systems. Eric Anderson: So I guess this transition, if I'm imagining that is what's happening between your focus on CR-SQLite to Materialite reinforces the fact that Vulcan Labs is the thing that's persistent and continuous. That's where you're being consistent and then you move the locus of attention from one project to the other as needs arise, as conclusions form. Is that fair? Matt Wonlaw: Yeah, I guess I started, it was really just Vulcan and it was all going to be a product around CR-SQLite and then I realized I really enjoy solving the difficult problems and not so much the finding collaborators, maybe finding funding, maybe hiring people, the whole business side building. So I was like, "Okay, pivoting it as a research lab and doing contract work for people who also have these problems." It fits my interest and two, it provides some financial stability. Eric Anderson: Maybe one question going back to this object-oriented as the big culprit and you mentioned relations to the model, and I think I got that with respect to data modeling and your database. Does that also mean you would avoid objects in more just general programming, like classes are problematic? What's the alternative? Is it functional or is there some other approach? Matt Wonlaw: Yeah, I don't think classes are altogether bad, right? I think you still need classes and objects and all these things for... Eric Anderson: Abstraction and encapsulation maybe. Matt Wonlaw: Yeah. But I'm trying to think of the best way to, there is a separation somewhere, there's like the data for the problem domain you're modeling, and I feel like that should be relational. And then there's the data for your algorithms, maybe your B-tree or your breadth first traversal or whatever these things are. These can be classes and hide their data and have interfaces and whatnot. But the stuff that's part of the problem domain feels like it should be stored in a relational DB and accessed directly through queries. I guess one other thing that the object model or program memory is missing is good primitives for doing mutations. So if you think about a database, you can start a transaction, you can mutate five things. If you fail in the middle, well, they all get rolled back. They think about your program memory. If you start a bunch of mutations and then you have an exception in the middle, you don't really have a facility to roll back. A few languages have software transactional memory, but not many. And I think that's another big problem as to like... Like people always say, "Oh, global state is a horrible thing," but our databases are shared global mutable state, and we generally don't have that many problems with them. And I think the primitives in our languages are just, we don't have the right mutation primitives, we can't do a transaction, we can't get isolation of transactions, we can't roll things back. Yeah, I should be able to say, "I want to mutate these five variables, but nobody should be able to see the effects of the mutation until I'm done. And if I fail in the middle, I should be able to revert to the prior state." But yeah, we don't have that in JavaScript or C or whatever. Eric Anderson: Interesting, and maybe we don't have those things because the database has done that for us in the past, like we've just said the database is the record of truth for this data and we're going to outsource mutation management to the database. And now as we want to do more of that state management within our programming more directly, do you envision that emerging? Is this the fifth project for Vulcan lab? Matt Wonlaw: So I think in the early 2000s, you're right, when pages were, like the LAMP stack and everything was a full page refresh, all your state was in the database and that was the system of record and you had no in-memory state. You had to manage and roll back and do all these things with. I think things were pretty easy back then. And I guess to answer your other question, would I ever do software transactional memory? So I know Clojure has it, they've had it for a really long time. JavaScript, the environment seems so impure, it seems like super hard to pull that off. I don't know if you could pull that off in user space. Eric Anderson: So Matt, maybe we can just touch a bit more on the Vulcan Labs model 'cause I think it's an interesting model. So you went into this thinking, "I'm just going to create value, solve big problems, and if people want to fund me, great and if not, we'll figure it out." And people did want to fund you. How does that happen? What are the mechanics 'cause I think that's interesting to some people? They just send you dollar bills in the mail? Matt Wonlaw: Yeah, I wish it was that easy. Like okay, some people send you dollar bills in the mail, but they're literally like $5 a month. Eric Anderson: Right. Matt Wonlaw: To get worthwhile sponsorships, yeah, I was just actually talking with the cut, so finding out which companies were using this stuff. Usually they were talking to me in Discord 'cause they needed support and then finding out who are they, okay, they're part of a company and then just literally having that conversation like, "It looks like this powers one of your products. I'm doing a lot of bug fixes and maintaining things for you. I think it would be fair if you guys contribute a significant amount to this." Yeah, one, so Johannes, he's a guy I talked to. He encouraged me to say, "Oh, are you getting one engineer's salary worth of value out of this? That's how much you should contribute." I never went quite that aggressive. So I went somewhere between $0 to that aggressive, yeah just having those conversations, being upfront that they're getting value and what's the worst that can happen? They can say no, but they're probably still going to use your project, they're not just going to drop it. I did wait, right? I didn't ask for these donations immediately. I waited till the project was kind of in use in some capacity at their company before asking, which it feels a bit sleazy like, "Oh, I waited until you deployed to production, now I'm asking you for money." But I think everybody understands that you got to make a living somehow. Eric Anderson: Yeah, I don't think it's terrible to deliver value and then ask for money. It'd be almost, the reverse seems also equally strange to be like, "I think you should pay me and just hope that I give you something interesting in the end." Matt Wonlaw: That's true. Eric Anderson: And these people are accommodating. And are there strings attached to that money? Do you implicitly need to serve their needs or do they ask for deliverables? Matt Wonlaw: Yeah, it's different for different companies. Some are no-strings attached. It's like, "We're using it, we know how to use it. Whatever support you can provide is fine, but we're not holding you to anything." There have been others that like, "Oh, we want to give you equity and make sure you're aligned with our company's success and sign this contract." Those, I just have to turn down because- Eric Anderson: Okay, yeah. Matt Wonlaw: ... I feel like if I'm going to start tying myself to one specific sponsor, then that might preclude others in the future. And now I'm suddenly worried about what I say publicly or work on in the future, right? For those, I just say, "Yeah, I can't do that. You can just write a sponsorship check or nothing at all." I don't know if you've talked to others in the past who get open source sponsorships and if you have any insights into what other people have done? Eric Anderson: GitHub now facilitates some donations and I think Patreon is another kind of channel that I've seen people use. In the case of maybe both of those, there's an option to do a reacquiring, like, "I'm going to subscribe to a donation. I am going to give you 10 bucks a month," which is an interesting model. We've all seen the phrasing around Buy Me A Coffee, which is kind of a fun, it seems like if Matt was in person, I definitely would buy him a coffee. I imagine in most cases your sponsors are buying you much more than that, but do you incorporate as a nonprofit, are you like Mozilla Foundation in a small way? Matt Wonlaw: Yeah, these are very good questions. I should talk to somebody who deals with this to give you some advice, but right now, I'm just set up as an LLC. But yeah, I don't know, could I set up as a nonprofit, get better tax benefits or... Yeah, I know there's research tax credits and stuff. Eric Anderson: Good. So Matt, I want to pause here 'cause we're approaching end of time. Anything you wanted to cover or that would be good to cover? Matt Wonlaw: I think the last thing that's interesting to me is you have an embedded database, which has some set of data on it, but realistically, you probably have... I guess, people have all sorts of different devices with different storage. You have your phone and then your laptop and desktop. So the amount of data in your app on your phone is probably going to be a sliver of what might be on your desktop. So it is really interesting if like can you create an embedded replicated database where on the phone it just has the hot set that the phone is using, but on the desktop it has the full set and can you do queries that span both databases where like, "Oh, it'll query my data locally and then if there's more data, it'll go back to the server or whatever and pull in the rest." Eric Anderson: Maybe jamming on that a little bit more broadly. I don't think this is anything new, but I novel all the time when I look through my apps on my phone that I have gigabytes of app on my phone, but very little of my user data. People build apps, they ship them to my phone and then on my phone, I generate data and I ship it to their server and they store my data and I store their app, and I find that a little odd. I feel like I should keep my data, you keep your app. Somehow that's not how mobile is built today. You're describing something that's more nuanced, which is how has this user data persisted and some of it's stored on my client, on desktop we're okay with lots of it being stored and on mobile, you want a little more flexibility to only store what's needed in a critical sense. Matt Wonlaw: Yeah, so on mobile, only store what's needed, but how can we hide that complexity from the developer where they're not having to figure out what to store or not. Maybe as they query the database, it sees what you're querying and it pulls in what you need locally and anything you didn't query, stays on the server or desktop, wherever your user data is. 'Cause I guess the Local-First Movement, there's this whole movement called Local-First where it's like users should have all their data on device and all their user data there, but all the solutions in the Local-First space require you syncing all of your data to the app before you can start using it. And some people in that space say, "Oh, you're never going to generate enough user data to fill your phone. Phones are huge now." Maybe that's true, maybe I'm barking up the wrong tree, but I feel like you do need the ability to start your app with just the slice of user data you need at that moment and as you need it, start syncing it in from, I don't know, your desktop or maybe you have some service provider that you do let you store your aggregate of user data. Eric Anderson: I feel like Local-First is often useful for single player applications and I just wonder are they just as useful for these multiplayer applications? In this sense, you bring the whole enterprise's data onto your device? Matt Wonlaw: Yeah, so that's where these Local-First solutions have sort of been breaking it down, right? They're good for single player, they're good for multiplayer up to an extent. But then once you get, I don't know, all of Boeing or Lockheed Martin or something, that's a whole enterprise, you're not going to sink down the whole enterprise Wiki and enterprise task tracker and whatever else there is. So yeah, I think in that case where you do have enterprise software where you want to be snappy and fast, where all the data that your employees are using are local on your device, you do need to somehow figure out how to just sync a subset of the enterprise, just what that user commonly uses day-to-day is synced to their device and local for them. Eric Anderson: Maybe I am asking you for a hot-take here. If you're spending less time in SQLite at the moment, have you come across PGlite, this kind of like running Postgres on WASM on the client? Is that a thing that we should be keeping an eye on? Matt Wonlaw: I've seen it. It looks really cool. I was super blown away. They got the WASM size down like 2.6 megs after compression. I'm like, "Postgres, is that small?" I had no idea. I don't know if they've gripped stuff out. Yeah, I'm super curious. I want to see some benchmarks. Yeah, it's the ElectricSQL, folks. I think Neon working on it, so I know them pretty well. But also I have enough going on, I don't want to distract myself with a new rabbit hole, so I think I'll probably just get a TLDR and try to just file that away for some future problem if it ever comes up. Eric Anderson: Well, Matt, I think we're also maybe in kind of conclusion here. Glad not only is your son the beneficiary of you going rogue here with Vulcan Labs, but I think all the world, rather than there being more code in Facebook, we have more code in public and you're solving generalized problems that all programmers face. So thanks for your contributions. I'm excited to see where it takes you. Matt Wonlaw: Yeah, thanks for having me. Eric Anderson: You can subscribe to the podcast and check out our community Slack and newsletter at contributor.fyi. If you like the show, please leave a rating and review on Apple Podcasts, Spotify or wherever you get your podcasts. Until next time, I'm Eric Anderson and this has been Contributor.
After his first child was born, Matt Wonlaw (@tantaman) imagined giving his son life advice. What kind of life did he want his kid to lead? At the time, he was working for Facebook, and he decided that his own life needed a change in direction. So Matt started vlcn, aka Vulcan Labs, a research company that develops open-source projects like CR-SQLite and Materialite. vlcn has an unusual business model – Matt receives donations and sponsorships from users and clients. It’s all part of his mission to rethink the modern data stack for writing rich and complex applications.
Contributor is looking for a community manager! If you want to know more, shoot us an email at eric@scalevp.com.
Subscribe to Contributor on Substack for email notifications!
In this episode we discuss:
One reason that software is still too hard to write: Object orientations
How CR-SQLite allows databases to be merged together and Materialite provides Incremental View Maintenance for JavaScript
Why coding directly to relations can provide a more flexible and efficient approach to building applications
Matt’s decision to build vlcn as a research lab rather than as a startup
Thoughts for the future on PGLite
Links:
People mentioned:
Johannes Schickling (@schickling)
Matt Wonlaw:
I've always been looking for simpler ways to do things, I think like a lot of engineers are trying to find simpler ways to do things, and yeah, trying out different programming models and whatnot. I guess there's a quote, "I'd rather help people write programs than write programs."
Eric Anderson:
This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson.
Today, we get to talk with Matt Wonlaw, who's the creator and principal at Vulcan Labs. Welcome, Matt.
Matt Wonlaw:
Thanks. Nice to be here.
Eric Anderson:
I don't know if you've ever called yourself the principal of Vulcan Labs. I just made that up.
Matt Wonlaw:
Yeah, no. I guess, founder, but it's a one-man show, so titles don't mean much.
Eric Anderson:
We're going to talk about all the things Vulcan Labs does. One of those things is an open source project, CR-SQLite. We've talked a lot about SQLite on the show lately, so excited to have you. But I want to start, actually, maybe with Vulcan Labs 'cause I think that's the right umbrella for this conversation. You're living the dream in many respects. Tell us about what Vulcan Labs is and how you got into it.
Matt Wonlaw:
Yeah, I think software is too hard to write. The first 80% starts pretty easy, as the saying goes, it's that last 20% and for some reason, it takes forever and everything turns into that spaghetti code. And I was trying to figure out what is it that makes software so hard to write? Is it just like engineers are bad and we need to study harder or is it the tools we're using are the wrong abstractions for the job? They're just not up to today's applications. And I came to the conclusion that the tooling is wrong, and I guess Vulcan Labs is my experiments and explorations in what should the modern dev stack for rich applications like a Figma or a Notion or Spotify, if you were to build those, what primitives do you need to build those? I guess, as a preview, the solutions I've landed on are CR-SQLite. It's basically an extension for SQLite that lets you merge databases. So think of Git for databases in a way, so that's to facilitate collaboration and multiplayer.
The other is Materialite. So this is bringing incremental view maintenance to embedded databases 'cause a lot of queries, you want to be able to subscribe to a query rather than always being request response 'cause then like a UI, you want to know instantaneously what has changed rather than every time someone makes a change, recoding the database. And then the last two things, one is tree SQL. So I think the relational model is the right model, but if you're using a relational model, how do you pull a tree of data out 'cause a lot of times your application, it needs a hierarchy, not some flat set of relations. So if you think like a issue tracker, you might have an issue and that issue has labels and maybe has comments, you might want to pull those as one document. And yeah, the last thing is better integration between the host language and the database. So you have full static typing end-to-end.
Eric Anderson:
The high level idea of, "Software is still too hard to write," is I think a good first principle. I think we can all agree. Is there some fundamental reason for that or is this just a blocking and tackling exercise? We just need to make it easier in a thousand different ways.
Matt Wonlaw:
Object orientation is a big culprit I think. So I think when we model our data with OO, we're bringing some implicit assumptions to the data that we don't realize. So one example is a chair, right? You're going to model a chair in your program. You're going to say your chair is a piece of furniture. Well, that classification of chair as furniture is very dependent on the perspective of the viewer or the person using the chair. Yeah, in my normal life, a chair is a piece of furniture, but if it's really cold outside and I don't have heat, maybe my chair is firewood or if I need to break out of the office, maybe my chair's a battering ram. If I need to block a door, maybe the chair's a barricade. It has all these different roles depending on the context of the viewer. And I think software, as it gets older, gets new requirements that change those fundamental perspectives and your data model, when it's this OO way, it is not flexible enough to adapt to that.
So I think OO is one culprit. Can we code directly to relations? And that got me started down the relational DB path. And then I realized there's other problems here like relational databases are built for this era of request-response. Like you think about the early LAMP stack kind of world where every time a user visited a site, you would request from the database, get all data and show stuff. Whereas if you're building some rich UI like a Spotify, you don't want to have to request to the database every time you make a state change. Every time a state change happens, it should just update, kind of like call you back reactively. So that's kind of where the Materialite project was born of SQLite. And these databases are still in this request-response paradigm. They really need a subscription paradigm where I can say, "Set up all my queries that my app needs and subscribe to them." 'Cause yeah, applications have very static set of queries.
If you think about WhatsApp, it has a query for your threads, your messages, your contact list and those queries don't change every time you open the app. It's really the data that's changing the queries that are static. So for these sort of apps, you need a database that really handles the static query case and dynamically changing data case.
Eric Anderson:
So you have this broader realization that software could be easier in a lot of ways, and if you start identifying these culprits, you're mapping them into projects, was this all happening before you started Vulcan or did you lead to start Vulcan and you're like, "Now what do I do," and happen into this? How long has this been a motivator for you?
Matt Wonlaw:
Ever since I started coding, I've always been looking for simpler ways to do things. I think like a lot of engineers who are trying to find simpler ways to do things and yeah, trying out different programming models and whatnot. I guess there's a quote, "I'd rather help people write programs than write programs," if that makes sense. I'd rather write infrastructure for people. I was doing a lot of that at Facebook and whatnot, but I just wanted to do something that had broader applicability to the whole world and could be open sourced. So after I had my first child, I was thinking in my head, "What am I going to tell him how to live his life?" I was like, "Oh, I'm not living this life," I would tell him. Yeah, I took the plunge and decided to leave my job. But I've always been sort of like keep the fire movement of aggressively saving and stuff being a thing for eight years. I had enough to just take that plunge. I was fortunate enough to be able to do that and work on this stuff full-time.
Eric Anderson:
People tell themselves, "Oh, if I had more financial security, I would do X or Y. That's my true passion." And I challenge them a bit like, "well, Is this true passion of yours really so commercially in-viable?" 'Cause presumably, that passion probably produces some value for society. And I think most people when they realize that, they're like, "Yeah, actually, if I did do this thing I love, it wouldn't be so terrible." And it sounds like you came to that conclusion eventually.
Matt Wonlaw:
Yeah, yeah. That was part of the motivator is like, "If I quit, I'm doing something. It's going to produce money at some point. It's not like I'm going to be living on my savings forever." And I think, yeah, after a year, a year and a half in, some people found CR-SQlite Fly.io specifically and they did a pretty significant sponsorship. And then some people found Materialite and were like, "Oh, we need this in our database and yes, contract to hire." So yeah, money is coming in and it's more than I expected. So yeah, it's been pretty good.
Eric Anderson:
I'm curious now that you've been through this, Matt, what do you think about the future? I'm remembering one of your tweets where you kind of thought, "Oh, a lot of people are chasing this problem area now. Maybe it's time for me to move on to something else." I get the impression that you see yourself as kind of operating at the frontier.
Matt Wonlaw:
Yeah. So what I spent most of my time on was CR-SQlite, which is this concept of can you model SQLite tables with CRDTs so that you can merge databases? The idea would be like this would make collaborative software or software can go offline and come back online. Really easy for developers. They don't have to understand CRDTs themselves, they don't have to understand syncing. They just set up their table say, this column's last-write-wins, this column is some tech CRDT and they just write to their database and the database handles all the merging for them.
And when I started that project, I think there was just Automerge and Yjs, those were two other projects in the space of CRDTs and collaboration and data syncing. But then I guess a year later, we saw ElectricSQL, PowerSync, SQLSync, Replicache. So there was endless entrance into this data syncing space. And yeah, I guess I've never really questioned myself like, "Why do I feel like once it's saturated, I need to move on?" I guess I feel like other people are solving it. There's more interesting stuff to solve next.
So yeah, after I saw so many people working on that problem, I knew in my own apps and apps people have been writing with CR-SQLite, there was this question of I'm using SQLite as my data store, but I have to build this object model on top because I want to be able to react in realtime to mutations. So I was like, "Okay, this seems like a problem where we could have incremental views and subscriptions, where you could subscribe to your queries rather than having to create this separate layer to handle notifications of writes." So that's kind of where I got into incremental view maintenance and Materialite.
Eric Anderson:
You and I have talked a little bit about SQLite and then on the show, we've covered quite a bit. I want to make sure we cover as much as you're interested in covering SQLite 'cause I think it's been an interesting ecosystem for the last little bit. What have you found interesting or what are some topics we should cover today?
Matt Wonlaw:
Well, I guess my latest conclusion is SQLite might not be the right fit for today's like Figmas or Notions like the next set of rich UIs. And why I think that is 'cause, as I said earlier, if you think of an application, the queries are pretty static and the data is what's dynamic. So we really want a facility for doing subscriptions against the database, like for the WhatsApp example. I have a query for my messages, a query for my threads, a query for user status. I just want to subscribe to all those and anytime that data changes, notify me so I can update the UI. With SQLite right now, you can't subscribe to anything, right? You've got to either pull on some interval or you've got to add some layer on top of the database to handle this for you. And once you add a layer on top of the database, you end up with all the same problems that DB was solving for you, right?
A database gives you nice transactions and concurrency control, but if you're going to add a new layer on top, well, you're going to have to think about transactions, concurrency control, and implement all that there. So it would be better if it is in the DB itself. And then, I guess, I briefly touched on the object model is the wrong one. It'd be great if you could just code directly to relations. I think that might be a little wild idea to some people, but if you're coding directly to relations, you need your database to be as fast as memory. So when you write, it finishes as fast as setting a variable. When you read, it's as fast as reading a variable off the JavaScript heap if you're using JS.
And SQLite where every transaction when you commit it has to be durably committed before you can do another operation, I think that's a fundamental problem for if you want to just code directly to relations, where I don't think all commits need to be durably committed before you move on to the next commit 'cause there's plenty of cases in an application where it's fine if you lose the last few commits, if you think of Spotify or something, right? Not every single interaction needs to be durable immediately, and if you can get rid of that durability for every single commit, you can go a lot faster.
Eric Anderson:
Maybe I shouldn't ask this question. What does this coding directly to relations mean? Is this like a graph-like idea or to map it with terms that I've explored before?
Matt Wonlaw:
Yeah, so I guess if you think of Spotify, you have your tracks, you have your Play button, you have your timeline of what's currently where you are in the track. Somehow you have to get the data to those components, essentially the Play state. So when you press Play, all the things can update and show the correct state. And if you're using an object model, maybe you're passing that down to all the components. But if you're coding directly against some relational DB where everything's flat and laid out, like this global data store where every component can just issue a query for the data it needs, so literally just issuing some query for the data it needs and then subscribing to that query. And I guess coding to relations has less of this perspective problem of that chair example of if I need to find something that's firewood, well, I can just query for anything that's made of wood and chairs will come back and that's fine.
Eric Anderson:
Maybe it's worth pointing out. One of the things that's interesting about what you're doing, I think it's kind of orthogonal to the way a lot of the software is developed today, which is individuals have a specific problem in a company, they build some software to solve that specific problem and then they explore whether it can be generalized to a lot of people. And I think you've separated yourself from a specific application and said, "Here's a general problem. Can I come up with a general solution and then explore whether it can apply to certain people's specific problems?" Is that fair to say you're taking the reverse approach to say Uber open source or Google open source?
Matt Wonlaw:
I started... So I guess I'm pulling on my, been doing software development for 15 years and I've noticed these recurring patterns and all sorts of systems we've had to build. So I guess it's pulling on this history of experience in these problems I know I keep dealing with and thinking through why does state management keep coming up as a problem? Why is model view controller always turning into a mess eventually? And I do have this old project I used to use, it's like to validate and test my ideas, Strut.io, it's like this old presentation editor. Yeah, there's some grounding in reality and use case.
Eric Anderson:
Okay, so you went down the SQLite journey, built CR-SQLite, Fly got excited, but over time you came to the conclusion that maybe SQLite isn't the right abstraction. Have you come to similar conclusions for your other projects?
Matt Wonlaw:
So I guess the short answer is not really. I think the other projects still seem like they're bearing a lot of fruit. SQLite, I had reservations at the beginning, but the old adage, "Don't write your own database," and all these things, coming from Facebook where they're very pragmatic about how they do things. I was like, "Yeah, that culture was instilled in me, so let me make the pragmatic choice here. Let me pull SQLite off the shelf and see how far I can get with it." And then just after a while it was like, "Yeah, I don't think it's going to get all the way to where I want to get it to." And I think part of that is I've been targeting the web platform specifically and I just didn't realize how much of a tax there is crossing from JavaScript to WASM and back and there's a huge performance hit just in that. And maybe if that performance hit wasn't there, I could still continue with SQLite, I'm not sure.
Eric Anderson:
Do you come out the other door, if SQLite isn't the answer, is there something else you lean towards?
Matt Wonlaw:
What I'm leaning towards is just fully investing my time in Materialite and building that up to just not just be incremental view maintenance, but also a regular database under the hood. Yeah, I am leaning into, yeah, I guess, I will build my own database. The upside of that is Materialite actually has the most interest from people financially, so it'd make sense for me to do that too.
Eric Anderson:
I've noticed a little database trend of late where folks seem to not build databases from scratch in the form factor we're used to as much anymore as they borrow this from Postgres or that from ClickHouse. And that database ends up being a federation of database components then like a single monolith. And I'm curious as you approach Materialite, is that going to bear out or...
Matt Wonlaw:
Yeah, I think so. So that's also one of the things that finally pushed me over the edge to maybe I can build my own. I don't know. I feel so arrogant saying this, maybe I can build my own database, but I guess that's why we do hard things, right? We do 'cause we don't know they're hard. But there's a guy at Triplet, I think their founder, he's like, "Yeah, building database probably isn't that hard these days 'cause we have all these key-value stores in B-tree implementations, you can just pull stuff," as you said, "off the shelf." So yeah, that's what I've been doing and the browser has IndexedDB, which is pretty decent abstraction for a key-value store to base the database off of, so I don't have to solve the writing to disk and the durability and all these things. I just really am dealing with that key-value interface. Everything below that is already solved for me.
Eric Anderson:
If Materialite goes the way you want, is this a database in the sense of a local database like a SQLite or is this a distributed database, I don't need Postgres anymore?
Matt Wonlaw:
It'll be a locally embedded database like SQLite, but ideally with collaborative features, right? I think SQLite was built at a time where everybody just had one computer, but now you have multiple devices and you might start work on your phone and continue it on your laptop and then finish it later back on your phone and you want that data obviously to sync between all of them. So I think, yeah, it'd be really cool if an embedded database of the future knew how to sync or merge itself with other copies of itself, so you do-
Eric Anderson:
Got it.
Matt Wonlaw:
... 'Cause I guess going back to Strut.io, when I first quit, I was like, "Oh, I think I can resurrect this old project and make a bunch of money real quick with it." But that project didn't have multiplayer or syncing, so I was like, "Okay, let me just go add that real quick." And I was like, "Oh, this is a mess and that's why I think there's a market here with CR-SQLite." And that's how I started building CR-SQLite, "I think there's a market, let me just go build that general solution." To all that say, syncing is hard, it would be great if something like at the database layer could handle that for developers, so they don't have to be experts in distributed systems.
Eric Anderson:
So I guess this transition, if I'm imagining that is what's happening between your focus on CR-SQLite to Materialite reinforces the fact that Vulcan Labs is the thing that's persistent and continuous. That's where you're being consistent and then you move the locus of attention from one project to the other as needs arise, as conclusions form. Is that fair?
Matt Wonlaw:
Yeah, I guess I started, it was really just Vulcan and it was all going to be a product around CR-SQLite and then I realized I really enjoy solving the difficult problems and not so much the finding collaborators, maybe finding funding, maybe hiring people, the whole business side building. So I was like, "Okay, pivoting it as a research lab and doing contract work for people who also have these problems." It fits my interest and two, it provides some financial stability.
Eric Anderson:
Maybe one question going back to this object-oriented as the big culprit and you mentioned relations to the model, and I think I got that with respect to data modeling and your database. Does that also mean you would avoid objects in more just general programming, like classes are problematic? What's the alternative? Is it functional or is there some other approach?
Matt Wonlaw:
Yeah, I don't think classes are altogether bad, right? I think you still need classes and objects and all these things for...
Eric Anderson:
Abstraction and encapsulation maybe.
Matt Wonlaw:
Yeah. But I'm trying to think of the best way to, there is a separation somewhere, there's like the data for the problem domain you're modeling, and I feel like that should be relational. And then there's the data for your algorithms, maybe your B-tree or your breadth first traversal or whatever these things are. These can be classes and hide their data and have interfaces and whatnot. But the stuff that's part of the problem domain feels like it should be stored in a relational DB and accessed directly through queries.
I guess one other thing that the object model or program memory is missing is good primitives for doing mutations. So if you think about a database, you can start a transaction, you can mutate five things. If you fail in the middle, well, they all get rolled back. They think about your program memory. If you start a bunch of mutations and then you have an exception in the middle, you don't really have a facility to roll back. A few languages have software transactional memory, but not many. And I think that's another big problem as to like... Like people always say, "Oh, global state is a horrible thing," but our databases are shared global mutable state, and we generally don't have that many problems with them. And I think the primitives in our languages are just, we don't have the right mutation primitives, we can't do a transaction, we can't get isolation of transactions, we can't roll things back.
Yeah, I should be able to say, "I want to mutate these five variables, but nobody should be able to see the effects of the mutation until I'm done. And if I fail in the middle, I should be able to revert to the prior state." But yeah, we don't have that in JavaScript or C or whatever.
Eric Anderson:
Interesting, and maybe we don't have those things because the database has done that for us in the past, like we've just said the database is the record of truth for this data and we're going to outsource mutation management to the database. And now as we want to do more of that state management within our programming more directly, do you envision that emerging? Is this the fifth project for Vulcan lab?
Matt Wonlaw:
So I think in the early 2000s, you're right, when pages were, like the LAMP stack and everything was a full page refresh, all your state was in the database and that was the system of record and you had no in-memory state. You had to manage and roll back and do all these things with. I think things were pretty easy back then. And I guess to answer your other question, would I ever do software transactional memory? So I know Clojure has it, they've had it for a really long time. JavaScript, the environment seems so impure, it seems like super hard to pull that off. I don't know if you could pull that off in user space.
Eric Anderson:
So Matt, maybe we can just touch a bit more on the Vulcan Labs model 'cause I think it's an interesting model. So you went into this thinking, "I'm just going to create value, solve big problems, and if people want to fund me, great and if not, we'll figure it out." And people did want to fund you. How does that happen? What are the mechanics 'cause I think that's interesting to some people? They just send you dollar bills in the mail?
Matt Wonlaw:
Yeah, I wish it was that easy. Like okay, some people send you dollar bills in the mail, but they're literally like $5 a month.
Eric Anderson:
Right.
Matt Wonlaw:
To get worthwhile sponsorships, yeah, I was just actually talking with the cut, so finding out which companies were using this stuff. Usually they were talking to me in Discord 'cause they needed support and then finding out who are they, okay, they're part of a company and then just literally having that conversation like, "It looks like this powers one of your products. I'm doing a lot of bug fixes and maintaining things for you. I think it would be fair if you guys contribute a significant amount to this." Yeah, one, so Johannes, he's a guy I talked to. He encouraged me to say, "Oh, are you getting one engineer's salary worth of value out of this? That's how much you should contribute." I never went quite that aggressive. So I went somewhere between $0 to that aggressive, yeah just having those conversations, being upfront that they're getting value and what's the worst that can happen? They can say no, but they're probably still going to use your project, they're not just going to drop it.
I did wait, right? I didn't ask for these donations immediately. I waited till the project was kind of in use in some capacity at their company before asking, which it feels a bit sleazy like, "Oh, I waited until you deployed to production, now I'm asking you for money." But I think everybody understands that you got to make a living somehow.
Eric Anderson:
Yeah, I don't think it's terrible to deliver value and then ask for money. It'd be almost, the reverse seems also equally strange to be like, "I think you should pay me and just hope that I give you something interesting in the end."
Matt Wonlaw:
That's true.
Eric Anderson:
And these people are accommodating. And are there strings attached to that money? Do you implicitly need to serve their needs or do they ask for deliverables?
Matt Wonlaw:
Yeah, it's different for different companies. Some are no-strings attached. It's like, "We're using it, we know how to use it. Whatever support you can provide is fine, but we're not holding you to anything." There have been others that like, "Oh, we want to give you equity and make sure you're aligned with our company's success and sign this contract." Those, I just have to turn down because-
Eric Anderson:
Okay, yeah.
Matt Wonlaw:
... I feel like if I'm going to start tying myself to one specific sponsor, then that might preclude others in the future. And now I'm suddenly worried about what I say publicly or work on in the future, right? For those, I just say, "Yeah, I can't do that. You can just write a sponsorship check or nothing at all." I don't know if you've talked to others in the past who get open source sponsorships and if you have any insights into what other people have done?
Eric Anderson:
GitHub now facilitates some donations and I think Patreon is another kind of channel that I've seen people use. In the case of maybe both of those, there's an option to do a reacquiring, like, "I'm going to subscribe to a donation. I am going to give you 10 bucks a month," which is an interesting model. We've all seen the phrasing around Buy Me A Coffee, which is kind of a fun, it seems like if Matt was in person, I definitely would buy him a coffee. I imagine in most cases your sponsors are buying you much more than that, but do you incorporate as a nonprofit, are you like Mozilla Foundation in a small way?
Matt Wonlaw:
Yeah, these are very good questions. I should talk to somebody who deals with this to give you some advice, but right now, I'm just set up as an LLC. But yeah, I don't know, could I set up as a nonprofit, get better tax benefits or... Yeah, I know there's research tax credits and stuff.
Eric Anderson:
Good. So Matt, I want to pause here 'cause we're approaching end of time. Anything you wanted to cover or that would be good to cover?
Matt Wonlaw:
I think the last thing that's interesting to me is you have an embedded database, which has some set of data on it, but realistically, you probably have... I guess, people have all sorts of different devices with different storage. You have your phone and then your laptop and desktop. So the amount of data in your app on your phone is probably going to be a sliver of what might be on your desktop. So it is really interesting if like can you create an embedded replicated database where on the phone it just has the hot set that the phone is using, but on the desktop it has the full set and can you do queries that span both databases where like, "Oh, it'll query my data locally and then if there's more data, it'll go back to the server or whatever and pull in the rest."
Eric Anderson:
Maybe jamming on that a little bit more broadly. I don't think this is anything new, but I novel all the time when I look through my apps on my phone that I have gigabytes of app on my phone, but very little of my user data. People build apps, they ship them to my phone and then on my phone, I generate data and I ship it to their server and they store my data and I store their app, and I find that a little odd. I feel like I should keep my data, you keep your app. Somehow that's not how mobile is built today. You're describing something that's more nuanced, which is how has this user data persisted and some of it's stored on my client, on desktop we're okay with lots of it being stored and on mobile, you want a little more flexibility to only store what's needed in a critical sense.
Matt Wonlaw:
Yeah, so on mobile, only store what's needed, but how can we hide that complexity from the developer where they're not having to figure out what to store or not. Maybe as they query the database, it sees what you're querying and it pulls in what you need locally and anything you didn't query, stays on the server or desktop, wherever your user data is. 'Cause I guess the Local-First Movement, there's this whole movement called Local-First where it's like users should have all their data on device and all their user data there, but all the solutions in the Local-First space require you syncing all of your data to the app before you can start using it.
And some people in that space say, "Oh, you're never going to generate enough user data to fill your phone. Phones are huge now." Maybe that's true, maybe I'm barking up the wrong tree, but I feel like you do need the ability to start your app with just the slice of user data you need at that moment and as you need it, start syncing it in from, I don't know, your desktop or maybe you have some service provider that you do let you store your aggregate of user data.
Eric Anderson:
I feel like Local-First is often useful for single player applications and I just wonder are they just as useful for these multiplayer applications? In this sense, you bring the whole enterprise's data onto your device?
Matt Wonlaw:
Yeah, so that's where these Local-First solutions have sort of been breaking it down, right? They're good for single player, they're good for multiplayer up to an extent. But then once you get, I don't know, all of Boeing or Lockheed Martin or something, that's a whole enterprise, you're not going to sink down the whole enterprise Wiki and enterprise task tracker and whatever else there is. So yeah, I think in that case where you do have enterprise software where you want to be snappy and fast, where all the data that your employees are using are local on your device, you do need to somehow figure out how to just sync a subset of the enterprise, just what that user commonly uses day-to-day is synced to their device and local for them.
Eric Anderson:
Maybe I am asking you for a hot-take here. If you're spending less time in SQLite at the moment, have you come across PGlite, this kind of like running Postgres on WASM on the client? Is that a thing that we should be keeping an eye on?
Matt Wonlaw:
I've seen it. It looks really cool. I was super blown away. They got the WASM size down like 2.6 megs after compression. I'm like, "Postgres, is that small?" I had no idea. I don't know if they've gripped stuff out. Yeah, I'm super curious. I want to see some benchmarks. Yeah, it's the ElectricSQL, folks. I think Neon working on it, so I know them pretty well. But also I have enough going on, I don't want to distract myself with a new rabbit hole, so I think I'll probably just get a TLDR and try to just file that away for some future problem if it ever comes up.
Eric Anderson:
Well, Matt, I think we're also maybe in kind of conclusion here. Glad not only is your son the beneficiary of you going rogue here with Vulcan Labs, but I think all the world, rather than there being more code in Facebook, we have more code in public and you're solving generalized problems that all programmers face. So thanks for your contributions. I'm excited to see where it takes you.
Matt Wonlaw:
Yeah, thanks for having me.
Eric Anderson:
You can subscribe to the podcast and check out our community Slack and newsletter at contributor.fyi. If you like the show, please leave a rating and review on Apple Podcasts, Spotify or wherever you get your podcasts. Until next time, I'm Eric Anderson and this has been Contributor.
After his first child was born, Matt Wonlaw (@tantaman) imagined giving his son life advice. What kind of life did he want his kid to lead? At the time, he was working for Facebook, and he decided that his own life needed a change in direction. So Matt started vlcn, aka Vulcan Labs, a research company that develops open-source projects like CR-SQLite and Materialite. vlcn has an unusual business model – Matt receives donations and sponsorships from users and clients. It’s all part of his mission to rethink the modern data stack for writing rich and complex applications.
Contributor is looking for a community manager! If you want to know more, shoot us an email at eric@scalevp.com.
Subscribe to Contributor on Substack for email notifications!
In this episode we discuss:
One reason that software is still too hard to write: Object orientations
How CR-SQLite allows databases to be merged together and Materialite provides Incremental View Maintenance for JavaScript
Why coding directly to relations can provide a more flexible and efficient approach to building applications
Matt’s decision to build vlcn as a research lab rather than as a startup
Thoughts for the future on PGLite
Links:
People mentioned:
Johannes Schickling (@schickling)
Matt Wonlaw:
I've always been looking for simpler ways to do things, I think like a lot of engineers are trying to find simpler ways to do things, and yeah, trying out different programming models and whatnot. I guess there's a quote, "I'd rather help people write programs than write programs."
Eric Anderson:
This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson.
Today, we get to talk with Matt Wonlaw, who's the creator and principal at Vulcan Labs. Welcome, Matt.
Matt Wonlaw:
Thanks. Nice to be here.
Eric Anderson:
I don't know if you've ever called yourself the principal of Vulcan Labs. I just made that up.
Matt Wonlaw:
Yeah, no. I guess, founder, but it's a one-man show, so titles don't mean much.
Eric Anderson:
We're going to talk about all the things Vulcan Labs does. One of those things is an open source project, CR-SQLite. We've talked a lot about SQLite on the show lately, so excited to have you. But I want to start, actually, maybe with Vulcan Labs 'cause I think that's the right umbrella for this conversation. You're living the dream in many respects. Tell us about what Vulcan Labs is and how you got into it.
Matt Wonlaw:
Yeah, I think software is too hard to write. The first 80% starts pretty easy, as the saying goes, it's that last 20% and for some reason, it takes forever and everything turns into that spaghetti code. And I was trying to figure out what is it that makes software so hard to write? Is it just like engineers are bad and we need to study harder or is it the tools we're using are the wrong abstractions for the job? They're just not up to today's applications. And I came to the conclusion that the tooling is wrong, and I guess Vulcan Labs is my experiments and explorations in what should the modern dev stack for rich applications like a Figma or a Notion or Spotify, if you were to build those, what primitives do you need to build those? I guess, as a preview, the solutions I've landed on are CR-SQLite. It's basically an extension for SQLite that lets you merge databases. So think of Git for databases in a way, so that's to facilitate collaboration and multiplayer.
The other is Materialite. So this is bringing incremental view maintenance to embedded databases 'cause a lot of queries, you want to be able to subscribe to a query rather than always being request response 'cause then like a UI, you want to know instantaneously what has changed rather than every time someone makes a change, recoding the database. And then the last two things, one is tree SQL. So I think the relational model is the right model, but if you're using a relational model, how do you pull a tree of data out 'cause a lot of times your application, it needs a hierarchy, not some flat set of relations. So if you think like a issue tracker, you might have an issue and that issue has labels and maybe has comments, you might want to pull those as one document. And yeah, the last thing is better integration between the host language and the database. So you have full static typing end-to-end.
Eric Anderson:
The high level idea of, "Software is still too hard to write," is I think a good first principle. I think we can all agree. Is there some fundamental reason for that or is this just a blocking and tackling exercise? We just need to make it easier in a thousand different ways.
Matt Wonlaw:
Object orientation is a big culprit I think. So I think when we model our data with OO, we're bringing some implicit assumptions to the data that we don't realize. So one example is a chair, right? You're going to model a chair in your program. You're going to say your chair is a piece of furniture. Well, that classification of chair as furniture is very dependent on the perspective of the viewer or the person using the chair. Yeah, in my normal life, a chair is a piece of furniture, but if it's really cold outside and I don't have heat, maybe my chair is firewood or if I need to break out of the office, maybe my chair's a battering ram. If I need to block a door, maybe the chair's a barricade. It has all these different roles depending on the context of the viewer. And I think software, as it gets older, gets new requirements that change those fundamental perspectives and your data model, when it's this OO way, it is not flexible enough to adapt to that.
So I think OO is one culprit. Can we code directly to relations? And that got me started down the relational DB path. And then I realized there's other problems here like relational databases are built for this era of request-response. Like you think about the early LAMP stack kind of world where every time a user visited a site, you would request from the database, get all data and show stuff. Whereas if you're building some rich UI like a Spotify, you don't want to have to request to the database every time you make a state change. Every time a state change happens, it should just update, kind of like call you back reactively. So that's kind of where the Materialite project was born of SQLite. And these databases are still in this request-response paradigm. They really need a subscription paradigm where I can say, "Set up all my queries that my app needs and subscribe to them." 'Cause yeah, applications have very static set of queries.
If you think about WhatsApp, it has a query for your threads, your messages, your contact list and those queries don't change every time you open the app. It's really the data that's changing the queries that are static. So for these sort of apps, you need a database that really handles the static query case and dynamically changing data case.
Eric Anderson:
So you have this broader realization that software could be easier in a lot of ways, and if you start identifying these culprits, you're mapping them into projects, was this all happening before you started Vulcan or did you lead to start Vulcan and you're like, "Now what do I do," and happen into this? How long has this been a motivator for you?
Matt Wonlaw:
Ever since I started coding, I've always been looking for simpler ways to do things. I think like a lot of engineers who are trying to find simpler ways to do things and yeah, trying out different programming models and whatnot. I guess there's a quote, "I'd rather help people write programs than write programs," if that makes sense. I'd rather write infrastructure for people. I was doing a lot of that at Facebook and whatnot, but I just wanted to do something that had broader applicability to the whole world and could be open sourced. So after I had my first child, I was thinking in my head, "What am I going to tell him how to live his life?" I was like, "Oh, I'm not living this life," I would tell him. Yeah, I took the plunge and decided to leave my job. But I've always been sort of like keep the fire movement of aggressively saving and stuff being a thing for eight years. I had enough to just take that plunge. I was fortunate enough to be able to do that and work on this stuff full-time.
Eric Anderson:
People tell themselves, "Oh, if I had more financial security, I would do X or Y. That's my true passion." And I challenge them a bit like, "well, Is this true passion of yours really so commercially in-viable?" 'Cause presumably, that passion probably produces some value for society. And I think most people when they realize that, they're like, "Yeah, actually, if I did do this thing I love, it wouldn't be so terrible." And it sounds like you came to that conclusion eventually.
Matt Wonlaw:
Yeah, yeah. That was part of the motivator is like, "If I quit, I'm doing something. It's going to produce money at some point. It's not like I'm going to be living on my savings forever." And I think, yeah, after a year, a year and a half in, some people found CR-SQlite Fly.io specifically and they did a pretty significant sponsorship. And then some people found Materialite and were like, "Oh, we need this in our database and yes, contract to hire." So yeah, money is coming in and it's more than I expected. So yeah, it's been pretty good.
Eric Anderson:
I'm curious now that you've been through this, Matt, what do you think about the future? I'm remembering one of your tweets where you kind of thought, "Oh, a lot of people are chasing this problem area now. Maybe it's time for me to move on to something else." I get the impression that you see yourself as kind of operating at the frontier.
Matt Wonlaw:
Yeah. So what I spent most of my time on was CR-SQlite, which is this concept of can you model SQLite tables with CRDTs so that you can merge databases? The idea would be like this would make collaborative software or software can go offline and come back online. Really easy for developers. They don't have to understand CRDTs themselves, they don't have to understand syncing. They just set up their table say, this column's last-write-wins, this column is some tech CRDT and they just write to their database and the database handles all the merging for them.
And when I started that project, I think there was just Automerge and Yjs, those were two other projects in the space of CRDTs and collaboration and data syncing. But then I guess a year later, we saw ElectricSQL, PowerSync, SQLSync, Replicache. So there was endless entrance into this data syncing space. And yeah, I guess I've never really questioned myself like, "Why do I feel like once it's saturated, I need to move on?" I guess I feel like other people are solving it. There's more interesting stuff to solve next.
So yeah, after I saw so many people working on that problem, I knew in my own apps and apps people have been writing with CR-SQLite, there was this question of I'm using SQLite as my data store, but I have to build this object model on top because I want to be able to react in realtime to mutations. So I was like, "Okay, this seems like a problem where we could have incremental views and subscriptions, where you could subscribe to your queries rather than having to create this separate layer to handle notifications of writes." So that's kind of where I got into incremental view maintenance and Materialite.
Eric Anderson:
You and I have talked a little bit about SQLite and then on the show, we've covered quite a bit. I want to make sure we cover as much as you're interested in covering SQLite 'cause I think it's been an interesting ecosystem for the last little bit. What have you found interesting or what are some topics we should cover today?
Matt Wonlaw:
Well, I guess my latest conclusion is SQLite might not be the right fit for today's like Figmas or Notions like the next set of rich UIs. And why I think that is 'cause, as I said earlier, if you think of an application, the queries are pretty static and the data is what's dynamic. So we really want a facility for doing subscriptions against the database, like for the WhatsApp example. I have a query for my messages, a query for my threads, a query for user status. I just want to subscribe to all those and anytime that data changes, notify me so I can update the UI. With SQLite right now, you can't subscribe to anything, right? You've got to either pull on some interval or you've got to add some layer on top of the database to handle this for you. And once you add a layer on top of the database, you end up with all the same problems that DB was solving for you, right?
A database gives you nice transactions and concurrency control, but if you're going to add a new layer on top, well, you're going to have to think about transactions, concurrency control, and implement all that there. So it would be better if it is in the DB itself. And then, I guess, I briefly touched on the object model is the wrong one. It'd be great if you could just code directly to relations. I think that might be a little wild idea to some people, but if you're coding directly to relations, you need your database to be as fast as memory. So when you write, it finishes as fast as setting a variable. When you read, it's as fast as reading a variable off the JavaScript heap if you're using JS.
And SQLite where every transaction when you commit it has to be durably committed before you can do another operation, I think that's a fundamental problem for if you want to just code directly to relations, where I don't think all commits need to be durably committed before you move on to the next commit 'cause there's plenty of cases in an application where it's fine if you lose the last few commits, if you think of Spotify or something, right? Not every single interaction needs to be durable immediately, and if you can get rid of that durability for every single commit, you can go a lot faster.
Eric Anderson:
Maybe I shouldn't ask this question. What does this coding directly to relations mean? Is this like a graph-like idea or to map it with terms that I've explored before?
Matt Wonlaw:
Yeah, so I guess if you think of Spotify, you have your tracks, you have your Play button, you have your timeline of what's currently where you are in the track. Somehow you have to get the data to those components, essentially the Play state. So when you press Play, all the things can update and show the correct state. And if you're using an object model, maybe you're passing that down to all the components. But if you're coding directly against some relational DB where everything's flat and laid out, like this global data store where every component can just issue a query for the data it needs, so literally just issuing some query for the data it needs and then subscribing to that query. And I guess coding to relations has less of this perspective problem of that chair example of if I need to find something that's firewood, well, I can just query for anything that's made of wood and chairs will come back and that's fine.
Eric Anderson:
Maybe it's worth pointing out. One of the things that's interesting about what you're doing, I think it's kind of orthogonal to the way a lot of the software is developed today, which is individuals have a specific problem in a company, they build some software to solve that specific problem and then they explore whether it can be generalized to a lot of people. And I think you've separated yourself from a specific application and said, "Here's a general problem. Can I come up with a general solution and then explore whether it can apply to certain people's specific problems?" Is that fair to say you're taking the reverse approach to say Uber open source or Google open source?
Matt Wonlaw:
I started... So I guess I'm pulling on my, been doing software development for 15 years and I've noticed these recurring patterns and all sorts of systems we've had to build. So I guess it's pulling on this history of experience in these problems I know I keep dealing with and thinking through why does state management keep coming up as a problem? Why is model view controller always turning into a mess eventually? And I do have this old project I used to use, it's like to validate and test my ideas, Strut.io, it's like this old presentation editor. Yeah, there's some grounding in reality and use case.
Eric Anderson:
Okay, so you went down the SQLite journey, built CR-SQLite, Fly got excited, but over time you came to the conclusion that maybe SQLite isn't the right abstraction. Have you come to similar conclusions for your other projects?
Matt Wonlaw:
So I guess the short answer is not really. I think the other projects still seem like they're bearing a lot of fruit. SQLite, I had reservations at the beginning, but the old adage, "Don't write your own database," and all these things, coming from Facebook where they're very pragmatic about how they do things. I was like, "Yeah, that culture was instilled in me, so let me make the pragmatic choice here. Let me pull SQLite off the shelf and see how far I can get with it." And then just after a while it was like, "Yeah, I don't think it's going to get all the way to where I want to get it to." And I think part of that is I've been targeting the web platform specifically and I just didn't realize how much of a tax there is crossing from JavaScript to WASM and back and there's a huge performance hit just in that. And maybe if that performance hit wasn't there, I could still continue with SQLite, I'm not sure.
Eric Anderson:
Do you come out the other door, if SQLite isn't the answer, is there something else you lean towards?
Matt Wonlaw:
What I'm leaning towards is just fully investing my time in Materialite and building that up to just not just be incremental view maintenance, but also a regular database under the hood. Yeah, I am leaning into, yeah, I guess, I will build my own database. The upside of that is Materialite actually has the most interest from people financially, so it'd make sense for me to do that too.
Eric Anderson:
I've noticed a little database trend of late where folks seem to not build databases from scratch in the form factor we're used to as much anymore as they borrow this from Postgres or that from ClickHouse. And that database ends up being a federation of database components then like a single monolith. And I'm curious as you approach Materialite, is that going to bear out or...
Matt Wonlaw:
Yeah, I think so. So that's also one of the things that finally pushed me over the edge to maybe I can build my own. I don't know. I feel so arrogant saying this, maybe I can build my own database, but I guess that's why we do hard things, right? We do 'cause we don't know they're hard. But there's a guy at Triplet, I think their founder, he's like, "Yeah, building database probably isn't that hard these days 'cause we have all these key-value stores in B-tree implementations, you can just pull stuff," as you said, "off the shelf." So yeah, that's what I've been doing and the browser has IndexedDB, which is pretty decent abstraction for a key-value store to base the database off of, so I don't have to solve the writing to disk and the durability and all these things. I just really am dealing with that key-value interface. Everything below that is already solved for me.
Eric Anderson:
If Materialite goes the way you want, is this a database in the sense of a local database like a SQLite or is this a distributed database, I don't need Postgres anymore?
Matt Wonlaw:
It'll be a locally embedded database like SQLite, but ideally with collaborative features, right? I think SQLite was built at a time where everybody just had one computer, but now you have multiple devices and you might start work on your phone and continue it on your laptop and then finish it later back on your phone and you want that data obviously to sync between all of them. So I think, yeah, it'd be really cool if an embedded database of the future knew how to sync or merge itself with other copies of itself, so you do-
Eric Anderson:
Got it.
Matt Wonlaw:
... 'Cause I guess going back to Strut.io, when I first quit, I was like, "Oh, I think I can resurrect this old project and make a bunch of money real quick with it." But that project didn't have multiplayer or syncing, so I was like, "Okay, let me just go add that real quick." And I was like, "Oh, this is a mess and that's why I think there's a market here with CR-SQLite." And that's how I started building CR-SQLite, "I think there's a market, let me just go build that general solution." To all that say, syncing is hard, it would be great if something like at the database layer could handle that for developers, so they don't have to be experts in distributed systems.
Eric Anderson:
So I guess this transition, if I'm imagining that is what's happening between your focus on CR-SQLite to Materialite reinforces the fact that Vulcan Labs is the thing that's persistent and continuous. That's where you're being consistent and then you move the locus of attention from one project to the other as needs arise, as conclusions form. Is that fair?
Matt Wonlaw:
Yeah, I guess I started, it was really just Vulcan and it was all going to be a product around CR-SQLite and then I realized I really enjoy solving the difficult problems and not so much the finding collaborators, maybe finding funding, maybe hiring people, the whole business side building. So I was like, "Okay, pivoting it as a research lab and doing contract work for people who also have these problems." It fits my interest and two, it provides some financial stability.
Eric Anderson:
Maybe one question going back to this object-oriented as the big culprit and you mentioned relations to the model, and I think I got that with respect to data modeling and your database. Does that also mean you would avoid objects in more just general programming, like classes are problematic? What's the alternative? Is it functional or is there some other approach?
Matt Wonlaw:
Yeah, I don't think classes are altogether bad, right? I think you still need classes and objects and all these things for...
Eric Anderson:
Abstraction and encapsulation maybe.
Matt Wonlaw:
Yeah. But I'm trying to think of the best way to, there is a separation somewhere, there's like the data for the problem domain you're modeling, and I feel like that should be relational. And then there's the data for your algorithms, maybe your B-tree or your breadth first traversal or whatever these things are. These can be classes and hide their data and have interfaces and whatnot. But the stuff that's part of the problem domain feels like it should be stored in a relational DB and accessed directly through queries.
I guess one other thing that the object model or program memory is missing is good primitives for doing mutations. So if you think about a database, you can start a transaction, you can mutate five things. If you fail in the middle, well, they all get rolled back. They think about your program memory. If you start a bunch of mutations and then you have an exception in the middle, you don't really have a facility to roll back. A few languages have software transactional memory, but not many. And I think that's another big problem as to like... Like people always say, "Oh, global state is a horrible thing," but our databases are shared global mutable state, and we generally don't have that many problems with them. And I think the primitives in our languages are just, we don't have the right mutation primitives, we can't do a transaction, we can't get isolation of transactions, we can't roll things back.
Yeah, I should be able to say, "I want to mutate these five variables, but nobody should be able to see the effects of the mutation until I'm done. And if I fail in the middle, I should be able to revert to the prior state." But yeah, we don't have that in JavaScript or C or whatever.
Eric Anderson:
Interesting, and maybe we don't have those things because the database has done that for us in the past, like we've just said the database is the record of truth for this data and we're going to outsource mutation management to the database. And now as we want to do more of that state management within our programming more directly, do you envision that emerging? Is this the fifth project for Vulcan lab?
Matt Wonlaw:
So I think in the early 2000s, you're right, when pages were, like the LAMP stack and everything was a full page refresh, all your state was in the database and that was the system of record and you had no in-memory state. You had to manage and roll back and do all these things with. I think things were pretty easy back then. And I guess to answer your other question, would I ever do software transactional memory? So I know Clojure has it, they've had it for a really long time. JavaScript, the environment seems so impure, it seems like super hard to pull that off. I don't know if you could pull that off in user space.
Eric Anderson:
So Matt, maybe we can just touch a bit more on the Vulcan Labs model 'cause I think it's an interesting model. So you went into this thinking, "I'm just going to create value, solve big problems, and if people want to fund me, great and if not, we'll figure it out." And people did want to fund you. How does that happen? What are the mechanics 'cause I think that's interesting to some people? They just send you dollar bills in the mail?
Matt Wonlaw:
Yeah, I wish it was that easy. Like okay, some people send you dollar bills in the mail, but they're literally like $5 a month.
Eric Anderson:
Right.
Matt Wonlaw:
To get worthwhile sponsorships, yeah, I was just actually talking with the cut, so finding out which companies were using this stuff. Usually they were talking to me in Discord 'cause they needed support and then finding out who are they, okay, they're part of a company and then just literally having that conversation like, "It looks like this powers one of your products. I'm doing a lot of bug fixes and maintaining things for you. I think it would be fair if you guys contribute a significant amount to this." Yeah, one, so Johannes, he's a guy I talked to. He encouraged me to say, "Oh, are you getting one engineer's salary worth of value out of this? That's how much you should contribute." I never went quite that aggressive. So I went somewhere between $0 to that aggressive, yeah just having those conversations, being upfront that they're getting value and what's the worst that can happen? They can say no, but they're probably still going to use your project, they're not just going to drop it.
I did wait, right? I didn't ask for these donations immediately. I waited till the project was kind of in use in some capacity at their company before asking, which it feels a bit sleazy like, "Oh, I waited until you deployed to production, now I'm asking you for money." But I think everybody understands that you got to make a living somehow.
Eric Anderson:
Yeah, I don't think it's terrible to deliver value and then ask for money. It'd be almost, the reverse seems also equally strange to be like, "I think you should pay me and just hope that I give you something interesting in the end."
Matt Wonlaw:
That's true.
Eric Anderson:
And these people are accommodating. And are there strings attached to that money? Do you implicitly need to serve their needs or do they ask for deliverables?
Matt Wonlaw:
Yeah, it's different for different companies. Some are no-strings attached. It's like, "We're using it, we know how to use it. Whatever support you can provide is fine, but we're not holding you to anything." There have been others that like, "Oh, we want to give you equity and make sure you're aligned with our company's success and sign this contract." Those, I just have to turn down because-
Eric Anderson:
Okay, yeah.
Matt Wonlaw:
... I feel like if I'm going to start tying myself to one specific sponsor, then that might preclude others in the future. And now I'm suddenly worried about what I say publicly or work on in the future, right? For those, I just say, "Yeah, I can't do that. You can just write a sponsorship check or nothing at all." I don't know if you've talked to others in the past who get open source sponsorships and if you have any insights into what other people have done?
Eric Anderson:
GitHub now facilitates some donations and I think Patreon is another kind of channel that I've seen people use. In the case of maybe both of those, there's an option to do a reacquiring, like, "I'm going to subscribe to a donation. I am going to give you 10 bucks a month," which is an interesting model. We've all seen the phrasing around Buy Me A Coffee, which is kind of a fun, it seems like if Matt was in person, I definitely would buy him a coffee. I imagine in most cases your sponsors are buying you much more than that, but do you incorporate as a nonprofit, are you like Mozilla Foundation in a small way?
Matt Wonlaw:
Yeah, these are very good questions. I should talk to somebody who deals with this to give you some advice, but right now, I'm just set up as an LLC. But yeah, I don't know, could I set up as a nonprofit, get better tax benefits or... Yeah, I know there's research tax credits and stuff.
Eric Anderson:
Good. So Matt, I want to pause here 'cause we're approaching end of time. Anything you wanted to cover or that would be good to cover?
Matt Wonlaw:
I think the last thing that's interesting to me is you have an embedded database, which has some set of data on it, but realistically, you probably have... I guess, people have all sorts of different devices with different storage. You have your phone and then your laptop and desktop. So the amount of data in your app on your phone is probably going to be a sliver of what might be on your desktop. So it is really interesting if like can you create an embedded replicated database where on the phone it just has the hot set that the phone is using, but on the desktop it has the full set and can you do queries that span both databases where like, "Oh, it'll query my data locally and then if there's more data, it'll go back to the server or whatever and pull in the rest."
Eric Anderson:
Maybe jamming on that a little bit more broadly. I don't think this is anything new, but I novel all the time when I look through my apps on my phone that I have gigabytes of app on my phone, but very little of my user data. People build apps, they ship them to my phone and then on my phone, I generate data and I ship it to their server and they store my data and I store their app, and I find that a little odd. I feel like I should keep my data, you keep your app. Somehow that's not how mobile is built today. You're describing something that's more nuanced, which is how has this user data persisted and some of it's stored on my client, on desktop we're okay with lots of it being stored and on mobile, you want a little more flexibility to only store what's needed in a critical sense.
Matt Wonlaw:
Yeah, so on mobile, only store what's needed, but how can we hide that complexity from the developer where they're not having to figure out what to store or not. Maybe as they query the database, it sees what you're querying and it pulls in what you need locally and anything you didn't query, stays on the server or desktop, wherever your user data is. 'Cause I guess the Local-First Movement, there's this whole movement called Local-First where it's like users should have all their data on device and all their user data there, but all the solutions in the Local-First space require you syncing all of your data to the app before you can start using it.
And some people in that space say, "Oh, you're never going to generate enough user data to fill your phone. Phones are huge now." Maybe that's true, maybe I'm barking up the wrong tree, but I feel like you do need the ability to start your app with just the slice of user data you need at that moment and as you need it, start syncing it in from, I don't know, your desktop or maybe you have some service provider that you do let you store your aggregate of user data.
Eric Anderson:
I feel like Local-First is often useful for single player applications and I just wonder are they just as useful for these multiplayer applications? In this sense, you bring the whole enterprise's data onto your device?
Matt Wonlaw:
Yeah, so that's where these Local-First solutions have sort of been breaking it down, right? They're good for single player, they're good for multiplayer up to an extent. But then once you get, I don't know, all of Boeing or Lockheed Martin or something, that's a whole enterprise, you're not going to sink down the whole enterprise Wiki and enterprise task tracker and whatever else there is. So yeah, I think in that case where you do have enterprise software where you want to be snappy and fast, where all the data that your employees are using are local on your device, you do need to somehow figure out how to just sync a subset of the enterprise, just what that user commonly uses day-to-day is synced to their device and local for them.
Eric Anderson:
Maybe I am asking you for a hot-take here. If you're spending less time in SQLite at the moment, have you come across PGlite, this kind of like running Postgres on WASM on the client? Is that a thing that we should be keeping an eye on?
Matt Wonlaw:
I've seen it. It looks really cool. I was super blown away. They got the WASM size down like 2.6 megs after compression. I'm like, "Postgres, is that small?" I had no idea. I don't know if they've gripped stuff out. Yeah, I'm super curious. I want to see some benchmarks. Yeah, it's the ElectricSQL, folks. I think Neon working on it, so I know them pretty well. But also I have enough going on, I don't want to distract myself with a new rabbit hole, so I think I'll probably just get a TLDR and try to just file that away for some future problem if it ever comes up.
Eric Anderson:
Well, Matt, I think we're also maybe in kind of conclusion here. Glad not only is your son the beneficiary of you going rogue here with Vulcan Labs, but I think all the world, rather than there being more code in Facebook, we have more code in public and you're solving generalized problems that all programmers face. So thanks for your contributions. I'm excited to see where it takes you.
Matt Wonlaw:
Yeah, thanks for having me.
Eric Anderson:
You can subscribe to the podcast and check out our community Slack and newsletter at contributor.fyi. If you like the show, please leave a rating and review on Apple Podcasts, Spotify or wherever you get your podcasts. Until next time, I'm Eric Anderson and this has been Contributor.