Elevarq Blog
Technical writing on PostgreSQL performance, database operations, observability, and the engineering systems behind our products.
Elevarq 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.
postgresqlpgagroalElevarq Signals Beta 7: the road to 1.0
Beta 7 of Elevarq Signals: passwordless cloud-IAM and live secret-store auth for read-only PostgreSQL diagnostics — and the road to 1.0.
postgresqlsignalsreleasesecurityobservabilityBloat that won't come back: prevention, pg_repack, and PostgreSQL 19's REPACK
Some PostgreSQL bloat is self-healing. Some isn't. The kind that won't come back on its own — dead tuples sitting in regions of a table that no longer take writes — quietly inflates your storage bill, your backups, and your recovery time. Here's how to recognise it, prevent it with partitioning and fillfactor, and reclaim it with pg_repack today or REPACK in PostgreSQL 19.
postgresqlOperations