In July 2026, a client’s team lost the clean path they had been using to reach business data through Claude. The connector flow now expected each employee to authenticate individually, and none of them had Supabase accounts.
I had two obvious answers. I could expand direct access to the production system, or I could take a roughly $7,000-per-year access path back to the client. The $7,000 figure was the team’s quoted decision input, not a public Supabase price benchmark. Neither answer matched the actual requirement.
The requirement was narrower: keep Supabase as the writable source of truth, but give approved employees and Claude a governed way to read the business data they needed.
That distinction led to a private AWS read layer estimated at $38–$45 per month. It also led me through a logical-replication design that worked in disposable tests and failed in the managed production path.
The database was not the thing I needed to replace
Supabase was still doing its real job. It held the operational data, supported the application, and remained connected to automations that were already working. Rebuilding that write system would have increased the scope without solving the access problem any better.
The issue was the boundary around it.
Anthropic’s connector model is built around per-user permissions: on Team and Enterprise plans, each person normally authenticates individually, and Claude inherits that person’s source-system access. That is a sensible default because enabling a connector does not silently grant elevated access. In this case, though, it exposed a mismatch. The employees who needed information through Claude were not supposed to become operators inside the production Supabase environment.
I initially looked at temporary admin access and an existing n8n agent path. Both could make data reachable, but neither gave me the identity, revocation, and least-privilege model I wanted to carry forward.
So I stopped calling the project a migration.
Supabase would keep all writes, editing, operational workflows, and existing application responsibilities. AWS would receive only an approved read projection. Claude would never receive generic SQL access. It would receive a small set of business actions over curated data.
That was the first useful decision: protect the working system instead of replacing it.
The elegant replication path failed at the network boundary
Native PostgreSQL logical replication was the cleanest design on paper. I built the publication, tested the full 41-table shape locally, and watched inserts, updates, and deletes move through disposable PostgreSQL environments.
Then I tried the managed production path.
The AWS database could not reach the IPv6 address exposed by Supabase’s direct database endpoint. That was the failure—not “managed infrastructure got complicated” or “the integration was unreliable.”
I spent longer on that design than I should have because it was architecturally satisfying. Continuous replication looked better on the diagram, and it had already passed locally. But a design that works only where the network is easy is not a production design.
I retired the publication, failed subscription, and inactive slot rather than preserving a half-working path. The replacement was less elegant and more controllable: a guarded snapshot worker running every 15 minutes.
This is the same kind of lesson I ran into while writing about the hidden cost of self-hosting AI: the front door can look healthy while the important system behind it has failed. Infrastructure has to be graded on the path that actually runs, not the component that looks good in isolation.
A 15-minute snapshot produced stronger evidence
The snapshot worker reads only explicitly approved tables and columns. It moves the data in deterministic 200-row primary-key chunks, loads isolated staging tables, validates counts, and promotes all 41 tables in one transaction. If a run fails, the previously published replica remains untouched.
That operational model gave me something logical replication had stopped giving me: a failure I could explain and recover from.
At the July 23 acceptance check, the initial load copied 30,756 rows across 41 approved tables with zero count mismatches. The scheduled follow-up reached 30,758 rows, proving that newer rows moved through the automated path. The two vector datasets contained 2,430 document embeddings and 252 approved-copy embeddings at 1,536 dimensions.
Those are historical acceptance measurements, not permanent “current” totals. The source database continued changing after that check. Their value is that they prove the system reconciled at a defined moment.
I also kept query execution and search relevance as separate acceptance gates. Correct dimensions and successful cosine queries proved that the vector plumbing worked. They did not prove that every returned result was useful. Synthetic ranking scores were never promoted into claims about production relevance.
The final authorization suite passed 27 out of 27 tests. Deployed response checks showed a normal user receiving the five data tools while the owner also received the access-management tools. That proved the policy boundary at the deployed service level.
It did not, by itself, prove that a non-owner employee completed the full interactive Claude sign-in. I am keeping that as a separate human acceptance check instead of quietly turning an infrastructure test into a user claim.
The boundary cost more than the database
The deployed AWS shape was estimated at $38–$45 per month. That estimate excluded the existing Supabase and Claude subscriptions and any Supabase egress created by repeated snapshots.
The surprising line was not compute.
A small RDS PostgreSQL instance was estimated at about $11.68 per month, with roughly $2.30 for storage. Three private interface-endpoint attachments came to approximately $21.90 per month—nearly twice the database compute charge. Authentication, monitoring, secrets, and synchronization infrastructure made up the remaining estimate.
The expensive part of secure private AI access was the boundary plumbing.
That matters because “$40 per month instead of $7,000 per year” is an attractive headline and an incomplete comparison. The $7,000 figure came from the team’s planning constraint. The AWS number was an architecture estimate based on the deployed shape, not a guaranteed bill. They describe the decision honestly only when those limitations stay attached.
The useful AI system exposed less, not more
The final employee-facing surface contained five tools:
list_clientsget_clientget_client_guidelinessearch_documentssearch_approved_copy
None exposed generic SQL. Each tool mapped to a bounded business question, queried curated views, enforced input limits, and returned only the approved shape.
That is the part I would carry into the next project. Connecting a model to a database is easy compared with deciding what the model should be allowed to discover, retrieve, and never touch.
AI compressed the implementation and verification loop. It helped me compare designs, build Terraform and Lambda scaffolding, run tests, trace a deployed interceptor timeout, and expand the authorization suite from 25 tests to 27. It did not decide which data was approved, whether the risk was acceptable, or when production evidence had disproved the elegant design.
I wrote about that distinction in the Claude Skill that supports my blog workflow: workflow logic can accelerate repeatable work, but it does not remove responsibility for the result.
The safest version of this system came from exposing less. Keep the operational database where it works. Copy only approved reads. Put business tools in front of them. And when production disproves the prettier design, ship the one you can validate and recover.
FAQ
Did this replace Supabase?
No. Supabase remained the writable operational system. AWS became a private 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, test, audit, and explain than an open query surface.
Why use snapshots instead of logical replication?
Logical replication passed locally, but the AWS database could not reach Supabase’s direct database endpoint in the managed path. The snapshot worker traded immediacy for deterministic validation and recovery.
Is the AWS layer really $38–$45 per month?
That was the estimate for the deployed shape at the time. It excluded existing Claude and Supabase subscriptions and possible Supabase egress, so it should not be read as a guaranteed all-in bill.
Was the final employee experience tested?
The deployed authorization suite passed 27/27 tests, including normal-user and owner tool-discovery behavior. A separate non-owner human Claude sign-in still needs explicit confirmation before I describe that experience as completed.
- * *
