The one thing to understand first
Every convenience a managed service gives you is paid for with a capability it takes away. The provider can only guarantee the database stays up, durable, and patched if it stops you from doing the things that would break that guarantee. Knowing exactly what you give up — before you build on it — prevents the nasty surprise of discovering a hard wall mid-project.
No superuser, no OS
You do not get the PostgreSQL superuser role or shell access to the host. You get a powerful admin role, but not the privileges that would let you read arbitrary files, load untrusted C code, or change protected settings. Anything that assumed filesystem access (server-side COPY from a local path, custom C extensions, reading server log files directly) needs a managed-service equivalent or is simply unavailable.
Extension allowlists and locked parameters
You can only install extensions the provider has vetted and put on its allowlist. Popular ones (PostGIS, pg_stat_statements, pgvector, pg_trgm) are almost always present; a niche or brand-new extension may not be — check before you design around it. Likewise, you configure the engine through parameter groups / flags / server parameters, and a subset of settings is locked or range-limited because changing them would endanger the managed contract.