Update content/blog/2025-09-10-numbered-databases/index.md

Co-authored-by: Madelyn Olson <[email protected]>
Signed-off-by: Kyle J. Davis <[email protected]>

Author: stockholmux

content/blog/2025-09-10-numbered-databases/index.md

@@ -72,7 +72,7 @@ The second use of `MOVE` is similar to the first except it revolves around compl
 This is really a form of temporal namespacing: you're taking advantage of the namespace to have two active keys under the same name both of which can be read and manipulated. You can apply this pattern to other cases: anyplace you want to make a key inaccessible for a period of time.
 
 > **How is key prefixing different than numbered databases?** Some of the patterns in this blog can be achieved without numbered databases and instead with key prefixing (e.g. `app0:...`, `app1:...`). Key prefixing has a few downsides when compared to numbered databases:
-> * Prefixes add up at scale. Millions of keys each with repeated prefixes over the span of the whole cluster means less RAM for data. While each database does have a memory overhead it is linear relative to the number of databases used, not keys. For a deeper look a how numbered database memory overhead works, including using 10 million databases, read the comments on [valkey-io/valkey#1609](https://github.com/valkey-io/valkey/pull/1609#issuecomment-2616366819).
+> * Prefixes add up at scale. Millions of keys each with repeated prefixes over the span of the whole cluster means less RAM for data. While each database does have a memory overhead it is linear relative to the number of databases used, not keys. For a deeper look at how numbered database memory overhead works, including using 10 million databases, read the comments on [valkey-io/valkey#1609](https://github.com/valkey-io/valkey/pull/1609#issuecomment-2616366819).
 > * Databases are transparent to your application. To support prefixing, either your application or your client library has to be able to interpolate the prefix into each key. With numbered databases, the changes can be as simple as a number in the connection URI, not to each key name.
 > * Databases avoid pattern-based iterations. Having all your keys in DB 0 then needing to iterate over the entire keyspace to affect a specific pattern is expensive and complicated. If your keys are separated into databases, this both subsets that iteration and enables some database wide commands (i.e. `FLUSHDB` instead of trying to delete keys by a pattern).