Deploy ParticleDB
Before deployment
Section titled “Before deployment”Record the server version, configuration and data location. Choose storage with adequate capacity, configure authentication and TLS, and restrict network access. Test with your application’s client versions.
Start an authenticated instance
Section titled “Start an authenticated instance”Provision a certificate and private key for the database hostname and a password file readable only by the database service account. See TLS and authentication for certificate setup.
particledb start \ --data-dir /var/lib/particledb \ --http-addr 127.0.0.1:7173 \ --pg-addr 127.0.0.1:5432 \ --redis-addr 127.0.0.1:6379 \ --grpc-addr 127.0.0.1:26257 \ --pdb-addr 127.0.0.1:5440 \ --metrics-addr 127.0.0.1:7175 \ --no-unix-sockets \ --auth-method scram-sha-256 \ --pg-password-file /etc/particledb/password \ --tls-cert /etc/particledb/server.crt \ --tls-key /etc/particledb/server.key \ --require-tls-for-credentials \ --wal-sync-mode groupsyncThis example keeps access local. To accept connections from application hosts, bind only the required client address to a private interface and restrict it with your network policy. The native client address is explicitly restricted to loopback. The MySQL interface remains disabled unless explicitly enabled in configuration.
Run the process under your service manager with a dedicated account, a writable data directory and a defined restart policy. Retain the startup logs and verify a query using your application’s TLS settings before directing traffic to it.
Persistent data
Section titled “Persistent data”Use a persistent data directory outside temporary storage. Do not run two servers against the same directory. Review durability and restart and the effects of your configured persistence mode.
Resources and monitoring
Section titled “Resources and monitoring”Set memory limits and connection limits. Configure monitoring and verify that your application recognizes failed health checks and connection errors.
Recovery
Section titled “Recovery”Practice a restore using the backup or export path available in your edition. Check data and schema before directing application traffic to the restored instance. A clean shutdown test does not establish power-loss recovery behavior.
Upgrade
Section titled “Upgrade”Read release notes, retain a recovery path, and validate the new binary against a copy of representative data before changing production. See upgrades.