Wrapping Up

[00:00:00]
>> Brian Holt: That was a complete intro to SQLite. It's pretty cool, I think. In this course, you should have hopefully picked up on a little bit of SQL, if it wasn't familiar to you, if it was, hopefully there was some refreshers and some new things that you learned. Yeah, hopefully I shed some light on how SQLite fits into the ecosystem.

[00:00:21]
And it's gone from kind of a grow up from this local library that was only meant for embedded systems, all the way to now powerful cloud database area. So again, people like to ask me which one's my favorite. I think I've probably talked about it enough. You can probably guess that I do like Postgres, but I don't regret any time with SQLite.

[00:00:47]
I've really enjoyed it. I'll fix this link here, but I do have another course on Intro to Databases, which goes over Postgres, Mongo, Redis, and Neo4j. That's another good course if you're interested in getting kind of more varieties of other databases that are out there, all really cool things as well.

[00:01:08]
In general, Postgres has gotten so far that it's just kind of a general purpose tool for everything. It handles queues, it handles key value stores, it handles document based storage, it just does so much now. But SQLite is making bounds, particularly with some of the powerful people behind it, like the powerful movement that's growing behind it.

[00:01:30]
So we went over how to get SQLite running, the basics of SQL, how to build an app with Node JS, what's unique to SQLite, how to use JSON extension, and just extensions in general. Some of the performance aspects of it, some of the futuristic cool stuff that's like recent innovations with Litestream, LiteFS, the libSQL, and a little bit of local first development, kind of first steps into that kind of area.

[00:02:00]
So with that, I'll take any questions if there's any left here.
>> Speaker 2: Do you have any thoughts on when local first wouldn't be a good idea?
>> Brian Holt: I do. It is more complicated infrastructure, so you're gonna end up with just more stuff to worry about. That can be problematic.

[00:02:20]
As far from a use case, if you are very consistency bound, again, if you read from the database and you have no tolerance for it being late, that's not a good thing for local first cuz you have to be okay with eventual consistency. You wouldn't use Mongo. Mongo has eventual consistency.

[00:02:43]
You wouldn't use Cassandra, another eventually consistent database. You would use something like Postgres, and turn on all the consistency knobs, right? It's like, if this is written to the database, I need you to acknowledge for all of my secondary replicas that it's been written to those as well before we return is true, right?

[00:03:03]
That's probably the biggest one I would think of. Local first requires some discipline of how you structure your data as well. Because as you imagine, you don't wanna send an entire copy of your database to your user because there could be a lot of private information in there.

[00:03:19]
So you have to structure it in such a way that you can kind of section off little shards of data to give to your user that's okay for them to know about, write to all those kind of things. And if you can't structure your data that way, then you can't do local first.

[00:03:35]
And then the other thing is you are targeting browsers that can handle WebAssembly. So if you're targeting 2G devices in the middle of Montana or the middle of India or something like that, local first is not gonna help you, right? Because those probably can't run WebAssembly with any amount of speed.

[00:03:58]
>> Brian Holt: But if you're targeting iPhone users in Montana, rural Montana or India, it was actually a perfect use case for that because when they're on Wi-Fi, they can get their data and then they can go offline and it works really well, right? So that's some initial thoughts, I'm sure I'm missing some stuff, but that's at least a good place to get started.

[00:04:20]
>> Speaker 2: When would you use something like Neon?
>> Brian Holt: All the time, just kidding. Yeah, I get a bonus every time I say that. My opinion on Postgres is that it's the default database for most use cases, and that for me personally, I need a reason to not use Postgres.

[00:04:42]
I need to use Neo4j's cuz I have graph and I'm just using graph, right? Then I would use Neo4j's, or some other graph based database. So with that in mind and my bias towards it that existed even before I started working at Neon. I like Neon because I like serverless, right?

[00:05:01]
And that's what they did. They took it apart the database, they separated the storage and the compute layer so that it can scale independently. And you only pay for consumption. So if you're not doing very much, you don't pay very much, which is cool. So to answer the question of when do I use Neon, I use Neon unless I have a reason not to, which there are some.

[00:05:23]
There's some reasons to host Postgres yourself. There's some reasons to host Postgres other places, cuz they have different features that Neon doesn't have. But Neon for the most part, is just stock serverless Postgres, which is just knowable, right, which I quite appreciate, all right? Well, thank you, hope you enjoyed the course, and we'll see you next time.

[00:05:45]
>> [APPLAUSE]