Aurora Postgres speaks the standard Postgres wire protocol underneath AWS's storage layer, so QueryFlow connects to it the same way it connects to any Postgres database, plus a few Aurora-specific details worth knowing.
No credit card. 14 days. Cancel in one click.
Quick answer: QueryFlow connects to Amazon Aurora PostgreSQL as a standard Postgres connection: host (the cluster's writer or reader endpoint), port 5432, database, username, and password, with SSL. Add the writer and reader endpoints as separate connections if you use both. QueryFlow's Postgres connection uses username and password, not IAM token auth.
Everything QueryFlow's general Postgres Mac client page says still applies to Aurora, the same editor, the same Ask panel, the same scheduling. What's worth calling out specifically for Aurora is the handful of details that trip people up the first time: which endpoint to use, whether IAM auth is an option, and what SSL mode AWS expects. That's what this page covers.
Amazon Aurora PostgreSQL is wire-compatible with standard PostgreSQL, the storage and replication architecture underneath is AWS's own, but nothing about that changes how a client talks to it. If you've connected to any managed Postgres before, RDS, Supabase, Neon, Aurora looks the same from the client side: a hostname, a port, credentials, and SSL.
In the RDS console, open your Aurora cluster and look at Connectivity & security. You'll see a Writer endpoint and, if you've provisioned any replicas, a Reader endpoint that load-balances across them. Copy whichever one matches what you're trying to do, writer for anything that inserts or updates, reader for read-only analytical queries you'd rather not run against your primary.
Click the + next to Databases, choose PostgreSQL, and fill in:
my-cluster.cluster-abc123xyz.us-east-1.rds.amazonaws.comIf you use both endpoints, add each as its own connection with a clear name, orders-aurora-writer and orders-aurora-reader, so you don't accidentally point an analytical query at the writer or a write at the reader.
Aurora supports IAM database authentication, generating a short-lived token in place of a stored password, and it's a reasonable security posture for some teams. QueryFlow's Postgres connection is built around a standard username and password, so IAM token auth isn't a fit unless you're willing to regenerate the token and re-enter it as the password each time it expires, which for most people defeats the point. If IAM auth is a hard requirement for your Aurora cluster, a native username/password user (or IAM auth handled by a proxy in front of the connection) is the more workable path with QueryFlow today.
Same standard Postgres SQL as any other Postgres source:
SELECT plan_name, COUNT(*) AS active_subscriptions FROM public.subscriptions WHERE status = 'active' GROUP BY plan_name ORDER BY active_subscriptions DESC;
The Explorer tab lists schemas and tables the same way it does for any Postgres connection, and the Ask panel writes standard Postgres SQL against whichever tables it can see through the connection.
Once connected, Aurora works like any Postgres connection for scheduling a query, watching a result with Watch This, or syncing data with Data Sync into or out of it. If you're moving data from Aurora into a warehouse for analytics, that's a Data Sync job with Aurora as the source; the reverse, syncing warehouse data back into Aurora, works the same way with Aurora as the target.
A frequent setup for teams running Aurora in production is pointing all reporting and ad-hoc analysis at the reader endpoint, keeping every query someone runs by hand off the writer that application traffic depends on. Add the reader endpoint as its own connection, name it clearly, and treat the writer connection as something you use deliberately, for a migration script or a one-off correction, rather than by default. QueryFlow doesn't enforce this separation for you; it's a habit worth building into how the connections get named and used day to day.
If an application writes to Aurora continuously and you want to know if it silently stops, a row-count Watch on a recent time window catches that the same way it would on any Postgres source:
SELECT COUNT(*) AS rows_last_hour FROM public.events WHERE created_at >= NOW() - INTERVAL '1 hour';
Watch rows_last_hour with condition Equals 0, checked every 1h, against the reader endpoint, so the check itself never adds load to the writer it's monitoring.
Yes. Aurora's writer and reader endpoints are just different hostnames on the same Postgres wire protocol, add each as its own QueryFlow connection with a name that makes clear which is which.
QueryFlow's Postgres connection uses username and password authentication. Aurora's IAM auth generates a short-lived token in place of a password, which isn't a fit for a client that expects a stored credential unless you're comfortable regenerating and re-entering the token yourself.
AWS enables SSL by default on Aurora Postgres clusters and recommends using it. Set sslmode to require or verify-full in the connection settings, matching what your cluster's parameter group enforces.
Yes, Aurora Postgres is a standard Postgres connection, so scheduling, Watches, and Data Sync all work the same way they do for any Postgres source.
14-day free trial, no card. Add your writer and reader endpoints in a minute.
No credit card. 14 days. Cancel in one click.