diff --git a/docs/web/feature-engineering/materialized-views.mdx b/docs/web/feature-engineering/materialized-views.mdx
index cc807f0db..3e8019c5f 100644
--- a/docs/web/feature-engineering/materialized-views.mdx
+++ b/docs/web/feature-engineering/materialized-views.mdx
@@ -92,20 +92,21 @@ the SDK refuses them on a `db://` connection.
 
 Materialized views are off by default on a deployment and have to be enabled
 there. How a deployment handles a view then depends on its LanceDB Enterprise
-version. Newer versions run every create and refresh as a job that rebuilds the
-whole view, as a local refresh does; the source does not need stable row ids,
-and [`REFRESH MATERIALIZED VIEW`](/sql/dml/refresh#refresh-materialized-view)
-accepts no options. Earlier versions could instead reconcile only what changed
-in the source, and could require the source to have stable row ids. A view
-created by an earlier version has to be recreated once the deployment moves to
-a newer one.
+version. Recent versions create and refresh every view as a SQL job: the source
+does not need stable row ids,
+[`REFRESH MATERIALIZED VIEW`](/sql/dml/refresh#refresh-materialized-view) takes
+no options, and whether a refresh rebuilds the whole view, as a local refresh
+does, or adds only what changed in the source depends on the version and on the
+view's query. Earlier versions could require the source to have stable row ids
+and took refresh options; a view they created has to be recreated once the
+deployment moves to a recent version.
 
 Stable row ids are set up on the deployment, not by the SDK: a `db://`
 connection does not send `new_table_enable_stable_row_ids`, and no SDK call adds
 them to an existing table. An earlier version that requires them may give new
 tables stable row ids, may refuse a view created through SQL -- as the SDK
 creates one -- over a source without them, or may convert an existing source
-when a view is created through its REST API, which newer versions no longer
+when a view is created through its REST API, which recent versions no longer
 have. Check with the deployment's administrator which version it runs before
 relying on a source.
 
diff --git a/docs/web/sql/dml/copy.mdx b/docs/web/sql/dml/copy.mdx
index 3fe002fe8..658b20b59 100644
--- a/docs/web/sql/dml/copy.mdx
+++ b/docs/web/sql/dml/copy.mdx
@@ -7,7 +7,7 @@ keywords: ["copy", "export", "parquet", "sql"]
 ---
 
 <Warning>
-Newer deployment versions refuse `COPY` over the SQL endpoint with "COPY is not
+Recent deployment versions refuse `COPY` over the SQL endpoint with "COPY is not
 supported". On those, export a result by reading it through a Flight SQL client
 or an SDK and writing the files from your application.
 </Warning>
diff --git a/docs/web/sql/dml/refresh.mdx b/docs/web/sql/dml/refresh.mdx
index 4882c86ed..90ba61c8f 100644
--- a/docs/web/sql/dml/refresh.mdx
+++ b/docs/web/sql/dml/refresh.mdx
@@ -71,13 +71,14 @@ REFRESH MATERIALIZED VIEW chunks WITH (full = true)
 
 On earlier deployment versions, `full = true` asks for every row to be
 recomputed, and without it a refresh can reconcile only what changed in the
-source. Newer versions rebuild the whole view on every refresh, as every local
-SDK refresh does, and refuse `WITH` options.
+source. Recent versions refuse `WITH` options; whether their refresh rebuilds
+the whole view, as every local SDK refresh does, or adds only what changed
+depends on the version and on the view's query.
 
 <Warning>
 `CASCADE` asks for the views this one is built on to be refreshed first, in
 dependency order. Whether a deployment carries it out depends on its version,
-and newer versions refuse it; where it is refused, refresh each view yourself,
+and recent versions refuse it; where it is refused, refresh each view yourself,
 its sources first.
 </Warning>
 
diff --git a/docs/web/sql/index.mdx b/docs/web/sql/index.mdx
index 4b92ef38c..6b147d0a7 100644
--- a/docs/web/sql/index.mdx
+++ b/docs/web/sql/index.mdx
@@ -111,7 +111,7 @@ operations that have no SQL form, such as a merge insert -- see
 | [Insert](/sql/dml/insert) | `INSERT INTO`, including `INSERT ... SELECT` |
 | [Update](/sql/dml/update) | `UPDATE ... SET` |
 | [Delete](/sql/dml/delete) | `DELETE FROM` |
-| [Copy](/sql/dml/copy) | `COPY` -- refused by newer deployment versions |
+| [Copy](/sql/dml/copy) | `COPY` -- refused by recent deployment versions |
 | [Refresh](/sql/dml/refresh) | filling computed columns and materialized views |
 
 ### DQL {#dql}
@@ -144,7 +144,7 @@ operations that have no SQL form, such as a merge insert -- see
 | Vector search | [depends on the deployment](/basics/sql#no-vector-sql); the query builder always has it |
 | Merge insert | no SQL form -- needs a source relation and a per-match policy |
 | `information_schema` | not enabled, so `SHOW TABLES` and `SHOW COLUMNS` fail |
-| `COPY` | refused by newer deployment versions -- see [Copy](/sql/dml/copy) |
+| `COPY` | refused by recent deployment versions -- see [Copy](/sql/dml/copy) |
 | `PREPARE` / `EXECUTE` | preparation is a [protocol feature](/sql/prepared-statements), not a statement |
 | Run on a local database | no engine to plan the statement |