# Cluster CPU + Memory

As described in [Vertical Scaling](/embedded/scaling#vertical-scaling), the most effective way to scale Synqly Embedded is to make more CPU and Memory available for the `embedded` Pod. In order to do so, the Kubernetes cluster running Embedded must have the target amount of CPU and Memory available and allocatable.

The following are general CPU and Memory recommendations for running Embedded in both pre-production and production environments. Please note that CPU and Memory requirements can vary based on the request throughput and compute requirements of incoming requests. The values included here are meant as a starting point and may need to change to accommodate higher throughput or more complex queries.

The recommended buffer resources in both environments are included to accommodate load increases over time. If you anticipate rapid changes in inbound requests, it may make sense to add additional buffer resources.

## Pre-Production

The following values represent the minimum recommended resources for running Synqly Embedded in pre-production developer or POC environments.

| Component | CPU (vCPUs) | Memory (GB) |
|  --- | --- | --- |
| Embedded | 1.0 | 1.5 |
| Management UI | 0.5 | 1.0 |
| Connect UI | 0.5 | 1.0 |
| Scaling Room (buffer) | 1.0 | 0.5 |
| **Total Recommended** | **3.0** | **4.0** |


## Production

The following resource allocations are the recommended baseline for production environments. The lower end of the range represents medium-scale deployments handling tens of thousands of requests a minute, while the upper range represents large-scale deployments handling hundreds of thousands of requests a minute.

| Component | CPU (vCPUs) | Memory (GB) |
|  --- | --- | --- |
| Embedded | 4.0-8.0+ | 8.0-16.0+ |
| Management UI | 1.0 | 2.0 |
| Connect UI | 1.0 | 2.0 |
| Scaling Room (buffer) | 1.0 | 2.0 |
| **Total Recommended** | **7.0-11.0+** | **14.0-22.0+** |


## Monitoring

Once Synqly Embedded has been deployed, there are several metrics that can be helpful in determining whether more CPU or Memory are required. An increase in [Request Durations](/embedded/monitoring#request-durations) is the most common signal that the `embedded` Pod requires either more CPU or Memory to handle the current throughput of inbound requests.

Monitoring the CPU and Memory Utilization as described in [Kubernetes Pod Metrics](/embedded/monitoring#kubernetes-pod-metrics) will help track the percentage of allocated resources that are being actively used.

# Database

When preparing infrastructure for Synqly Embedded, it's important to configure the PostgreSQL-compatible database with enough headroom for production operations. The target Database has to have enough storage to accommodate future Synqly usage, as well as enough concurrent connections to support the desired number of Embedded Pods. This section covers a reasonable baseline configuration for production Synqly Embedded databases.

## Storage

Synqly Embedded is designed from the ground up to optimize for storage. It doesn't clone provider data or store query results past the duration of the HTTPS call requesting them. The only persistent data that Embedded stores are Synqly Management API objects and audit logs. Examples of stored Management API object are:

- Accounts
- Integrations
- Credentials
- Members


For more information on which APIs are classified as Management APIs, refer to our [Management API Overview](/api-reference/management).

Although storage requirements will always vary based on usage patterns, Embedded has relatively modest needs. As a point of comparison, Synqly's largest SaaS environment (running the same code as Embedded) uses less than 50 GB of active DB storage after years of continuous operation. Our largest Embedded test environment uses garbage collection to routinely clean out old Management config and uses less than 2 GB.

When deploying a new Embedded environment, allocating 100 GB for the database should ensure a comfortable runway for production use. If your database of choice supports resizing, you can also add more storage down the line if it's needed. If your selected database instance does not support resizing, or the resizing requires downtime, you may want to allocate more storage at first to avoid future maintenance windows.

## Connection Pool

The number of database connections required for Synqly Embedded scales directly based on the number of `embedded` Pods that you configure in your environment. Each `embedded` Pod reserves a database connection pool of up to 50 connections. Those connections are allocated to incoming API requests as needed. `embedded` automatically batches database transactions for a given API call into a single database connection.

As a result of the connection pooling and transaction batching, the database connection load should remain static, even in the event of increased API traffic.

When planning your database, use the following simple calculation. Please keep in mind the recommendations from [Scaling Synqly Embedded](/embedded/scaling#scaling-synqly-embedded), i.e. that additional replicas provide increased availability, but do not meaningfully increase request throughput.


```
(Number of `embedded` replicas) * 50 = Required database connections
```