memgraph
diff --git a/‎pages/advanced-algorithms/available-algorithms/betweenness_centrality.mdx‎
Lines changed: 1 addition & 2 deletions b/‎pages/advanced-algorithms/available-algorithms/betweenness_centrality.mdx‎
Lines changed: 1 addition & 2 deletions
diff --git a/‎pages/advanced-algorithms/available-algorithms/community_detection.mdx‎
Lines changed: 1 addition & 1 deletion b/‎pages/advanced-algorithms/available-algorithms/community_detection.mdx‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎pages/advanced-algorithms/available-algorithms/migrate.mdx‎
Lines changed: 219 additions & 0 deletions b/‎pages/advanced-algorithms/available-algorithms/migrate.mdx‎
Lines changed: 219 additions & 0 deletions
diff --git a/‎pages/advanced-algorithms/install-mage.mdx‎
Lines changed: 16 additions & 1 deletion b/‎pages/advanced-algorithms/install-mage.mdx‎
Lines changed: 16 additions & 1 deletion
diff --git a/‎pages/client-libraries/python.mdx‎
Lines changed: 18 additions & 2 deletions b/‎pages/client-libraries/python.mdx‎
Lines changed: 18 additions & 2 deletions
@@ -59,8 +59,7 @@ If subgraph is not specified, the algorithm is computed on the entire graph by d
 - `normalized: boolean (default=True)` ➡ If `True` the betweenness values are normalized by
   `2/((n-1)(n-2))` for graphs, and `1/((n-1)(n-2))` for directed graphs where
   `n` is the number of nodes.
-- `threads: integer (default=number of concurrent threads supported by the
-  implementation)` ➡ The number of threads used to calculate betweenness
+- `threads: integer (default=half of the system’s available hardware threads)` ➡ The number of threads used to calculate betweenness
   centrality.
 
 
 
@@ -78,7 +78,7 @@ the procedure.
   gain in modularity goes below this threshold, a final iteration is performed using the
   `community_alg_threshold` value.
   Valid values are between 0 and 1 (exclusive). This parameter's value should be higher than `community_alg_threshold`.
-- `num_of_threads: integer (default=Half of the system's maximum thread count)` ➡ Specifies the number of threads used for parallel execution in the algorithm's parallelized parts. 
+- `num_of_threads: integer (default=half of the system’s available hardware threads)` ➡ Specifies the number of threads used for parallel execution in the algorithm's parallelized parts. 
 **Note**: OpenMP (omp) is used for parallelization, so the actual thread usage may depend on system settings and OpenMP configurations.
 
 {<h4 className="custom-header"> Output: </h4>}
 
@@ -6,6 +6,7 @@ description: Discover the migration capabilities of Memgraph for efficient trans
 import { Cards } from 'nextra/components'
 import GitHub from '/components/icons/GitHub'
 import { Steps } from 'nextra/components'
+import { Callout } from 'nextra/components';
 
 # migrate
 
@@ -35,6 +36,181 @@ filter, and convert relational data into a graph format.
 
 ## Procedures
 
+### `arrow_flight()`
+
+With the `arrow_flight()` procedure, users can access data sources which support the [Arrow Flight RPC protocol](https://arrow.apache.org/docs/format/Flight.html) for transfer
+of large data records to achieve high performance. Underlying implementation is using the `pyarrow` Python library to stream rows to
+Memgraph. [Dremio](https://www.dremio.com/) is a confirmed data source that works with the `arrow_flight()` procedure. Other sources may also be compatible, but Dremio is based on previous experience.
+
+{<h4 className="custom-header"> Input: </h4>}
+
+- `query: str` ➡ Query used to query the data source.  
+- `config: mgp.Map` ➡ Connection parameters (as in `pyarrow.flight.connect`). Useful parameters for connecting are `host`, `port`, `username` and `password`.
+- `config_path` ➡ Path to a JSON file containing configuration parameters.  
+
+{<h4 className="custom-header"> Output: </h4>}
+
+- `row: mgp.Map` ➡ The result table as a stream of rows.
+
+#### Retrieve and inspect data
+```cypher
+CALL migrate.arrow_flight('SELECT * FROM users', {username: 'memgraph',
+        password: 'password',
+        host: 'localhost',
+        port: '12345'} )
+YIELD row
+RETURN row
+LIMIT 5000;
+```
+
+#### Filter specific data
+```cypher
+CALL migrate.arrow_flight('SELECT * FROM users', {username: 'memgraph',
+        password: 'password',
+        host: 'localhost',
+        port: '12345'} )
+YIELD row
+WHERE row.age >= 30
+RETURN row;
+```
+
+#### Create nodes from migrated data
+```cypher
+CALL migrate.arrow_flight('SELECT id, name, age FROM users', {username: 'memgraph',
+        password: 'password',
+        host: 'localhost',
+        port: '12345'} )
+YIELD row
+CREATE (u:User {id: row.id, name: row.name, age: row.age});
+```
+
+#### Create relationships between users
+```cypher
+CALL migrate.arrow_flight('SELECT user1_id, user2_id FROM friendships', {username: 'memgraph',
+        password: 'password',
+        host: 'localhost',
+        port: '12345'} )
+YIELD row
+MATCH (u1:User {id: row.user1_id}), (u2:User {id: row.user2_id})
+CREATE (u1)-[:FRIENDS_WITH]->(u2);
+```
+
+### `duckdb()`
+With the `migrate.duckdb()` procedure, users can connect to the ** DuckDB** database and query various data sources.
+List of data sources that are supported by DuckDB can be found on their [official documentation page](https://duckdb.org/docs/stable/data/data_sources.html).
+The underlying implementation streams results from DuckDB to Memgraph using the `duckdb` Python Library. DuckDB is started with the in-memory mode, without any
+persistence and is used just to proxy to the underlying data sources.
+
+{<h4 className="custom-header"> Input: </h4>}
+
+- `query: str` ➡ Table name or an SQL query.  
+- `setup_queries: mgp.Nullable[List[str]]` ➡ List of queries that will be executed prior to the query provided as the initial argument. 
+Used for setting up the connection to additional data sources.
+
+{<h4 className="custom-header"> Output: </h4>}
+
+- `row: mgp.Map` ➡ The result table as a stream of rows.
+
+{<h4 className="custom-header"> Usage: </h4>}
+
+#### Retrieve and inspect data
+```cypher
+CALL migrate.duckdb("SELECT * FROM 'test.parquet';")
+YIELD row
+RETURN row
+LIMIT 5000;
+```
+
+#### Filter specific data
+```cypher
+CALL migrate.duckdb("SELECT * FROM 'test.parquet';")
+YIELD row
+WHERE row.age >= 30
+RETURN row;
+```
+
+#### Create nodes from migrated data
+```cypher
+CALL migrate.duckdb("SELECT * FROM 'test.parquet';")
+YIELD row
+CREATE (u:User {id: row.id, name: row.name, age: row.age});
+```
+
+#### Create relationships between users
+```cypher
+CALL migrate.duckdb("SELECT * FROM 'test.parquet';")
+YIELD row
+MATCH (u1:User {id: row.user1_id}), (u2:User {id: row.user2_id})
+CREATE (u1)-[:FRIENDS_WITH]->(u2);
+```
+
+#### Setup connection to query additional data sources
+```cypher
+CALL migrate.duckdb("SELECT * FROM 's3://your_bucket/your_file.parquet';", ["CREATE SECRET secret1 (TYPE s3, KEY_ID 'key', SECRET 'secret', REGION 'region');"])
+YIELD row
+MATCH (u1:User {id: row.user1_id}), (u2:User {id: row.user2_id})
+CREATE (u1)-[:FRIENDS_WITH]->(u2);
+```
+
+---
+
+### `memgraph()`
+
+With the `migrate.memgraph()` procedure, you can access another Memgraph instance and migrate your data to a new Memgraph instance.  
+The resulting nodes and edges are converted into a stream of rows which can include labels, properties, and primitives.
+
+<Callout type="info">
+Streaming of raw node and relationship objects is not supported and users are advised to migrate all the necessary identifiers in order to recreate the same graph in Memgraph.
+</Callout>
+
+{<h4 className="custom-header"> Input: </h4>}
+
+- `label_or_rel_or_query: str` ➡ Label name (written in format `(:Label)`), relationship name (written in format `[:rel_type]`) or a plain cypher query. 
+- `config: mgp.Map` ➡ Connection parameters (as in `gqlalchemy.Memgraph`). Notable parameters are `host[String]`, and `port[Integer]` 
+- `config_path` ➡ Path to a JSON file containing configuration parameters.  
+- `params: mgp.Nullable[mgp.Any] (default=None)` ➡ Query parameters (if applicable).  
+
+{<h4 className="custom-header"> Output: </h4>}
+
+- `row: mgp.Map` ➡ The result table as a stream of rows.
+        - when retrieving nodes using the `(:Label)` syntax, row will have the following keys: `labels`, and `properties`
+        - when retrieving relationships using the `[:REL_TYPE]` syntax, row will have the following keys: `from_labels`, `to_labels`, `from_properties`, `to_properties`, and `edge_properties`
+        - when retrieving results using a plain Cypher query, row will have keys identical to the returned column names from the Cypher query
+
+{<h4 className="custom-header"> Usage: </h4>}
+
+#### Retrieve nodes of certain label and create them in a new Memgraph instance
+```cypher
+CALL migrate.memgraph('(:Person)', {host: 'localhost', port: 7687})
+YIELD row
+WITH row.labels AS labels, row.properties as props
+CREATE (n:labels) SET n += row.props
+```
+
+#### Retrieve relationships of certain type and create them in a new Memgraph instance
+```cypher
+CALL migrate.memgraph('[:KNOWS]', {host: 'localhost', port: 7687})
+YIELD row
+WITH row.from_labels AS from_labels,
+        row.to_labels AS to_labels,
+        row.from_properties AS from_properties,
+        row.to_properties AS to_properties,
+        row.edge_properties AS edge_properties
+MATCH (p1:Person {id: row.from_properties.id})
+MATCH (p2:Person {id: row.to_properties.id})
+CREATE (p1)-[r:KNOWS]->(p2)
+SET r += edge_properties;
+```
+
+#### Retrieve information from Memgraph using an arbitrary Cypher query
+```cypher
+CALL migrate.memgraph('MATCH (n) RETURN count(n) as cnt', {host: 'localhost', port: 7687})
+YIELD row
+RETURN row.cnt as cnt;
+```
+
+---
+
 ### `mysql()`
 
 With the `migrate.mysql()` procedure, you can access MySQL and migrate your data to Memgraph.  
@@ -334,3 +510,46 @@ CALL migrate.s3('s3://my-bucket/employees.csv', {aws_access_key_id: 'your-key',
 YIELD row
 CREATE (e:Employee {id: row.id, name: row.name, position: row.position});
 ```
+
+---
+
+### `servicenow()`
+
+With the `migrate.servicenow()` procedure, you can access [ServiceNow REST API](https://developer.servicenow.com/dev.do#!/reference/api/xanadu/rest/) and transfer your data to Memgraph.
+The underlying implementation is using the [`requests` Python library] to migrate results to Memgraph. The REST API from 
+ServiceNow must provide results in the format `{results: []}` in order for Memgraph to stream it into result rows.
+
+{<h4 className="custom-header"> Input: </h4>}
+
+- `endpoint: str` ➡ ServiceNow endpoint. Users can optionally include their own query parameters to filter results.  
+- `config: mgp.Map` ➡ Connection parameters. Notable connection parameters are `username` and `password`, per `requests.get()` method.
+- `config_path: str` ➡ Path to a JSON file containing configuration parameters.  
+
+{<h4 className="custom-header"> Output: </h4>}
+
+- `row: mgp.Map` ➡ Each row from the CSV file as a structured dictionary.
+
+{<h4 className="custom-header"> Usage: </h4>}
+
+#### Retrieve and inspect CSV data from ServiceNow
+```cypher
+CALL migrate.servicenow('http://my_endpoint/api/data', {})
+YIELD row
+RETURN row
+LIMIT 100;
+```
+
+#### Filter specific rows from the CSV
+```cypher
+CALL migrate.servicenow('http://my_endpoint/api/data', {})
+YIELD row
+WHERE row.age >= 30
+RETURN row;
+```
+
+#### Create nodes dynamically from CSV data
+```cypher
+CALL migrate.servicenow('http://my_endpoint/api/data', {})
+YIELD row
+CREATE (e:Employee {id: row.id, name: row.name, position: row.position});
+```
@@ -22,13 +22,28 @@ data.
 
 You can download a specific version of MAGE
 
-For example, if you want to download version `3.1.1`, you should run the following
+For example, if you want to download version `3.2`, you should run the following
 command:
 
+```shell
+docker run -p 7687:7687 --name memgraph memgraph/memgraph-mage:3.2
+```
+
+The following tags are available on Docker Hub:
+- `x.y` - production MAGE image
+- `x.y-relwithdebinfo` - contains debugging symbols and `gdb`
+- `x.y-malloc` - Memgraph compiled with `malloc`instead of `jemalloc` (x86_64 only)
+
+For versions prior to `3.2`, MAGE image tags included both MAGE and Memgraph versions, e.g.
+
 ```shell
 docker run -p 7687:7687 --name memgraph memgraph/memgraph-mage:3.1.1-memgraph-3.1.1
 ```
 
+A `no-ml` image (e.g. `3.1.1-memgraph-3.1.1-no-ml`) was also provided, but this has now been 
+discontinued as of `3.2` onwards.
+
+
 </Callout>
 
 ## Linux
 
@@ -435,7 +435,7 @@ for record in records:
     print(path.end_node)
 ```
 
-Path will contain [Nodes](#process-the-node-result) and [Relationships[#process-the-relationship-result], that can be accessed in the same way as in the previous examples.
+Path will contain [Nodes](#process-the-node-result) and [Relationships](#process-the-relationship-result), that can be accessed in the same way as in the previous examples.
 
 ### Transaction management
 
@@ -546,6 +546,11 @@ With sessions, you can run:
 
 To create a managed transaction, use `Session.execute_read()` procedure for read queries and `Session.execute_write()` procedure for write queries.
 
+<Callout type="info">
+As of Memgraph version 3.2, queries are categorized as **read** or **write** and the corresponding storage access is taken. This allows for better query parallelization and higher throughput.
+An exception will be thrown if the user tries to execute a write query inside a read transaction. For more details, see [transaction accessor misalignment](/fundamentals/transactions#transaction-accessor-misalignment).
+</Callout>
+
 ```python
 def match_user(tx, name):
     result = tx.run(
@@ -581,6 +586,12 @@ To maintain multiple concurrent transactions, use [multiple concurrent sessions]
 With explicit transactions, you can get **complete control over transactions**. To begin a transaction, run `Session.begin_transaction()` procedure and to run a transaction, use `Transaction.run()` procedure.
 Explicit transactions offer the possibility of explicitly controlling the end of a transaction with `Transaction.commit()`, `Transaction.rollback()` or `Transaction.close()` methods.
 
+<Callout type="info">
+As of Memgraph version 3.2, queries are categorized as **read** or **write** and the corresponding storage access is taken. This allows for better query parallelization and higher throughput.
+Explicit transactions can cover a number of individual queries, but storage access is given at the start. For best performance, the user needs to declare whether the transaction should use read or write access.
+This can be done by setting the session's `default_access_mode` to `"r"` or `"w"`. This will, in turn, set the access mode of a transaction created via the `begin_transaction` function. Note that `execute_read` and `execute_write` will override the session's default access.
+</Callout>
+
 Use explicit transaction if you need to **distribute Cypher execution across multiple functions for the same transaction** or if you need to **run multiple queries within a single transactions without automatic retries**.
 
 The following example shows how to explicitly control the transaction of changing account balances based on a token transfer:
@@ -610,7 +621,7 @@ def create_users(client, sender, receiver):
 
 
 def transfer_tokens(client, sender_id, receiver_id, num_of_tokens):
-    with client.session(database="memgraph") as session:
+    with client.session(database="memgraph", default_access_mode="w") as session:
         tx = session.begin_transaction()
 
         try:
@@ -676,6 +687,11 @@ In the above example, if John's account balance is changed to a number less than
 Implicit or auto-commit transactions are the simplest way to run a Cypher query since they won't be automatically retried as with `execute_query()` procedure or managed transactions.
 With implicit transactions, you don't have the same control of transaction as with explicit transactions, so they are mostly used for quick prototyping.
 
+<Callout type="info">
+As of Memgraph version 3.2, queries are categorized as **read** or **write** and the corresponding storage access is taken. This allows for better query parallelization and higher throughput.
+Access mode is automatically determined when executing single queries through implicit transactions.
+</Callout>
+
 To run an implicit transaction, use the `Session.run()` method:
 
 ```python