"Managed" is one of those words that sounds like a convenience and is actually a risk transfer. When you run Postgres yourself, a dozen unglamorous jobs sit on your plate — backups that are tested, patches applied on time, failover that actually fails over, pooling so a traffic spike doesn't exhaust connections. Skip any of them and you find out at the worst possible moment. A good managed platform takes those jobs off your plate. Here's what should be in the box.

What "managed" should mean

  • Automated backups + point-in-time recovery — restore to a moment, not just last night.
  • Row-Level Security — access rules enforced by the database, not scattered in app code.
  • Connection pooling — a pooled and a direct connection string for app vs tooling.
  • Observability — REST and database logs, with audit-grade trails when you need them.
  • High availability & DR — redundancy and off-site, ideally cross-region, backups.

What "managed" means

A managed PostgreSQL service runs the database for you: provisioning, security patching, backups, pooling, monitoring, high availability and disaster recovery. You get a connection string and spend your time on schema and queries; the operational surface — precisely the parts that cause outages and data loss when neglected — is handled. The value isn't "I didn't have to run apt install postgresql"; it's that the 3am failure modes are somebody's full-time job.

Automated backups & point-in-time recovery

Every serious database needs backups; a production database needs point-in-time recovery (PITR). The difference matters. A nightly dump lets you restore to last night — so a bad migration at 4pm costs you a whole day. PITR combines periodic base backups with a continuous stream of write-ahead log (WAL) records, so you can roll the database forward to any moment: to 3:59pm, just before the mistake. You lose minutes, not a day.

The other half of the story is where the backups live. A backup in the same facility as your primary is not a disaster-recovery plan. Backups should be held off-site — ideally in a different region — so a single-city incident can't take out both your database and its safety net.

A backup you've never restored is a hope, not a plan. PITR turns "we think we can recover" into "we can recover to 3:59pm."

Row-Level Security: access rules in the database

Row-Level Security (RLS) is PostgreSQL's answer to a question every multi-user app faces: which rows is this user allowed to see and change? Without RLS, that logic lives in application code — a WHERE tenant_id = ? repeated in hundreds of places, one forgotten clause away from a data leak. With RLS, you attach a policy to the table, and the database enforces it on every query, including the ones you didn't think to guard.

This is the backbone of safe multi-tenant isolation: define once that a row belongs to a tenant and that authenticated users only touch their tenant's rows, and the guarantee holds no matter how your API grows. A managed platform that pairs RLS with JWT-based roles gives you application-grade authorisation that lives where it can't be bypassed — in the data layer.

Connection pooling & the two connection strings

PostgreSQL connections are relatively expensive, and modern apps — especially serverless ones — open many short-lived ones. Without pooling, a traffic spike exhausts the connection limit and the database starts refusing work. A connection pooler multiplexes many client connections onto a few database ones, so you stay up under load.

That's why managed platforms typically expose two connection strings:

Use the pooled URL for your app and the direct URL for tooling, both over TLS, and you get resilience under load without breaking the tools that need a real session.

Observability: logs & audit trails

You can't debug or govern what you can't see. Managed Postgres should give you read-only access to database access logs (connections, errors, slow activity) and, where an API layer is generated, REST request logs — so you can trace a slow endpoint or an unexpected error without SSH-ing into a box. For regulated workloads, statement-level auditing via pgaudit produces audit-grade trails of who did what, feeding straight into your Privacy Act and compliance story.

High availability & disaster recovery

Hardware fails and zones have bad days. High availability keeps a standby ready to take over so a single failure doesn't become an outage, while disaster recovery — off-site, cross-region backups plus PITR — is your insurance against the larger, rarer events. Together they turn "the database is down and we're not sure we can get the data back" into a bounded, recoverable incident.

What you still own

Managed does not mean absolved. Even with excellent backups, you should keep your own periodic exports of critical data — for portability, for extra safety, and to meet your own retention and audit obligations. You also own your schema design, your indexes, your RLS policies and your queries. A managed platform removes the operational risk; the shape and correctness of your data remain yours.

How WattleDB's managed Postgres is built

WattleDB gives you managed PostgreSQL with all of the above: automated backups with point-in-time recovery, Row-Level Security paired with JWT-based roles for multi-tenant isolation, a pooled DATABASE_URL and a direct DIRECT_URL over TLS, read-only REST and database logs (with pgaudit for audit-grade trails), and an auto-generated REST API on top of your schema. It all runs on 100% Australian-owned infrastructure in Sydney, with cross-state backups in Melbourne so your primary and your safety net are never in the same city — and never outside Australian jurisdiction.