We talked about the good use cases of SQLite. Let's talk about the not so good use cases. Let's talk about some of the limitations. It's fine. We just need to know when to use it and when not to.

So the first one is when you have a huge number of concurrent writers writing to the database. If you have a massive number of writers you're probably better off using one of the client server databases. MySQL, Postgres both would work just fine. If you have a huge number of readers that's okay, SQLite can handle that.

So we're gonna look at a few settings as we move forward to, to make concurrency less of an issue. But if you're talking about many thousands of writes per second, that's the point where you might start thinking, well maybe I should move off. With these settings that we're gonna use, the wall mode, which is something you're gonna hear about a lot. That's the first time I've said it, but you're gonna hear that a lot. With the wall mode, we can make, rider contention less of an issue but it's still going to be an issue.

So that's that's the first one. The second one is, if you have multiple machines that need to talk to the same database is a file. A file lives on a machine. Now you can have it on a network attached storage device or some sort of otherwise network file system. They don't super recommend that because the file locking could be buggy in those cases, and that can lead that can lead to some bad stuff.

If you can't trust if you can't trust the file system locks, SQLite is gonna have a hard time ensuring that it doesn't become corrupt. So the moment you need to scale out to multiple machines, that might be a time to look for something besides SQLite. There are a few tools, of which Turso is one that can put embedded replicas on multiple machines which is super interesting. So all your reads can come from the machine that they're on and your writes can go back to a central machine. But that requires extra extra tooling.

We're not afraid of extra tooling but I'm trying to explain what vanilla SQLite is capable of. And multiple machines is not one of them. So high riders, high number of concurrent riders needing needing to access it over a network. Those are two times you wouldn't want to reach for SQLite. The third or a third is once you start reaching a certain size of database.

Theoretically, SQLite can handle 281 terabytes, in a single database. That's not actually possible probably because I don't know where you would put a single file that's 281 terabytes. But theoretically, it can support that much. I think realistically, when you hit start to hit about a terabyte of data, that's when you might wanna start looking somewhere else. But before that, honestly, you're good.

So those are those are a few of the times you might think about not choosing SQLite. Beyond that beyond that, you're pretty good. I forgot one. One other one other would be fine grained privileges. SQLite, it just doesn't have fine grained privileges.

It's just you get access to the database or you don't. So if you need fine grain fine grained access control that sort of stuff, SQLite's not gonna be the best option there. But unless I've forgotten another one, that should be it. So there are good use cases and bad use cases. Hopefully this helps you decide when SQLite is right for you.

Let's move on and learn more about SQLite.