From d2cadacf0f5a77985e79cc1a50da5db4fb894e26 Mon Sep 17 00:00:00 2001 From: "Jeremiah C. Foster" Date: Fri, 22 Aug 2025 17:14:36 +0200 Subject: [PATCH 1/4] Update store.md Added a note about needing a Postgres user and db. --- docs/install/store.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/install/store.md b/docs/install/store.md index bbdcdb4..914cbca 100644 --- a/docs/install/store.md +++ b/docs/install/store.md @@ -11,7 +11,7 @@ Stalwart employs a modular storage architecture that separates different types o - To support efficient search operations, Stalwart also utilizes a [Full-text Search Store](/docs/storage/fts), which maintains indexes to speed up text-based queries across message content. - Finally, the [In-memory Store](/docs/storage/in-memory) handles ephemeral key-value data used by security, clustering, and anti-spam components, including rate limiting, distributed locks, Bayesian models, sender reputation scores, and message interaction tracking. -In simple or single-node setups, it is entirely feasible to consolidate these roles into a single storage backend. For example, databases such as **RocksDB** or **PostgreSQL** can be configured to serve as the data store, blob store, full-text search store, and even in-memory store. It is common to see lightweight deployments where RocksDB is used exclusively for all four functions, simplifying management and reducing infrastructure complexity. +In simple or single-node setups, it is entirely feasible to consolidate these roles into a single storage backend. For example, databases such as **RocksDB** or **PostgreSQL** can be configured to serve as the data store, blob store, full-text search store, and even in-memory store. It is common to see lightweight deployments where RocksDB is used exclusively for all four functions, simplifying management and reducing infrastructure complexity. If you decide to use PostrgreSQL instead of the default RocksDB, you'll need to add a user and a database into PostgreSQL before Stalwart can add data to it. However, for larger deployments—particularly those running in [distributed environments](/docs/cluster/overview)—it is advisable to assign each storage role to a backend that is specifically designed for that purpose. A more scalable and robust configuration might involve **FoundationDB** as the data store, an **S3-compatible service** for blob storage, **Redis** for handling volatile in-memory data, and a dedicated search engine such as **Elasticsearch** or **Meilisearch** for full-text indexing. From 0440f6897a71999136b7bafbf6823895358f595a Mon Sep 17 00:00:00 2001 From: "Jeremiah C. Foster" Date: Fri, 22 Aug 2025 17:20:36 +0200 Subject: [PATCH 2/4] Update store.md Added link to SQL schema --- docs/install/store.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/install/store.md b/docs/install/store.md index 914cbca..7d712a9 100644 --- a/docs/install/store.md +++ b/docs/install/store.md @@ -11,7 +11,7 @@ Stalwart employs a modular storage architecture that separates different types o - To support efficient search operations, Stalwart also utilizes a [Full-text Search Store](/docs/storage/fts), which maintains indexes to speed up text-based queries across message content. - Finally, the [In-memory Store](/docs/storage/in-memory) handles ephemeral key-value data used by security, clustering, and anti-spam components, including rate limiting, distributed locks, Bayesian models, sender reputation scores, and message interaction tracking. -In simple or single-node setups, it is entirely feasible to consolidate these roles into a single storage backend. For example, databases such as **RocksDB** or **PostgreSQL** can be configured to serve as the data store, blob store, full-text search store, and even in-memory store. It is common to see lightweight deployments where RocksDB is used exclusively for all four functions, simplifying management and reducing infrastructure complexity. If you decide to use PostrgreSQL instead of the default RocksDB, you'll need to add a user and a database into PostgreSQL before Stalwart can add data to it. +In simple or single-node setups, it is entirely feasible to consolidate these roles into a single storage backend. For example, databases such as **RocksDB** or **PostgreSQL** can be configured to serve as the data store, blob store, full-text search store, and even in-memory store. It is common to see lightweight deployments where RocksDB is used exclusively for all four functions, simplifying management and reducing infrastructure complexity. If you decide to use PostrgreSQL instead of the default RocksDB, you'll need to add a user and a [database into PostgreSQL](/docs/auth/backend/sql/#postgresql) before Stalwart can add data to it. However, for larger deployments—particularly those running in [distributed environments](/docs/cluster/overview)—it is advisable to assign each storage role to a backend that is specifically designed for that purpose. A more scalable and robust configuration might involve **FoundationDB** as the data store, an **S3-compatible service** for blob storage, **Redis** for handling volatile in-memory data, and a dedicated search engine such as **Elasticsearch** or **Meilisearch** for full-text indexing. From 14b3880a4f0ced38284f23620c85ca0b83aa71f4 Mon Sep 17 00:00:00 2001 From: "Jeremiah C. Foster" Date: Mon, 15 Sep 2025 16:15:23 +0200 Subject: [PATCH 3/4] Update store.md Minor editing and formatting changes for brevity and clarity. --- docs/install/store.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/install/store.md b/docs/install/store.md index 7d712a9..e3a3494 100644 --- a/docs/install/store.md +++ b/docs/install/store.md @@ -11,9 +11,11 @@ Stalwart employs a modular storage architecture that separates different types o - To support efficient search operations, Stalwart also utilizes a [Full-text Search Store](/docs/storage/fts), which maintains indexes to speed up text-based queries across message content. - Finally, the [In-memory Store](/docs/storage/in-memory) handles ephemeral key-value data used by security, clustering, and anti-spam components, including rate limiting, distributed locks, Bayesian models, sender reputation scores, and message interaction tracking. -In simple or single-node setups, it is entirely feasible to consolidate these roles into a single storage backend. For example, databases such as **RocksDB** or **PostgreSQL** can be configured to serve as the data store, blob store, full-text search store, and even in-memory store. It is common to see lightweight deployments where RocksDB is used exclusively for all four functions, simplifying management and reducing infrastructure complexity. If you decide to use PostrgreSQL instead of the default RocksDB, you'll need to add a user and a [database into PostgreSQL](/docs/auth/backend/sql/#postgresql) before Stalwart can add data to it. +In simple or single-node setups, it is entirely feasible to consolidate these roles into a single storage backend. For example, databases such as **RocksDB** or **PostgreSQL** can be configured to serve as the data store, blob store, full-text search store, and even in-memory store. It is common to see lightweight deployments where RocksDB is used exclusively for all four functions, simplifying management and reducing infrastructure complexity. -However, for larger deployments—particularly those running in [distributed environments](/docs/cluster/overview)—it is advisable to assign each storage role to a backend that is specifically designed for that purpose. A more scalable and robust configuration might involve **FoundationDB** as the data store, an **S3-compatible service** for blob storage, **Redis** for handling volatile in-memory data, and a dedicated search engine such as **Elasticsearch** or **Meilisearch** for full-text indexing. +Should you decide to use PostrgreSQL instead of the default RocksDB, you'll need to add a user and a [database schema](/docs/auth/backend/sql/#postgresql). + +However, for larger deployments—particularly those running in [distributed environments](/docs/cluster/overview)—it is advisable to assign each storage role to a backend that is fit for purpose. A more scalable and robust configuration might involve **FoundationDB** as the data store, an **S3-compatible service** for blob storage, **Redis** for handling volatile in-memory data, and a dedicated search engine such as **Elasticsearch** or **Meilisearch** for full-text indexing. Selecting the right combination of databases will depend on the performance requirements, fault tolerance expectations, and operational constraints of the deployment. Stalwart’s flexible architecture ensures that it can scale from compact single-server setups to complex multi-node clusters with specialized infrastructure for each storage layer. From d91cde378eadabc1c2c0fefa9c89e8b2f61ff0f7 Mon Sep 17 00:00:00 2001 From: "Jeremiah C. Foster" Date: Tue, 16 Sep 2025 12:04:06 +0200 Subject: [PATCH 4/4] Update store.md - formatting, white space, no --- docs/install/store.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/install/store.md b/docs/install/store.md index e3a3494..8305c4e 100644 --- a/docs/install/store.md +++ b/docs/install/store.md @@ -13,7 +13,7 @@ Stalwart employs a modular storage architecture that separates different types o In simple or single-node setups, it is entirely feasible to consolidate these roles into a single storage backend. For example, databases such as **RocksDB** or **PostgreSQL** can be configured to serve as the data store, blob store, full-text search store, and even in-memory store. It is common to see lightweight deployments where RocksDB is used exclusively for all four functions, simplifying management and reducing infrastructure complexity. -Should you decide to use PostrgreSQL instead of the default RocksDB, you'll need to add a user and a [database schema](/docs/auth/backend/sql/#postgresql). +Should you decide to use PostrgreSQL instead of the default RocksDB, you'll need to add a user and a [database schema](/docs/auth/backend/sql/#postgresql). However, for larger deployments—particularly those running in [distributed environments](/docs/cluster/overview)—it is advisable to assign each storage role to a backend that is fit for purpose. A more scalable and robust configuration might involve **FoundationDB** as the data store, an **S3-compatible service** for blob storage, **Redis** for handling volatile in-memory data, and a dedicated search engine such as **Elasticsearch** or **Meilisearch** for full-text indexing.