Databases overview

Every managed database on StackBlaze can run as a single Standard instance or as a replicated, high-availability deployment. Pick the topology per database when you create it.

Standard vs high availability

Each database add-on supports two deployment topologies. You choose between them when you create the instance (and you can scale up later by raising the replica count).

Enabling HA from the Postgres add-on's High availability tab. The cluster scales from a single primary to 3 instances with streaming replication.

Standard

A single instance with its own persistent volume. It is the simplest and lowest-cost option, and it is a good fit for development, internal tools, and workloads that can tolerate a short restart during maintenance or a node move. There is no automatic failover: if the pod or its node is rescheduled, the database is briefly unavailable until it comes back.

High availability (HA)

A clustered deployment with a primary plus one or more replicas spread across different nodes. Writes go to the primary and stream to the replicas; if the primary fails, the cluster promotes a replica automatically so the database stays available. HA also lets you serve reads from replicas to take load off the primary. It uses more resources, so it is the right choice for production and anything with an uptime requirement.

	Standard	High availability
Instances	Single	Primary + 1 or more replicas
Node spread	One node	Replicas on separate nodes
Failover	None (restart)	Automatic primary promotion
Read scaling	Primary only	Reads can fan out to replicas
Best for	Dev, internal, non-critical	Production, uptime SLAs

Choosing a topology

Start Standard for development and switch to HA before you carry production traffic. For most engines you raise the replica or node count and StackBlaze performs a rolling change with no data loss.

Available databases

StackBlaze provisions each database through a Kubernetes operator, so the same engine you run locally runs in your project with private networking. Attach an add-on from its Connections list or the app Add-ons tab to inject connection environment variables. Backups are opt-in on the add-on Backups tab — they are not enabled automatically. The table below lists every managed database and the topologies it supports.

Relational (SQL)

Database	Engine	Topologies
PostgreSQL	CloudNativePG	Standard + HA
MySQL	MariaDB (MySQL-compatible)	Standard + HA
CockroachDB	Distributed SQL	Standard + HA

Key-value & cache

Database	Engine	Topologies
Redis	Valkey (Redis-compatible)	Standard + HA
Memcached	Memcached	Standard only

Document

Database	Engine	Topologies
MongoDB	DocumentDB (MongoDB-compatible)	Standard + HA
CouchDB	Apache CouchDB	Standard + HA

Search & vector

Database	Engine	Topologies
OpenSearch	OpenSearch	Standard + HA
Milvus	Milvus (vector DB)	Standard + HA

Analytics

Database	Engine	Topologies
ClickHouse	ClickHouse	Standard + HA

Wide-column

Database	Engine	Topologies
Cassandra	Apache Cassandra	Standard + HA
ScyllaDB	ScyllaDB (Cassandra-compatible)	Standard + HA

One engine, the names you know

Some databases are served by a compatible engine so we can ship them under a permissive license without changing your client code. MongoDB is provided by DocumentDB (MongoDB wire protocol), Redis by Valkey, and MySQL by MariaDB. Your existing drivers, connection strings, and tools work unchanged.

See Backups & recovery to enable snapshots on an add-on, plus point-in-time recovery for PostgreSQL and MariaDB.

Looking for messaging? Kafka and RabbitMQ are documented under Messaging.