Why Use a Key-Value Store

[00:00:00]
>> Brian Holt: OK, so we are going to get back on here. We've done images. We're going to do key-value store. So what is a key-value store? I like them. I think they're a lot of fun to work with and they're like really simple for the most part, like pieces of technology, but they're highly optimized so that you can just like have tons of traffic on one node and it just works really well. But they're also really restricted in what they're able to accomplish.

[00:00:35]
As a like for a hackathon for Neon one time, I actually took the Redis wire protocol. It's like the way that your SDK speaks to the Redis, and I re-implemented it on top of Postgres. And so you can actually see here like the code for it. It's actually somewhat simple. So like here's a set, for example. So it just takes in this and then, well, let's do it again because it gets probably more interesting.

[00:01:07]
So it all does is like doing a select here, but like it just speaks this protocol where it's just like a lot of like new lines and tabs between everything. And as long as you like get the op codes correctly, it's everything just works. So you can directly write Redis to Postgres. Don't get me wrong, this is like 10 orders, 1000 orders of magnitude slower than Redis is itself. But at its key, like it was easy enough for me to like re-implement this in just like a couple lines of code, which is kind of cool.

[00:01:41]
So if you're interested, I do teach this course here, Complete Intro to Databases. That's on Frontend Masters, and we do go kind of in more into depth here on Redis, why you would use it, how to use it. There's also some other key-value stores you can use. You can actually use Postgres has something called HStore, which is like a pseudo key-value store as like a column in a database. That's actually what the other project I was just showing you.

[00:02:06]
It actually is using HStore. There's also one called Memcached. Memcached only lives in memory. It doesn't write anything to disk. So that says whenever you shut down the node, everything goes with it, right? But the tradeoff is like if you're not writing to disk, it's extremely fast, right? It's super, super fast. Redis is like a nice happy medium there where like it is very fast, but it also does flush to disk.

[00:02:35]
So that if your Redis goes down and you have to bring it back up, you can still have everything. There's also like some replication. There's a bunch of stuff you can do with Redis as well. And it's, I guess it bears mentioning Valkey. I won't get too much into it, though it is some fun spicy drama. Valkey is essentially Redis. Redis put some like restrictive terms on like how people could use Redis, and so the open source community kind of revolted a little bit, and they're like, cool, well, this is a key-value store.

[00:03:09]
We can re-implement it ourselves, and so they did. And so that's where Valkey came from, and then Redis realized like this is going to crash their business, so they like relaxed it. So now people are using Redis again. All this to say is Valkey, Redis, I think like 99% the same thing, right? One's just like a little bit more open source, whereas Redis is a full-on company, right? Up to you. I'm just throwing it out there that it exists.

[00:03:39]
So what is a key-value store? What is Redis? Why are we talking about this? Who cares? You can think of Redis like the world's biggest, fastest, most remote JavaScript object. So if I have a Redis store object and I say Redis store my key equals 5, how do I get it back out of that? Well, I say what is my key, right? It's a bit of a truism. I understand it's a very simple example, right? But like essentially you set a key and it gives you back a value, right?

[00:04:15]
And that's the whole kind of operation there. Redis works very much the same way where you say Redis set key to be this, right? That's equivalent to this. And then later you say, hey, give that thing back to me. I want my key back, and it gives you back the key. Why is this interesting? It's very fast and it's very remote. So like if I'm setting a cache for, let's say like a, in fact, this is literally what we're going to do.

[00:04:55]
If we go back to my page, is this running? Yeah, OK, this network. Well, the SQL statement to retrieve all of the rows out of my database, it runs every single time this page loads. So if I have a million people on my site all at once, it's going to run that SQL query against Postgres a million times. That's a lot of load on your database, right? And this is just a simple select statement. It's not that bad, but imagine if you have like joins and it was like all sorts of like, you know, kind of gnarly stuff coming together.

[00:05:28]
This is a really good case where we could cache the results of our SQL statement using Redis, right? So rather than hitting Postgres a million times, we're hitting Redis a million times. Redis is much better set up to be hit a million times than Postgres is. Don't get me wrong, Postgres scales amazingly. It's a fantastic piece of software. But it has its limitations, and this is where a key-value store is kind of designed to come in and absorb quite a bit of that load.

[00:05:52]
Does that make sense? There's another thing that we're going to do in here. We're going to track page views. You could definitely do that by inserting into your database, like I had a page view, right? But it's expensive, right? Whereas like, and we also don't care if we like lose that data, like if you lose the page views on a page, not the end of the world, right? So it's not like high value. So Redis is also perfect for something like that where you can store kind of like useful but like not critical data that can be retrieved later.

[00:06:32]
That's, you know, cheap to set and get, essentially. Makes sense so far? Yeah, so what would be like the way to compare, you know, using Redis versus caching with, let's say, React Query and caching locally on the browser? Like when would you say I would use Redis for this use case and then I would use like React Query or something like that? Like the concept is really similar here, but they serve pretty distinct use cases.

[00:07:02]
So if I use React Query and I query my API and I store locally, I'm doing that more so I don't have to make multiple round trips. So what I'm saving here is not server load. I guess it is to some extent. It's like a byproduct, though. It's not the focus. It's more that if a user, like the app requests it again, it's already there locally and it doesn't have to do another round trip. I don't do that to save API hits or like API load.

[00:07:27]
To some degree, I guess it helps, but I'm doing it more because the latency is so fast, right? So it's already there. It's already ready for the user to like query against. I'm going to use this on the server side so that I can actually like save load from my database or from other services or something like that. I'm trying to think. At LinkedIn, or is this LinkedIn? Was this Netflix? Oh, it's Netflix.

[00:07:51]
Running our recommendations engine was like really expensive because it was doing like a huge amount of spidering to figure out like you watched this, this, this, and this. That correlates to these things according to our machine learning algorithm. This was a decade ago, so we didn't have AI or anything like that. Those intermediary results of like this user has watched this and could watch these things, it was very expensive for us to run.

[00:08:19]
And so if we did that on every single request, we would crash all of our servers, right? So what we would do is instead, we would run that query and then we would stick it in this. It was a different key-value store called Voldemort, but regardless, the same idea. And we stick those intermediary results into this so that when the API requested it, it was not actually hitting like the whole AI pipeline.

[00:08:42]
It was just hitting these like key-value store. So it's a cache, right? It's like a cache so you can cache results in the intermediaries. That makes sense? So in our case, we don't want to hit the database every single time someone goes to the homepage. That's expensive. It's expensive. It would be fine, but in Ferrari, so that we can see where you would put these kind of things, we'll make it so that we don't have to query the database every single time someone hits the homepage.

[00:09:18]
So we're going to use another service that I'm quite fond of. It's called Upstash. And these folks do quite a few things. We're just going to use them for a serverless Redis. So like Neon is to Postgres, Upstash is to Redis. It's serverless. You don't have to care about how big this is, to scale up, to scale down. This is something that Upstash just totally hides from you. I like it. If you've ever used the Context 7 MCP server, which I use it quite a bit, this is from them as well.

[00:09:57]
It's kind of demonstrating the power of their serverless Redis platform. So please go ahead and sign in or sign up. Excuse me. Let me go to the dashboard. OK, so I have a few here already. I believe you get one for free. Again, I'm a paid customer, so I'm going to be able to create a third one, and we're going to call this FAM Wiki Masters. Try and get it as close to your other ones. I think, yeah, Ohio is perfect for me.

[00:10:30]
That's where I'm right now. I'm not going to create any read replicas. You could here. And I'm not going to set eviction, but again, you could here. I'm doing pay as I go, which is fine. And that is a huge budget. I do not want to spend that much. $100 is great. I do not want SOC 2. I do not want HIPAA. I don't want RBAC. I don't want Prometheus. OK. And now I have Redis in front of me. Again, you could totally run Redis locally.

[00:11:07]
I'm super OK with that as well. And then it's pretty easy to set it up in like a Docker Compose kind of format as well if you want to do it that way. All of the major cloud providers have some version of Redis or key-value store. You could run Memcached here as well. There's a bunch of stuff. OK, so we're going to use their, um, so I'm going to say npm i @upstash/redis. I don't actually really know what's different about their SDK.

[00:11:40]
Obviously I know a lot of why the Neon one's different because I work on it, but they do have their own Redis client. You could definitely use ioredis or node-redis as well. Those are like the, I don't say they're the official ones, so they're most commonly used Redis clients. But we're using Upstash. We might as well like it. Yeah, and I'll say Upstash has other stuff too, but I've only ever used them for key-value store.