---
title: "Production Deployment: Overview"
---

# Production Deployment: Overview

:::caution[Planned: clustering]
HeliosDB Full runs as a single server; Raft clustering, multi-region
replication and sharding are planned. The multi-node topology on this page
describes the planned cluster. For now, run one `heliosdb-full` server and
place HeliosProxy in front of it if you need pooling.
:::

**Part of**: [Production Deployment Guide](https://www.heliosdb.com/docs/full/deployment/production_deployment_guide/)


---

## 1.1 Introduction

HeliosDB Full is a database server that combines OLTP and OLAP workloads; it runs as a single server, and clustering is planned. This guide covers deploying HeliosDB in production across cloud providers and deployment models.

**Key Features in Production**:
- Multi-model data support (relational, document, graph, time-series, vector)
- ACID-compliant distributed transactions with 2PC/3PC protocols
- AI-driven query optimization and autonomous tuning
- Advanced replication (multi-master, tenant-based, federated)
- Edge computing support with intelligent caching
- Self-healing capabilities with automatic failure detection
- Post-quantum cryptography for future-proof security
- Energy-aware optimization for sustainable operations
- Neuromorphic computing integration for real-time analytics

## 1.2 Deployment Architecture

HeliosDB supports multiple deployment topologies to meet different requirements:

```
┌─────────────────────────────────────────────────────────────────┐
│                      HeliosDB Production Cluster                 │
├─────────────────────────────────────────────────────────────────┤
│                                                                   │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐          │
│  │   Region 1   │  │   Region 2   │  │   Region 3   │          │
│  │ ┌──────────┐ │  │ ┌──────────┐ │  │ ┌──────────┐ │          │
│  │ │Compute   │ │  │ │Compute   │ │  │ │Compute   │ │          │
│  │ │Nodes (3) │ │  │ │Nodes (3) │ │  │ │Nodes (3) │ │          │
│  │ └──────────┘ │  │ └──────────┘ │  │ └──────────┘ │          │
│  │ ┌──────────┐ │  │ ┌──────────┐ │  │ ┌──────────┐ │          │
│  │ │Storage   │ │  │ │Storage   │ │  │ │Storage   │ │          │
│  │ │Nodes (5) │ │  │ │Nodes (5) │ │  │ │Nodes (5) │ │          │
│  │ └──────────┘ │  │ └──────────┘ │  │ └──────────┘ │          │
│  │ ┌──────────┐ │  │ ┌──────────┐ │  │ ┌──────────┐ │          │
│  │ │Metadata  │ │  │ │Metadata  │ │  │ │Metadata  │ │          │
│  │ │Nodes (3) │ │  │ │Nodes (3) │ │  │ │Nodes (3) │ │          │
│  │ └──────────┘ │  │ └──────────┘ │  │ └──────────┘ │          │
│  └──────────────┘  └──────────────┘  └──────────────┘          │
│          │                 │                 │                   │
│          └─────────────────┴─────────────────┘                   │
│                      Global Cache Layer                          │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Edge Nodes (CDN-like, 20+ locations worldwide)         │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                   │
└─────────────────────────────────────────────────────────────────┘
```

**Architecture Layers**:

1. **Compute Layer**: Query processing, transaction coordination, AI/ML workloads
2. **Storage Layer**: Distributed storage with replication and sharding
3. **Metadata Layer**: Raft-based consensus for cluster state management
4. **Cache Layer**: Multi-tier caching (L1: local, L2: region, L3: global)
5. **Edge Layer**: Geo-distributed edge nodes for low-latency access

## 1.3 Prerequisites

**Required Knowledge**:
- Kubernetes administration (for K8s deployments)
- Docker containerization
- Linux system administration
- Network configuration and security
- Database administration fundamentals

**Software Requirements**:
- Kubernetes 1.28+ (for K8s deployments)
- Docker 24.0+ or containerd 1.7+
- kubectl CLI tool
- Helm 3.12+ (recommended)
- Git 2.40+
- Rust 1.75+ (for building from source)

**Cloud Provider CLI Tools** (optional):
- AWS CLI 2.x (for EKS)
- gcloud CLI (for GKE)
- Azure CLI 2.x (for AKS)

## 1.4 Planning Considerations

**Capacity Planning**:

| Deployment Size | Compute Nodes | Storage Nodes | Metadata Nodes | Expected Load |
|-----------------|---------------|---------------|----------------|---------------|
| **Small** | 3 | 3 | 3 | < 1K QPS, < 100GB data |
| **Medium** | 5-10 | 5-10 | 3-5 | 1K-10K QPS, 100GB-1TB |
| **Large** | 10-20 | 10-30 | 5-7 | 10K-100K QPS, 1TB-10TB |
| **Enterprise** | 20-50+ | 30-100+ | 7-9 | 100K+ QPS, 10TB+ |

**Cost Estimation** (monthly, AWS pricing):

| Component | Small | Medium | Large | Enterprise |
|-----------|-------|--------|-------|------------|
| Compute (EC2) | $500 | $2,000 | $8,000 | $20,000+ |
| Storage (EBS/S3) | $100 | $500 | $2,000 | $10,000+ |
| Network | $50 | $200 | $1,000 | $5,000+ |
| Load Balancers | $50 | $100 | $500 | $1,000+ |
| Monitoring | $20 | $100 | $500 | $2,000+ |
| **Total** | **$720** | **$2,900** | **$12,000** | **$38,000+** |

**High Availability Considerations**:
- Minimum 3 nodes per component for quorum
- Multi-AZ deployment (minimum 3 availability zones)
- Cross-region replication for disaster recovery
- Automated failover and recovery mechanisms
- Regular backup and restore testing

**Network Requirements**:
- Low latency between nodes (< 10ms within region, < 100ms cross-region)
- High bandwidth (10 Gbps+ for production)
- Proper DNS configuration
- Load balancer configuration
- Firewall rules and security groups

---

## Navigation

- **Next**: [Infrastructure Setup](https://www.heliosdb.com/docs/full/deployment/production_deployment_infrastructure_setup/)
- **Index**: [Production Deployment Guide](https://www.heliosdb.com/docs/full/deployment/production_deployment_guide/)