Choosing Database Infrastructure Across Multiple Client Accounts

A single consultant's biggest infrastructure risk is being the only person who understands how something was set up. AWS RDS fits cleanly into Terraform or CloudFormation, so a consultant already writing infrastructure as code for compute and networking can define the database the same way, version-controlled and reproducible after the engagement ends. Supabase supports infrastructure as code through its own CLI and management API, which covers most of the same ground, but the ecosystem of existing Terraform modules and examples is smaller than what exists for RDS.

For a consultant, the practical test is simple: could someone else pick up your client's infrastructure code and understand it without asking you a question first. If the answer is no, that gap is worth closing before the engagement ends, regardless of which platform you chose.

Consultants often need a working replica of a client's setup for testing, without full access to the client's production AWS account. Supabase's free and low-cost tiers make it simple to spin up an identical, throwaway Postgres instance for that purpose, independent of whichever cloud the client's production database runs on. Replicating an RDS setup for local testing usually means either a sandboxed AWS account of your own or a local Postgres instance that approximates RDS's behavior closely enough, neither of which is quite as fast to spin up.

When you are billing hourly or on retainer, the client should own the AWS or Supabase account directly, both so costs are transparent and so nothing depends on your personal credentials staying active after the engagement ends. Set this up on day one of any engagement, not as a cleanup task afterward. Cloud hosting spend runs around 5% of ARR at the median for private B2B SaaS companies¹, a useful number to have on hand when a client asks whether their database bill looks reasonable for their size, and a useful anchor for your own estimate when a prospective client asks what their infrastructure costs are likely to look like once the build is live.

A client shipping code multiple times a day may benefit from RDS sitting in the same AWS account and VPC as the rest of an AWS-based CI/CD pipeline (for example CodeDeploy, ECS, or Lambda), which can simplify networking and access control. A client shipping in slower, scheduled batches often has less to gain from that tight coupling and more to gain from Supabase's faster initial setup. Ask about their deploy frequency before recommending a platform²; a client already deploying on demand has more to gain from the tighter AWS coupling than one still shipping in scheduled batches.

One client wants the database pinned to an older Postgres major version because their reporting tool has not been tested against the newer one; another wants the newest available version for a feature you need. Running both is normal for a consultant juggling several engagements, and it is one more reason to keep each client's infrastructure code in its own repository rather than one shared template you edit in place. Supabase makes the version choice at project creation and handles upgrades through its own dashboard; on RDS you choose the engine version explicitly and manage major version upgrades yourself, which gives you more control over timing but also more to track across several clients at once.

• Keep a template Terraform module (for RDS) and a template Supabase CLI config, so neither setup starts from scratch
• Provision under the client's own account or organization from the first day, not your own
• Document the connection pooling setup explicitly; this is the step most likely to be skipped under deadline pressure
• Hand the client a one-page runbook covering backups, recovery, and who to call, before the engagement ends
• Keep each client's infrastructure code in its own repository so version differences between clients don't collide