Add server side parameters docs

pages/advanced-algorithms/available-algorithms/migrate.mdx

@@ -32,6 +32,19 @@ filter, and convert relational data into a graph format.
 | **Implementation**  | Python     |
 | **Parallelism**     | sequential |
 
+<Callout type="info">
+When running multiple migrations against the same source, avoid repeating the `config` map in every call.
+Use [server-side parameters](/database-management/server-side-parameters) to store the connection config once
+and reference it as `$config` across all your queries:
+
+```cypher
+SET GLOBAL PARAMETER pg_config = {user: 'memgraph', password: 'password', host: 'localhost', database: 'demo_db'};
+
+CALL migrate.postgresql('users', $pg_config) YIELD row CREATE (u:User {id: row.id});
+CALL migrate.postgresql('orders', $pg_config) YIELD row CREATE (o:Order {id: row.id});
+```
+</Callout>
+
 ---
 
 ## Procedures

pages/ai-ecosystem/graph-rag/atomic-pipelines.mdx

@@ -57,9 +57,9 @@ Offer the ability to compute embeddings during the preprocessing or retrieval
 stages.
 11. [`llm.complete`](/advanced-algorithms/available-algorithms/llm) function:
 Allows you to call any LLM under any given Cypher query.
-12. Server-side parameters: Could be used for many different things, but in this
-context, the parameters help you with managing configuration under any given
-query or pipeline.
+12. [Server-side parameters](/database-management/server-side-parameters): Could
+be used for many different things, but in this context, the parameters help you
+managing configuration under any given query or pipeline.
 
 ## Question and Pipeline Types
 
@@ -107,4 +107,4 @@ exists, it synthesizes what is missing or not well-covered. Example use cases:
   - **Publishing**: *"I want to write a book, which important topics in this
   domain are not yet well covered in the existing literature?"*
 
-![atomic_graphrag_pipelines](/pages/ai-ecosystem/graph-rag/atomic-pipelines/atomic-graphrag-pipelines.png)
+![atomic_graphrag_pipelines](/pages/ai-ecosystem/graph-rag/atomic-pipelines/atomic-graphrag-pipelines.png)

pages/database-management/_meta.ts

@@ -9,6 +9,7 @@ export default {
   "monitoring": "Monitoring",
   "multi-tenancy": "Multi-tenancy",
   "query-metadata": "Query metadata",
+  "server-side-parameters": "Server-side parameters",
   "server-stats": "Server stats",
   "ssl-encryption": "SSL encryption",
   "system-configuration": "System configuration"

pages/database-management/authentication-and-authorization/query-privileges.mdx

@@ -124,6 +124,9 @@ Memgraph's privilege system controls access to various database operations throu
 | `DATA DIRECTORY LOCK STATUS` | `DURABILITY` | `DATA DIRECTORY LOCK STATUS` |
 | `FREE MEMORY` | `FREE_MEMORY` | `FREE MEMORY` |
 | `SHOW CONFIG` | `CONFIG` | `SHOW CONFIG` |
+| `SET [GLOBAL] PARAMETER` | `SERVER_SIDE_PARAMETERS` | `SET GLOBAL PARAMETER x = 'value'` |
+| `UNSET [GLOBAL] PARAMETER` | `SERVER_SIDE_PARAMETERS` | `UNSET PARAMETER x` |
+| `SHOW PARAMETERS` | `SERVER_SIDE_PARAMETERS` | `SHOW PARAMETERS` |
 | `CREATE TRIGGER` | `TRIGGER` | `CREATE TRIGGER ...` |
 | `DROP TRIGGER` | `TRIGGER` | `DROP TRIGGER ...` |
 | `SHOW TRIGGERS` | `TRIGGER` | `SHOW TRIGGERS` |

pages/database-management/configuration.mdx

@@ -342,6 +342,10 @@ If you want to change a value for a specific setting, following query should be
 SET DATABASE SETTING "setting.name" TO "some-value";
 ```
 
+For reusable query values accessed as `$name`, see
+[Server-side parameters](/database-management/server-side-parameters). Unlike
+database settings, server-side parameters are resolved during query execution.
+
 ### Multitenancy and configuration 
 
 If you are using a multi-tenant architecture, all isolated databases share

pages/database-management/server-side-parameters.mdx

@@ -0,0 +1,142 @@
+---
+title: Server-side parameters
+description: Configure and reuse server-side parameters in Memgraph with database or global scope.
+---
+
+# Server-side parameters
+
+Server-side parameters are named values stored by Memgraph and reusable in
+queries through `$parameterName`, just like user-provided parameters.
+
+They are useful when you want reusable defaults, while still allowing clients to override values when needed.
+
+## Parameter scopes
+
+Server-side parameters support two scopes:
+
+- **Database scope**: set with `SET PARAMETER ...`; visible only in the current
+  database.
+- **Global scope**: set with `SET GLOBAL PARAMETER ...`; visible across
+  databases.
+
+When you run `SHOW PARAMETERS`, Memgraph returns:
+- all global parameters
+- parameters from the current database
+
+## Resolution order
+
+When a query uses `$name`, values are resolved in this order:
+
+1. user-provided query parameter (from the client)
+2. database-scoped server-side parameter
+3. global server-side parameter
+
+This means:
+- user-provided parameters are preferred over server-side parameters
+- database-scoped server-side parameters are preferred over global ones
+
+## Set a parameter
+
+Use `SET PARAMETER` for database scope, or `SET GLOBAL PARAMETER` for global
+scope.
+
+```opencypher
+SET PARAMETER x = 'db_value';
+SET GLOBAL PARAMETER x = 'global_value';
+```
+
+You can set the value from:
+- a literal
+- a user-provided parameter (for example `$config`)
+- a map value
+
+```opencypher
+SET GLOBAL PARAMETER app_config = $config;
+SET GLOBAL PARAMETER limits = {timeout: 120, mode: 'safe'};
+SET GLOBAL PARAMETER ids = [10, 20, 30];
+```
+
+## Unset a parameter
+
+Remove a parameter by name in either database or global scope.
+
+```opencypher
+UNSET PARAMETER x;
+UNSET GLOBAL PARAMETER x;
+```
+
+## Show parameters
+
+List current server-side parameters:
+
+```opencypher
+SHOW PARAMETERS;
+```
+
+Output columns:
+- `name`: parameter name
+- `value`: stored value (JSON-encoded string form)
+- `scope`: `database` or `global`
+
+## Privileges
+
+Server-side parameter queries require the `SERVER_SIDE_PARAMETERS` privilege.
+See the [Query privileges reference](/database-management/authentication-and-authorization/query-privileges).
+
+## Use cases
+
+### Use in queries with `$`
+
+Once set, server-side parameters are available as `$name` in queries:
+
+```opencypher
+SET GLOBAL PARAMETER tenant = 'acme';
+CREATE (:Account {tenant: $tenant});
+```
+
+If the client sends a user parameter with the same name, that user value is
+used first:
+
+```opencypher
+SET GLOBAL PARAMETER x = 'server_value';
+CREATE (:Node {property: $x});
+```
+
+If the query is run with user parameter `x = 'client_value'`, the node property
+will be `'client_value'`.
+
+### Reusing connection config in data migrations
+
+The [`migrate` module](/advanced-algorithms/available-algorithms/migrate) procedures accept a `config` map with
+connection parameters like `host`, `port`, `user`, and `password`. When running multiple migration queries
+against the same source, repeating this map in every call is verbose and error-prone.
+
+Store the config once as a server-side parameter and reference it with `$config` across all your migration queries:
+
+```opencypher
+SET GLOBAL PARAMETER mysql_config = {
+  user: 'memgraph',
+  password: 'password',
+  host: 'localhost',
+  database: 'demo_db'
+};
+```
+
+Then use `$mysql_config` in every migration call instead of repeating the full map:
+
+```opencypher
+CALL migrate.mysql('users', $mysql_config)
+YIELD row
+CREATE (u:User {id: row.id, name: row.name});
+
+CALL migrate.mysql('orders', $mysql_config)
+YIELD row
+CREATE (o:Order {id: row.id, total: row.total});
+
+CALL migrate.mysql('SELECT user_id, order_id FROM user_orders', $mysql_config)
+YIELD row
+MATCH (u:User {id: row.user_id}), (o:Order {id: row.order_id})
+CREATE (u)-[:PLACED]->(o);
+```
+
+This works for all `migrate` procedures — `migrate.postgresql()`, `migrate.mysql()`, `migrate.neo4j()`, `migrate.sql_server()`, and others.