Creating a Database ​

This guide explains how to create a new managed database instance using the AppsCode console. The creation process is a multi-step wizard that walks you through selecting a database engine, setting a name and namespace, configuring topology and resources, and enabling optional features like monitoring, TLS, and backups.

1. Getting Started ​

Navigate to the Datastore section in the left sidebar. The Datastore Overview page lists all existing database instances across your connected engines.

To create a new database, click the green + Create New Instance button in the top-right corner of the page.

2. Select a Database Type ​

You will be presented with a grid of all supported database engines. Click on the engine you want to provision.

Tip: The console supports a wide range of engines including relational, document, key-value, search, and time-series databases. Select the engine that best fits your workload.

3. Choose Namespace and Name ​

After selecting the database type, you will be prompted to choose a namespace and provide a name for the new instance.

1. Select Namespace: Choose the Kubernetes namespace where the database will be deployed. If the namespace has resource quotas, available CPU and memory will be shown to help you stay within limits.
2. Name: Enter a unique name for the database instance. The name must start with a lowercase letter and can contain letters, numbers, or dashes.

Click Next to proceed to the configuration step.

Note: Both fields are required (marked with a red asterisk). The name cannot be changed after creation.

4. Configure the Database ​

The main configuration page shows all settings for the new database. At the top, the namespace and name you chose are displayed as a breadcrumb (e.g., demo / mongo-test).

4.1 - Database Version ​

Select the database engine version from the Database Version dropdown. The version determines the engine features, compatibility, and runtime behaviour of your cluster.

4.2 - Database Mode ​

Select the topology for your database under Database Mode. Three modes are available:

• Standalone — A single-node database without high availability or sharding. Best for development or low-traffic workloads.
• Replicated Cluster — A MongoDB ReplicaSet for high availability.
• Sharded Cluster — A fully sharded MongoDB cluster for high performance and high availability.

Replicated Cluster ​

When Replicated Cluster is selected, two additional fields appear:

Sharded Cluster ​

When Sharded Cluster is selected, three subsections appear — Shard Nodes, Config Server, and Mongos — each configurable independently.

Shard Nodes — Configure how MongoDB data is partitioned, replicated, and resourced across your cluster.

Config Server — Stores metadata about the sharded cluster including chunk distribution and shard configuration. Must run as a replica set.

Mongos — Acts as the query router for the sharded cluster, directing client requests to the appropriate shards based on metadata from Config Servers.

4.3 - Machine Profile ​

The Machine Profile dropdown lets you select a preset CPU and memory configuration for your database nodes. Choose custom to enter specific CPU and memory values manually.

Tip: Preset profiles are named by size (e.g., db.t4large). Use custom when your workload requires resources that do not match any preset.

4.4 - Storage Class and Size ​

Select the Kubernetes Storage Class that will back the database persistent volumes, and enter the required Storage size.

5. Advanced Configuration ​

Expand the Advanced Configuration panel (labelled Configure Credentials, Deployment Mode etc.) to access additional settings.

5.1 - Labels & Annotations ​

Add custom Kubernetes labels and annotations to the database resources for organization, monitoring, and integration with other tools and services.

• Use + Add new under Labels to attach key-value label pairs.
• Use + Add new under Annotations to attach key-value annotation pairs.
• Use the delete icon on any row to remove it.

5.2 - Deletion Policy ​

The Deletion Policy dropdown controls what happens to the database resources when the database object is deleted from Kubernetes.

Warning: WipeOut permanently destroys all data. Ensure you have a valid backup before selecting this policy.

5.3 - Authentication Credentials ​

Configure how the database root credentials are managed.

5.4 - Point in-time Recovery ​

Enable Point in-time Recovery to restore the new database from a previous backup to an exact timestamp.

1. Namespace: The namespace where the source backup resides. Required.
2. Name: The name of the source database to recover from. Required.
3. Recovery Timestamp: The exact date and time to restore to (mm/dd/yyyy, hh:mm). Required.

Note: All three fields are required when Point in-time Recovery is enabled. Leaving any field empty will show an "Error in fields" warning.

6. Additional Options ​

Expand the Additional Options panel (labelled Enable Backup, Monitoring, TLS etc.) to enable integrated platform features for the new database.

7. Deploy ​

Once all required fields are filled and options are configured, click the green Deploy button at the bottom-right of the form to create the database.

Note: Required fields are marked with a red asterisk. The Deploy button will be active only when all required fields are valid. If any field has an error, a validation summary will appear above the button.

Quick Reference ​