StackGres supports ARM64 (aarch64) architecture, enabling deployment on ARM-based infrastructure including AWS Graviton, Apple Silicon, and other ARM processors.
StackGres provides multi-architecture container images that run on both:
The architecture is automatically detected and the appropriate image layers are used.
All StackGres operator components are available for ARM64:
| Component | ARM64 Support |
|---|---|
| stackgres-operator | Yes |
| stackgres-restapi | Yes |
| stackgres-jobs | Yes |
| stackgres-admin-ui | Yes |
StackGres PostgreSQL images are built for both architectures:
| Image | ARM64 Support |
|---|---|
| patroni | Yes |
| pgbouncer | Yes |
| envoy | Yes |
| postgres-util | Yes |
| prometheus-postgres-exporter | Yes |
| fluent-bit | Yes |
PostgreSQL extensions are built separately for each architecture. Extension availability may vary between amd64 and arm64.
The cluster status shows the detected architecture:
kubectl get sgcluster my-cluster -o jsonpath='{.status.arch}'
Output: aarch64 or x86_64
Extensions are downloaded based on the detected architecture:
Some extensions may only be available for x86_64. Check the extensions catalog for availability.
These popular extensions are available on ARM64:
| Extension | ARM64 | Notes |
|---|---|---|
| postgis | Yes | Full support |
| pgvector | Yes | Full support |
| pg_stat_statements | Yes | Built-in |
| pg_cron | Yes | Full support |
| timescaledb | Yes | Full support |
| pg_repack | Yes | Full support |
Some extensions may have limited or no ARM64 support:
| Extension | ARM64 | Notes |
|---|---|---|
| citus | Limited | Check version |
| pgaudit | Yes | Recent versions |
Tip: If an extension isn’t available for ARM64, consider using a custom extension build or switching to x86_64 for that workload.
Deploy on AWS Graviton processors for cost-effective ARM64 instances:
# Node affinity for Graviton instances
apiVersion: stackgres.io/v1
kind: SGCluster
metadata:
name: graviton-cluster
spec:
instances: 3
postgres:
version: '16'
pods:
persistentVolume:
size: '100Gi'
scheduling:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/arch
operator: In
values:
- arm64
Or use node selector:
pods:
scheduling:
nodeSelector:
kubernetes.io/arch: arm64
Deploy on Google Cloud’s ARM-based instances:
pods:
scheduling:
nodeSelector:
cloud.google.com/machine-family: t2a
kubernetes.io/arch: arm64
Deploy on Azure’s ARM-based VMs:
pods:
scheduling:
nodeSelector:
kubernetes.io/arch: arm64
The Helm chart automatically selects the correct image architecture:
helm install stackgres-operator \
--namespace stackgres \
--create-namespace \
stackgres-charts/stackgres-operator
No additional configuration is needed - the operator detects the node architecture.
For Kubernetes clusters with both amd64 and arm64 nodes:
# Operator on specific architecture
helm install stackgres-operator \
--namespace stackgres \
--set operator.nodeSelector."kubernetes\.io/arch"=arm64 \
stackgres-charts/stackgres-operator
Target ARM64 nodes for database workloads:
apiVersion: stackgres.io/v1
kind: SGCluster
metadata:
name: arm-cluster
spec:
instances: 3
postgres:
version: '16'
pods:
persistentVolume:
size: '50Gi'
scheduling:
nodeSelector:
kubernetes.io/arch: arm64
tolerations:
- key: "arm64"
operator: "Exists"
effect: "NoSchedule"
| Workload Type | ARM64 Suitability |
|---|---|
| OLTP | Excellent |
| Read-heavy | Excellent |
| Write-heavy | Good |
| Analytics/OLAP | Good |
| Extension-heavy | Verify availability |
kubectl get pods -n stackgres -o wide
kubectl exec -n stackgres deploy/stackgres-operator -- uname -m
kubectl exec my-cluster-0 -c patroni -- uname -m
Expected output: aarch64 for ARM64 or x86_64 for AMD64.
Test extensions: Verify all required extensions are available on ARM64 before migration
Use node selectors: Explicitly target ARM64 nodes for predictable behavior
Monitor performance: Compare metrics between architectures during migration
Keep images updated: ARM64 support improves with each release
Plan for mixed clusters: If some workloads need x86_64, design cluster topology accordingly