The access problem was smaller than a database migration
Supabase was already doing the work that mattered. It remained the operational database, supported the application, and stayed connected to existing automations. Replacing it would have expanded the project without improving the access boundary.
The narrower requirement was to let approved users retrieve business data through Claude without giving them production database accounts or an open query surface.
That changed the architecture. Supabase would keep writes, editing, and operational ownership. AWS would receive only an approved read projection. Claude would receive business actions over curated views—not credentials, generic SQL, or permission to browse the schema.
The clean replication design failed at the managed network boundary
Native PostgreSQL logical replication was the cleanest design on paper. The 41-table publication worked in disposable PostgreSQL environments, including inserts, updates, and deletes.
The managed production path failed for a precise reason: the AWS database could not reach the IPv6 address exposed by the Supabase direct database endpoint.
I retired the failed subscription, publication, and inactive slot rather than preserving a path that only worked in easier environments. The replacement was less elegant but easier to govern and recover: a guarded snapshot worker running every 15 minutes.
The snapshot made failure behavior explicit
The worker reads only explicitly approved tables and columns. It moves data in deterministic 200-row primary-key chunks, loads isolated staging tables, validates counts, and promotes all 41 destination tables in one transaction. If a run fails, the previously published read layer remains untouched.
At the July 23 acceptance check, the initial load copied 30,756 rows across 41 approved tables with zero count mismatches. A scheduled follow-up reached 30,758 rows, showing that newer source rows moved through the automated path. Those are dated acceptance measurements, not permanent current totals.
Five tools exposed business actions instead of a database
The employee-facing surface contained five bounded tools:
list_clientsget_clientget_client_guidelinessearch_documentssearch_approved_copy
Each tool mapped to a defined business question, used fixed parameterized queries over curated views, enforced input and response limits, and returned only the approved shape. None accepted generic SQL, table names, arbitrary joins, or caller-supplied vectors.
The deployed authorization suite passed 27 of 27 tests. It proved the normal user and owner tool-discovery boundaries at the service level. It did not, by itself, prove that a non-owner employee completed the full interactive Claude sign-in, so I keep that as a separate human acceptance gate.
The boundary cost more than the database
The AWS shape was estimated at $38–$45 per month. A small RDS PostgreSQL instance was estimated at about $11.68 per month, while three private interface endpoint attachments were approximately $21.90 per month. The secure boundary cost almost twice the database compute.
That is useful planning evidence, not a price promise. The estimate excluded existing Supabase and Claude subscriptions and possible Supabase egress. The $7,000 figure was the client’s quoted decision input, not a public Supabase benchmark. I would re-estimate the deployed shape before using either amount for a new project.
What this case study proves—and what it does not
The project proves that a working operational database can remain the writable owner while AI receives a smaller, governed read surface. It also proves that a guarded snapshot can be a stronger production choice than continuous replication when the managed network path rejects the elegant design.
It does not prove a permanent row count, a guaranteed monthly bill, realized savings, production return on investment, or a completed non-owner employee sign-in. Those require current operational evidence or separate human acceptance.
The reusable decision is narrower: preserve the system that already owns the work, copy only approved reads, and expose bounded business actions over the projection.
Frequently asked questions
Did this replace Supabase?
No. Supabase remained the writable operational system. AWS received an approved read projection for governed AI access.
Why not give Claude direct SQL access?
The users needed business answers, not database administration. Five bounded tools were easier to authorize, validate, audit, and explain than an open query surface.
Why use snapshots instead of logical replication?
Logical replication passed in disposable environments, but the AWS database could not reach the Supabase direct endpoint in the managed production path. The snapshot traded immediacy for deterministic validation and recovery.
Is the AWS layer guaranteed to cost $38–$45 per month?
No. That was the estimate for the deployed shape at the time. It excluded existing subscriptions and possible Supabase egress, so a new implementation would require a fresh estimate.