Database creation

Scoutflo Deploy: Database Creation and Management

This section empowers you to create and manage standalone, self-hosted databases within Scoutflo Deploy for your deployed open-source applications. These databases function as "Add-Ons" to enhance your application's functionality.

Creating a Database

Scoutflo Deploy provides a user-friendly interface for creating and configuring your database with granular control over various settings. Here's a breakdown of the available options:

Database Configuration:

• Basic Settings:

  • Config Name: Assign a descriptive name for easy identification of your database instance.

  • DB Type: Select the desired database engine from the following table:

Database Type	Description	Use Cases
MongoDB	NoSQL document-oriented database	Flexible schema, ideal for storing large and evolving data sets.
Redis	In-memory key-value data store	High-performance caching, real-time messaging, leaderboards.
MySQL	Open-source relational database management system (RDBMS)	Structured data storage for various web applications.
PostgreSQL	Open-source object-relational database management system (ORDBMS)	Advanced features like complex queries, ACID transactions.
RabbitMQ	Open-source message broker	Asynchronous communication between applications, message queuing.
Clickhouse	Open-source columnar database management system (DBMS)	Optimized for fast analytics on large datasets.

Add-on	Replication Strategy	Failover strategy
PostgreSQL	Primary-secondary	Read-only: writes unavailable until primary replica is replaced
PostgreSQL HA	Primary-secondary	Automated failover: a read replica is promoted to primary
MongoDB	Primary-secondary	Automated failover: a read replica is promoted to primary
MySQL	Primary-secondary	Read-only: writes unavailable until primary replica is replaced
Redis	Primary-secondary	Read-only: writes unavailable until primary replica is replaced
MinIO	Sharding	Damaged data is restored using healthy shards, failing replicas will be replaced
RabbitMQ (quorum queue)	Primary-secondary	Automated failover: a queue follower is promoted to leader
RabbitMQ (streams)	Sharding	Streams are available as long as a quorum of replicas is available, failing replicas will be replaced

• DB Name: Provide a unique name for your specific database instance.

• Database Version: Choose the desired version of the database application you want to deploy.

• Network Settings: Define access permissions for your database.

  • Private (Default): Database is only accessible from within your cluster for enhanced security.

  • Public: Database can be accessed externally, requiring a network load balancer and a secure TCP endpoint with TLS encryption.

• Compute Resources:

  • Plan: Select a pre-defined resource plan that allocates vCPUs and memory based on your anticipated database workload. Scoutflo Deploy offers plans optimized for development, testing, and various production deployments (details in the Plans section).

  • Custom Configuration (Optional): For advanced users, Scoutflo Deploy allows customizing vCPU and memory allocation to tailor resources to your specific needs.

• Storage:

  • Define the amount of storage space required for your database. This can be scaled up later as your data volume grows (with the caveat that scaling down is not currently supported).

• Advanced Settings:

  • Replicas: Configure the number of replica sets for your database. Replicas enhance database availability by providing failover mechanisms in case of a primary replica failure.

  • Backups (Automatic & Manual): Schedule automated snapshots for regular database backups. Scoutflo Deploy also allows initiating manual backups for added control.

  • Persistent Volumes: Attach additional storage volumes to your database instance for specific use cases requiring persistent data storage.

  • Set IP Policy Rules: Define a whitelist of IP addresses authorized to access your database, further strengthening security.

Important Notes:

• Remember that while you can increase storage size and replica count after creation, you cannot decrease them. Plan your resource allocation carefully to avoid potential limitations.

• By default, database access is set to "internal" for enhanced security. Public access requires additional configuration steps for network security.

Scaling the Database

Scoutflo Deploy empowers you to scale specific database resources as your application's needs evolve. Here's what you can adjust:

• CPU: Increase the number of vCPUs allocated to your database for handling more complex queries or higher workloads.

• Memory: Adjust the allocated memory to accommodate larger datasets or improve database performance.

• Storage Space: Scale up your storage space to store more data as your database grows.

• Number of Replicas: Enhance database availability by adding more replica sets for improved fault tolerance.

Plan Name	Configuration	Use Case
sf-compute-1-1	1 vCPU , 1 GB RAM	Development/Test Environment
sf-compute-1-2	1vCPU, 2 GB RAM	Development/Test Environment
sf-compute-1-4	1vCPU, 4GB RAM	Development/Test Environment
sf-compute-2-4	2 vCPU, 4GB RAM	Small-scale Production Deployment:
sf-compute-2-8	2 vCPU, 8GB RAM	Small-scale Production Deployment:
sf-compute-2-16	2 vCPU, 16GB RAM	Small-scale Production Deployment:
sf-compute-4-8	4 vCPU, 8GB RAM	Medium-scale Production Deployment
sf-compute-4-16	4 vCPU, 16GB RAM	Medium-scale Production Deployment
sf-compute-8-8	8 vCPU, 8GB RAM	Large-scale Production Deployment
sf-compute-8-24	8 vCPU, 24GB RAM	Large-scale Production Deployment
sf-compute-8-32	8 vCPU, 32GB RAM	Large-scale Production Deployment
sf-compute-8-40	8 vCPU, 40GB RAM	Large-scale Production Deployment

Database Availability

Scoutflo Deploy prioritizes ensuring your database's high availability (HA) to minimize downtime during potential failures. Here's how it works:

• Replication Strategies: Different database types utilize various replication strategies to maintain data redundancy and availability:

  • Primary-Secondary Replication: A common approach where a primary replica handles read/write requests, while secondary replicas maintain synchronized copies of the data. In case of a primary failure, a secondary replica can be automatically promoted to minimize downtime.

  • Sharding: This strategy distributes data across multiple replicas, potentially not all containing the full dataset. This can enhance scalability for very large datasets.

• Failover: Scoutflo Deploy's built-in mechanisms automatically detect primary replica failures and promote a secondary replica, ensuring minimal service disruption.

• Service URI Persistence: During failover, the database service URI remains unchanged. Only the IP address pointing to the