Conversation
🛡️ Jit Security Scan Results
✅ No security findings were detected in this PR
Security scan by Jit
|
|
@rrelledge the screenshot for the "create a database" step is really large. You could scale it down to half that size I think |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 3 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
| - Reduce infrastructure costs by combining high-speed RAM with cost-efficient flash storage | ||
|
|
||
| {{<note>}} | ||
| Flex does not replace long-term data persistence. For workloads that require durability and recovery across restarts or failures, use Redis persistence features like [AOF (Append-Only File)]({{< relref "/operate/oss_and_stack/management/persistence#append-only-file" >}}), [RDB snapshots]({{< relref "/operate/oss_and_stack/management/persistence#snapshotting" >}}), or both. For more information, see [Database persistence]({{< relref "/operate/rs/databases/configure/database-persistence" >}}). |
There was a problem hiding this comment.
I suggest adding a dedicated "What Flex isn't" section with the wording similar to the doc: https://docs.google.com/document/d/1PuFejCooJpy_gs0MoM5Pf9MLS46x6gcNUmzYfPjIHik/edit?disco=AAABz_t08H0&tab=t.0
There was a problem hiding this comment.
This info is already included in a note in https://redis.io/docs/staging/DOC-6284/operate/rs/flex/#when-to-use-flex:
Note:
Flex does not replace long-term data persistence. For workloads that require durability and recovery across restarts or failures, use Redis persistence features like AOF (Append-Only File), RDB snapshots, or both. For more information, see Database persistence.
There was a problem hiding this comment.
I agree the content is indeed present, In my opinion we should have an explicit and dedicated "When not to use Flex" - up to you, resolving this comment :)
|
Thank you this is looking great |
|
|
||
| You can add more shards to expand dataset capacity while maintaining the existing RAM-to-flash ratio. Throughput capacity also typically increases as a result of additional shards and infrastructure. This strategy is recommended when the dataset size and traffic are expected to grow together. | ||
|
|
||
| Before you increase the dataset capacity and add shards, you need to add more RAM and vCPUs to handle the increased number of shards. |
There was a problem hiding this comment.
Let's make it more explicit:
This increases capacity without adding CPU or RAM but may reduce RAM hit-rate and increase p99 latency; monitor metrics before and after the change.
There was a problem hiding this comment.
This suggestion contradicts the statement: "you need to add more RAM and vCPUs to handle the increased number of shards."
There was a problem hiding this comment.
It's saying the same thing and adding the "monitor metrics before and after".
There was a problem hiding this comment.
I think I'm still a little confused since your original comment said "without adding CPU or RAM," but the rough draft document said "you need to add more RAM and vCPUs".
4 participants
Still a work in progress
Note
Low Risk
Low risk documentation-only change; primary risk is broken/incorrect internal links or navigation due to the new
flexsection and renamed page titles.Overview
Adds a new dedicated
Flex databasesdocumentation section (content/operate/rs/flex) with pages to explain Flex, how to get started, deployment planning, and scaling guidance.Updates the existing flash/Auto Tiering docs (
databases/flash/*) to consistently use Flex terminology, add banner callouts that route readers to the new Flex section, and refresh “Next steps” links to point to the new Flex pages while keeping Auto Tiering quickstart and storage-engine info in place.Written by Cursor Bugbot for commit efa2146. This will update automatically on new commits. Configure here.