Production-grade Postgres.
Tuned, pooled, yours.
Managed Postgres is easy until the invoice lands. Rolling your own means hand-tuning configs and standing up a pooler. Autopg ships both as Docker images: a Postgres that configures itself to the host, and a connection pooler you set up once.
services: postgres: image: ghcr.io/piercefreeman/autopg:pg18-latest environment: AUTOPG_DB_TYPE: oltp ports: - 5432:5432Two pieces stand between you and self-hosted Postgres. So we built both.
The official Postgres image is deliberately generic. It boots with defaults sized for a laptop, so on a real server it leaves memory unused and parallelism switched off. Getting it production-ready means learning pgtune, reading the docs, and babysitting a postgresql.conf you copy between machines.
Then your app opens more connections than Postgres should hold at once, and you need a pooler. pgbouncer is the answer, but it speaks INI files, a separate userlist, and hand-computed password hashes. Autopg takes both jobs off your plate. The image tunes itself. The pooler reads one TOML file. Both are just containers you run.
Tuned Postgres, drop-in
Swap your postgres image for this one. It sizes shared_buffers, work_mem, WAL, and parallelism to the host on first boot.
image: ghcr.io/piercefreeman/autopg:pg18-latest
# boots tuned to CPU, memory, and diskpgbouncer, minus the sprawl
One TOML file for users, grants, and upstreams. Secrets stay in the environment and the hashes are generated for you.
[[users]]
username = "app"
password = "$APP_PASSWORD"
grants = ["main"]
# routed to [pools.main.remote]Tuned to the box it boots on.
On startup autopg reads the CPU count, memory, and disk type of the host and writes a postgresql.conf sized to match. No copy-pasting pgtune output, no conservative defaults leaving half your RAM on the table.
Tell it what the database is for.
Pick web, OLTP, data warehouse, desktop, or mixed. The tuning moves with it: connection limits, parallel workers, planner costs, and WAL sizing all shift to fit the shape of your traffic. Our algorithm builds on the battle-tested pgtune.
A real connection pooler, configured once.
autopg-pool wraps pgbouncer behind a single TOML file. Declare users, grants, and upstream databases. Passwords come from the environment and MD5 hashes are computed for you.
See the queries that hurt.
An optional dashboard surfaces sequential scans, unused indexes, and the queries eating your time. Each slow query comes with a ready-to-run EXPLAIN ANALYZE so you can reproduce it in seconds.
Managed Postgres is easy. Until the bill arrives.
RDS and Cloud SQL charge a steep premium for tuning and a pooler you could run yourself, and every upgrade pulls you deeper into one vendor. Autopg gives you the same production setup on hardware you control: a Postgres image tuned to the machine, and a pooler in front of it. Both are MIT. Both are just Docker.
$ docker run -p 5432:5432 \ ghcr.io/piercefreeman/autopg:pg18-latest → Postgres boots tuned to the host. No flags.Swap one line and go.
It is the Postgres you already know, shipped as a drop-in image. Point your compose file at autopg:pg18-latest and it boots tuned to the host. Add the pooler when your connection count climbs. Override any value the moment you want to.
Autopg keeps the database healthy. The rest builds on top.
Each tool stands alone, but they share one assumption: Postgres is the backbone. Run autopg underneath and the rest of the stack talks to the same database, from your ORM to your background jobs.
A high-speed, type-driven ORM for the Postgres autopg runs. Typed SELECTs, INSERTs, and migrations straight from your Python.
VisitA strongly-conventioned full-stack framework for Python. Server-rendered React with no API glue to write.
VisitDurable background workflows on the same Postgres. Plain async Python that survives restarts, with no replay.
VisitRun Postgres in production.
Without renting it.
A tuned image and a pooler. Everything you need to self-host, and nothing you have to babysit.