I told you that a SQLite database is just a file on disk, which is very different than how MySQL and Postgres works. But is it better? I don't know. I'm not interested in absolute pronouncements. I will tell you about the file and we can decide together if it's good for your use case.

So this file, very, very strictly defined format. That's one of its great strengths is its file format is very rigid and very well known. It has great backwards compatibility and you can trust that it has forwards compatibility. And so if you put all of your data into this SQLite database file, the odds are nearing 100% that every computing platform will be able to read the data in that file. Extremely cross platform, cross architecture, cross everything.

So that's one of the great strengths is if you put your data in this file, you can distribute it very easily. This makes it really nice for sending out data sets to clients, whether that's a front end or a mobile device or a desktop device or just other servers somewhere. It makes a nice, data packaging format. The other thing is that future compatibility. You know that you're pretty safe storing your data in a SQLite file because of their insane commitment to backwards compatibility and the fact that if it's good enough for the Library of Congress in the US, it's probably good enough for my web application, mobile desktop application, whatever it is.

The other thing is there's no overhead for creating a new database. So if you wanna go multi database, multi tenant, which we'll talk about later, that's great. If you wanna create a new database for each service, so maybe you have a database to store like your actual data and then one to run your queues and one to serve as a cache back end, that's great. You can do that. That's just 3 separate files at that point.

So the fact that it's a file I think is a benefit in a lot of situations. It can be a drawback because the file has to live on a disk that's not ephemeral. So you can't have, you can't have it living on a serverless disk. Right? You can't have it in Lambda because that Lambda's gonna go away eventually.

There are ways around that, with with things like Turso, honestly. But we'll look at that as we move forward. But that is a drawback of it being a single file. I think one of the final things that the low overhead file only approach allows for is it's great for testing. So when you're running your CI or CD, it makes it very easy to use SQLite just like you do in production.

In fact, at that point it doesn't even have to be a file. You can just load the data into memory and SQLite can deal with it there. So instead of having to run MySQL locally, MySQL in CICD and MySQL in production, You can just use SQLite and the the the barrier to entry is a lot lower and it makes your tests a lot faster and a lot more compatible with production which is what we're always after. So just a single file, pretty cool honestly. It has some drawbacks but it opens up a lot of use cases which we'll continue to cover throughout this course.