# Doc site updates — April 2026 **URL:** \ **Category:** Community\ **Created:** [April 3, 2026, 4:03am UTC](https://forums.foundationdb.org/t/doc-site-updates-april-2026/5223 "2026-04-03T04:03:13Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![panghy](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/panghy/32/19_2.png) [@panghy](https://forums.foundationdb.org/u/panghy)\ **Post date:** [April 3, 2026, 4:03am UTC](https://forums.foundationdb.org/t/doc-site-updates-april-2026/5223/1 "2026-04-03T04:03:13Z")
Hey all, We’ve pushed a round of updates to the [doc site](https://foundationdb.vercel.app/) based on discussions from the recent open source working group meeting with folks from Apple, Palantir, OpenAI, and Adobe. Here’s what’s new: - **Backup V3** — documented the upcoming parallel log upload/download work that Apple is developing for faster restores. Also added notes on multi-cloud backup status (GCS support coming via Palantir, Azure currently broken). - **Storage engines** — stronger guidance on migrating from SQLite (ssd-2) to Redwood, and updated RocksDB status to reflect real-world production usage at Apple. - **Monitoring** — added a section on native OpenTelemetry metrics (in progress) and the current workaround of scraping trace events. - **Configuration** — documented the `causal_read_risky` knob for GRV path performance. - **Testing & benchmarking** — added Joshua cluster recommendations for faster test feedback, and documented Mako as a stable benchmarking tool. - **Community** — welcome OpenAI and Palantir to the production users list! PR is here if you want to review: [Update docs with April 2026 working group meeting outputs by panghy · Pull Request #16 · foundationdb-oss/doc-site · GitHub](https://github.com/foundationdb-oss/doc-site/pull/16) \> Feedback welcome — especially if anything looks off or if we’re missing something you’d like to see documented. ---
**Author:** ![gxglass](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/gxglass/32/2003_2.png) [@gxglass](https://forums.foundationdb.org/u/gxglass)\ **Post date:** [April 3, 2026, 7:49pm UTC](https://forums.foundationdb.org/t/doc-site-updates-april-2026/5223/2 "2026-04-03T19:49:42Z")
Thanks Clement. Updates look good. BTW, we may have more to say about the Backup V3. TBD on that. ---
**Author:** ![jwr](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/jwr/32/302_2.png) [@jwr](https://forums.foundationdb.org/u/jwr)\ **Post date:** [April 4, 2026, 1:17pm UTC](https://forums.foundationdb.org/t/doc-site-updates-april-2026/5223/3 "2026-04-04T13:17:07Z")
Very happy to see this, the site looks fantastic! I hope this will make FoundationDB more popular (it’s slightly worrying that it doesn’t see more adoption). One quick observation: perhaps it might be possible to link to [Consistency Models](https://jepsen.io/consistency/models) which is I think the best resource on the Internet today listing consistency models with precise explanations. I cringed a bit when I saw “ACID” on the front page, luckily the Guarantees page goes into a lot more detail. FoundationDB has nothing to be ashamed of here: Strict Serializable level is very rare. ---
**Author:** ![panghy](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/panghy/32/19_2.png) [@panghy](https://forums.foundationdb.org/u/panghy)\ **Post date:** [April 6, 2026, 9:50am UTC](https://forums.foundationdb.org/t/doc-site-updates-april-2026/5223/4 "2026-04-06T09:50:28Z")
Thanks Jan, great to have you back! You’re absolutely right — “ACID” was underselling what FDB actually provides. We’ve updated the site to properly highlight **strict serializable** isolation throughout (landing page, ACID guarantees page, and transactions page), and added a link to the Jepsen consistency hierarchy as a reference. Would love your feedback on the changes — here’s the PR and preview: - PR: [Upgrade isolation language and add Jepsen reference by panghy · Pull Request #17 · foundationdb-oss/doc-site · GitHub](https://github.com/foundationdb-oss/doc-site/pull/17) - Preview: [FoundationDB Documentation](https://doc-site-git-address-forum-feedback-panghys-projects-7a5a2496.vercel.app/7.3) ---
**Author:** ![panghy](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/panghy/32/19_2.png) [@panghy](https://forums.foundationdb.org/u/panghy)\ **Post date:** [April 7, 2026, 2:48am UTC](https://forums.foundationdb.org/t/doc-site-updates-april-2026/5223/5 "2026-04-07T02:48:56Z")
Hey all, another round of doc updates based on the working group meeting notes with Apple, Palantir, OpenAI, and Adobe. This one covers some important items we missed in the first pass: - **Feature deprecations** — Apple has deprecated and removed several features: Dynamic Knobs, Encryption at Rest, Metacluster, Blob Granules, and Parallel Restore. If you’re using or planning to use any of these, check the [versions page](https://foundationdb.vercel.app/getting-started/versions/) for details. - **Tracing knobs** — Documented three recommended knobs (`knob_latency_metrics_logging_interval`, `knob_histogram_report_interval`, `knob_kaio_latency_logging_interval`) set to 60s for more granular performance visibility at minimal cost. - **fdb-otel-exporter** — Added a reference to the [fdb-otel-exporter](https://github.com/tclinken/fdb-otel-exporter) project as a starting point if you’re looking to export OTel metrics from FDB. - **Cluster health metric** — Documented the upcoming stable health metric (single 0-100 scalar) that’ll make fleet-wide monitoring much easier. Has an open PR upstream. - **Kubernetes** — Noted that the fdb-kubernetes-operator is the recommended approach for deploying FDB on K8s. PR: [docs: wave 2 updates from April 2026 working group meeting by panghy · Pull Request #19 · foundationdb-oss/doc-site · GitHub](https://github.com/foundationdb-oss/doc-site/pull/19) As always, feedback welcome if anything looks off. ---
**Author:** ![RossWilliams](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/rosswilliams/32/1996_2.png) [@RossWilliams](https://forums.foundationdb.org/u/RossWilliams)\ **Post date:** [April 12, 2026, 11:01pm UTC](https://forums.foundationdb.org/t/doc-site-updates-april-2026/5223/6 "2026-04-12T23:01:54Z")
DR Failover says to run clear range over all keys to break replication. And to run this command on the DR cluster? This might need more explanation as it looks like you are saying to delete all the data on DR after the primary cluster failed. [Backup & Recovery - FoundationDB Documentation](https://doc-site-git-address-forum-feedback-panghys-projects-7a5a2496.vercel.app/7.3/operations/backup/#dr-failover) ---
**Author:** ![panghy](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/panghy/32/19_2.png) [@panghy](https://forums.foundationdb.org/u/panghy)\ **Post date:** [April 13, 2026, 5:55am UTC](https://forums.foundationdb.org/t/doc-site-updates-april-2026/5223/7 "2026-04-13T05:55:28Z")
Whoops, that does look very wrong… > > > \## Summary > > Fixes the DR Failover section in \`docs/operations/backup.md\` which p…reviously instructed operators to run \`clearrange "" "\\xff"\` on the DR cluster to "break replication." This reads like deleting all data on the only surviving copy after a primary failure — dangerous and confusing. > > \## Changes > > Replaced the DR Failover section (lines 450–461) with a correct, safe failover procedure: > > \- \*\*Primary method:\*\* \`fdbdr abort\` to unlock the destination cluster and stop replication > \- \*\*Application redirection:\*\* Step to update cluster files > \- \*\*Reverse DR:\*\* Optional step to set up replication back once the original primary recovers > \- \*\*Fallback:\*\* \`fdbcli unlock\` for when \`fdbdr abort\` fails (no data clearing) > \- \*\*Improved warning:\*\* Explains the data loss window (seconds of unreplicated commits) > > \## What was wrong > > The previous instructions showed: > \`\`\`bash > fdbcli\> writemode on > fdbcli\> clearrange "" "\\xff" # Only if needed to break replication > \`\`\` > > This clears every user key in the key-space — the opposite of what you want when the DR cluster is your only surviving copy. The official \[FoundationDB docs\](https://apple.github.io/foundationdb/backups.html) use \`fdbdr abort\` with no mention of \`clearrange\` for DR failover. > > \## Verification > > \- Only \`docs/operations/backup.md\` is modified > \- Only the \`### DR Failover\` section changed (no other sections affected) > \- Content aligns with official FoundationDB documentation > > \--- > Pull Request opened by \[Augment Code\](https://www.augmentcode.com/) with guidance from the PR author Merged.