Elevarq Blog
Technical writing on PostgreSQL performance, database operations, observability, and the engineering systems behind our products.
Stop getting better at firefighting
The best database incident is not the one your team resolves in 20 minutes. It is the one that never happens. PostgreSQL operations should be about making performance, cost, and security predictable, not about becoming exceptionally good at putting out fires.
postgresqlDatabase ReliabilitySREDevOpsDatabase PerformanceCloud CostsElevarqpgAgroal 1.4.5: Frontend TLS and Stricter HBA Security
pgAgroal 1.4.5 adds TLS for client connections, optional mutual TLS, stricter HBA source validation, and hardened Kubernetes deployment through Helm.
HelmKubernetespgagroalpostgresqlsecurityTLSElevarq Signals 1.3.0: Know Who Can Access What
Elevarq Signals 1.3.0 adds object and default privilege collection, making PostgreSQL grants — including access through PUBLIC — explicit, normalized, and ready for analysis.
postgresqlsecurityElevarq SignalsreleasepgAgroal Enterprise 1.2.0: Verified TLS for Amazon RDS and Aurora
pgAgroal Enterprise 1.2.0 adds verified backend TLS (verify-ca / verify-full) so the pooler authenticates your RDS or Aurora certificate against a CA, not just encrypts it. It ships with a broad security-hardening batch and is live now on AWS Marketplace and GHCR.
pgagroalpostgresqlreleasesecurityPooling was never the hard part
Putting a connection pooler in front of one database is easy, and that is why pooling gets called a solved problem. Running dozens of them the same way -- versions, certificates, config drift, upgrades across a Kubernetes fleet -- is a different problem entirely. A few opinions on why operating infrastructure is harder than installing it, and what a control plane should never do.
postgresqlpgagroal