Skip to main content
Persistence

PostgreSQL

Configure PostgreSQL for self-hosted Rivet deployments.

PostgreSQL is the recommended backend for multi-node self-hosted deployments. It is production-ready for light-to-moderate workloads, up to roughly 1,000 concurrent actors, but is not built for enterprise scale beyond that. For a single-node deployment, use the file system backend (RocksDB-based). Teams running larger or high-throughput realtime workloads should contact enterprise support about FoundationDB.

Choosing a Backend

Pick your database backend based on how many engine nodes you run:

  • Single-node: Use the file system backend (RocksDB). It is the recommended production-ready backend for single-node deployments. RocksDB is local to one node and cannot be shared across engine instances, and no pub/sub is needed.
  • Multi-node: Use PostgreSQL as the database and NATS for pub/sub. PostgreSQL can be shared across engine nodes and is production-ready for light-to-moderate workloads, up to roughly 1,000 concurrent actors.
  • Enterprise scale: Beyond that, or for high-throughput realtime workloads, PostgreSQL is not the right fit. Contact enterprise support about FoundationDB.

Basic Configuration

The configuration above is a complete single-node deployment and needs no pub/sub configuration, though for most single-node deployments the file system backend (RocksDB) is the recommended choice. For multi-node deployments, add NATS as the pub/sub backend so engine nodes can coordinate (see below).

Pub/Sub (NATS)

Rivet uses a pub/sub backend for realtime messaging between engine nodes. Single-node deployments do not need any pub/sub configuration.

Multi-node PostgreSQL deployments require NATS as the pub/sub backend so engine nodes can coordinate. Deploy 2+ NATS replicas for high availability.

See the production checklist and Configuration for details.

Managed Postgres Compatibility

Some hosted PostgreSQL platforms require additional configuration due to platform-specific restrictions.

SSL/TLS Support

To enable SSL for Postgres, add sslmode=require to your PostgreSQL connection URL:

The sslmode parameter controls TLS usage:

  • disable: Do not use TLS
  • prefer: Use TLS if available, otherwise connect without TLS (default)
  • require: Require TLS connection (fails if TLS is not available)

To verify the server certificate against a CA or verify the hostname, use custom SSL certificates (see below).

Custom SSL Certificates

For databases using custom certificate authorities (e.g., Supabase) or requiring client certificate authentication, you can specify certificate paths in the configuration:

ParameterDescriptionPostgreSQL Equivalent
root_cert_pathPath to the root certificate file for verifying the server’s certificatesslrootcert
client_cert_pathPath to the client certificate file for client certificate authenticationsslcert
client_key_pathPath to the client private key file for client certificate authenticationsslkey

All SSL paths are optional. If not specified, Rivet uses the default system root certificates from Mozilla’s root certificate store.

Do Not Use Connection Poolers

Rivet requires direct PostgreSQL connections for session-level features and does not support connection poolers.

Do not use:

  • PgBouncer
  • Supavisor
  • AWS RDS Proxy