System requirements
A self-hosted instance of Tonic Ephemeral has the following requirements.
PostgreSQL application database
The Ephemeral application database stores information about Ephemeral objects and users.
For the application database, you must provide a PostgreSQL database with the following characteristics:
Version:
PostgreSQL 16+
Database user:
Must have permission to:
Create a database
Create tables
Insert
Select
Cluster node type and block storage
Your Kubernetes cluster supports your Ephemeral databases. For persistent storage, it uses one volume mount per database instance.
When you provision your Kubernetes cluster, it is important to select the appropriate node types and block storage types.
These recommendations are based on your workload requirements, and cover the following major cloud providers:
AWS
Azure
Google Cloud
Factors to consider
CPU and memory requirements
Determine the CPU and memory requirements of your Ephemeral database instances to ensure that the selected node types can handle the workload.
For information, go to Setting the required resources for a database.
Network performance
Evaluate the network performance requirements, especially if your application involves significant data transfer between nodes.
Cost
To balance performance and cost, select instance types that meet your requirements, but that do not over-provision resources.
Ephemeral deployment resources
Volume attachment limits
Each instance type has volume attachment limits. When you select a node type, you need to consider these limits.
Each Ephemeral database requires one block storage volume attachment.
General-purpose compute options typically support between 20 and 30 volume attachments.
Large instance types support higher limits.
Block storage selection
When you configure block storage for Ephemeral database instances, select the appropriate block storage type based on your performance requirements.
AWS
gp3
General-purpose solid-state drive (SSD). Suitable for most workloads.
Provides consistent performance with the ability to provision IOPS and throughput independently.
Azure
Standard SSD
Suitable for most workloads. Provides a balance between cost and performance.
Premium SSD
Suitable for I/O-intensive workloads that require low latency.
Provides consistent performance with high IOPS and throughput.
Google Cloud
SSD Persistent Disk
Suitable for I/O-intensive workloads that require low latency.
Provides consistent performance with high IOPS and throughput.
Example scenarios - AWS m6a.4xlarge node
The table below covers multiple scenarios for deploying an Ephemeral database in AWS on a single m6a.4xlarge node, which has 16 vCPU and 64 GB memory.
It demonstrates the factors to consider when you determine the number of databases that a node can support.
Note that this instance type can support a maximum of 28 Amazon Elastic Block Store (EBS) attachments. Because EBS attachments correspond one-to-one with Ephemeral databases, this instance type can support no more than 28 Ephemeral databases, regardless of the CPU and memory considerations.
Only Nano (0.125 vCPU / 0.5 GB memory)
Only Micro (0.250 vCPU / 2.0 GB memory)
Only Small (1 vCPU / 4.0 GB memory)
Only Nano
In the only Nano scenario, the instance has enough CPU and memory to support 128 databases. However, it will reach the limit of 28 EBS attachments before it reaches the other resource limits.
If you run many minimally resourced Ephemeral databases, you should instead deploy multiple smaller nodes that better balance the usage of CPU/memory and the EBS attachment limits.
Only Micro
In the only Micro scenario, the instance has enough CPU and memory to support 32 databases. However, similar to the only Nano scenario, the instance will reach the limit of 28 EBS attachments before it reaches the other resource limits.
While the CPU and memory are still not fully utilized, they are closer to full utilization.
This instance might be suitable for this scenario.
Only Small
In the only Small scenario, the instance has enough CPU and memory to support 16 databases. The memory and CPU are fully utilized before they are bottlenecked by the limit on EBS attachments.
This is an efficient use of the instance, and the instance is suitable for this scenario.
Database resource configuration
0.125 cores / 0.5 GiB (Only Nano)
0.500 cores / 2.0 GiB (Only Micro)
1.000 core / 4.0 GiB (Only Small)
CPU per pod
0.125
0.5
1
Memory per pod
0.5 GiB
2.0 GiB
4.0 GiB
Max pods by CPU
128
32
16
Max pods by memory
128
32
16
Max pods by EBS attachments
28
28
28
Max pods on node
28
28
16
Cluster runtime and software requirements
The Kubernetes cluster where you deploy Ephemeral has the following requirements:
Runtime is either:
Last updated
Was this helpful?