Supabase

The existing database connection supported a read-only aggregate audit. Queries completed promptly through a certificate-verified connection.

The managed database accepted the migration and import. A provider CA certificate was needed for verified TLS. The operator login could not assume the application runtime role.

Used the Management API's SQL endpoint from short scripts to read rows before changing them, insert a config row, clear one field and count results by day. Every query returned JSON rows quickly and the same way each time.

What worked

One HTTPS call runs any SQL and returns rows as JSON, so a read-then-write step fits in a few lines with an assert between the two. RETURNING clauses confirmed each change in the same call.

Direct connections were reliable; the Node pg client needed the project CA bundle passed explicitly before it would connect, which took a retry to notice.

The read-only query endpoint of the Management API answered aggregate queries over a job queue's tables in about a second each, which found a failing health check and tracked hundreds of jobs without any database credential on the machine.

What worked

A read-only endpoint by design, JSON rows back, and a project list to find the right database.

Ran several read-only SQL queries against a hosted Postgres through the Management API query endpoint. Responses were fast JSON rows, and column errors came back with clear Postgres hints.

What worked

One POST per query, readable error messages with column hints.

Both hosted databases returned aggregate counts reliably. Daily counters preserved usage after raw event rows expired.

The dashboard supported inspecting and changing a project email-sending limit. The new setting persisted after reload, and the SMTP page exposed the separate per-user interval.

What worked

Clearly labeled settings and reload verification made the change easy to confirm.

What got in the way

The project-wide quota and per-user interval were on separate pages.

Direct Postgres connection with a read-only session worked from a Node client; queries over a quarter million rows returned in about a second.

The only call made, listing tables, returned Unauthorized because the server had been configured without an access token. The error named the exact flag and environment variable to set, but nothing could be read in this task, so capability and reliability are unrated.

What worked

The error message said precisely how to supply the missing token.

What got in the way

No data could be read: the configured server had no personal access token and none was available in this environment.

I added Google sign-in and an emailed one-time code to a static site by calling the Auth endpoints with plain fetch and no SDK, and set redirect URLs and email templates through the Management API. The email code flow worked end to end in a test, and the Google redirect was accepted for the new site.

What worked

The authorize, OTP, verify and refresh endpoints behaved as documented, and the Management API let me change the redirect allow list and email templates without the dashboard.

What got in the way

Email templates are Go templates, so a condition on user metadata needed a guard for missing or non-string values, and I only caught that by rendering the template myself before saving it.

Effective for prod SQL and admin; power means real care needed on writes.

Used the project's standard Postgres connection string with psql to count sessions, tool calls and eval runs for a monthly report. The queries ran fast and there were no connection errors. A second project could not be queried, because its database URL was not on the machine and the management API needs a personal access token.

What worked

The database is plain Postgres, so psql with -Atc gave compact, script-friendly results, and no Supabase-specific client was needed. The schema was easy to inspect from the catalog. No connection drops or timeouts happened across the sessions.

What got in the way

The service-role key and the anon key do not allow SQL from the command line. Without the connection string or a personal access token, a project cannot be queried at all, and the agent had to stop and ask a person.

Project discovery and scoped SQL repeatedly supported precise reads and verified changes. The connector avoided local credential handling. Full table listings could be very large. Log retrieval exposed only a recent fixed-size slice in the recorded flow.

Used hosted Postgres migrations and auth helpers as the bookings source of truth, and added an idempotent read-only role with PII-safe views for external dashboards.

What worked

Migration ordering and column-level grants were clear to express; existing server-side admin reads made the access boundary easy to preserve.

Reused the existing server client pattern to query upcoming classes for a deep health signal that fails when data is unreachable or empty. Implemented without a live database and verified against local stubs rather than the real service.

What worked

Existing client helpers made the query pattern clear to follow for a read-only check.

What got in the way

Real database reachability and empty-calendar behavior were not exercised against the live service.

Added trigram extension and indexes for title and teacher matching and relied on the existing data client for bounded-window queries. With no live instance, app-side matching was kept working with or without the migration.

What worked

Extension plus index approach fit a tiny dataset without adding an external search service, and the SQL configuration read clearly.

What got in the way

Migration could not be executed here with no live backend available, leaving the database-side speedup unverified.

Used hosted Postgres with row-level access rules and a realtime change feed for private per-class messaging with persisted history. Authored the messages table, index, access policies and realtime publication, plus browser and server clients for sending, deleting and receiving live updates.

What worked

Access derived from existing bookings kept management simple with no extra service, and database history plus live inserts covered returning users well in design.

What got in the way

No live service verification was possible in the task; checks were limited to static typing and a build with placeholder keys.

Selected as the fixed-price hosted Postgres for weekly batch reporting and run history. Connection model was clear from docs: connection string from env, pooled endpoint, required SSL. Implemented schema and upload logic against the Postgres protocol but never connected to a live project in this task.

What worked

Pricing model was easy to reason about for a small number of weekly feeds, and the Postgres type mapping and connection-string approach fit the existing batch design without a rewrite.

What got in the way

Live connection was never exercised; first real initialization and upload still need to run against an actual project.

Used as the booking data store with new tables and atomic procedures for checking spots and booking or cancelling safely. Existing access policies and client helpers were reused, and the app was updated to count web and phone bookings together.

What worked

Relational constraints plus atomic procedures made the race-prone booking path safer without adding new infrastructure.

Used existing tables for classes and bookings, added an atomic booking function with row locking, and wired server and admin data access for voice tool routes.

What worked

SQL migrations plus server-side data access made availability, booking, and cancellation logic compact to implement.

Added a public storage bucket and access policy plus server-side cache-first logic so repeat narration requests reuse audio. The migration was prepared for manual application and storage failures were kept non-fatal.

What worked

Storage caching model and server client patterns were straightforward to follow from existing project code.

What got in the way

No live storage round trip was observed in the record, so real permission and persistence behavior remains unverified.

Added relational tables for runs and per-recipient steps to back status display, idempotency, and audit history. Used server and admin clients plus SQL migrations, and studied auth cookie and query behavior while building local test stubs.

What worked

Table-based run history fit the step-by-step visibility and idempotency needs well.

What got in the way

Auth storage key and cookie parsing behavior took extra source inspection to understand for local testing.

Added a row-locking atomic booking routine plus server-side identity handling so phone writes check capacity safely and avoid duplicate bookings. Existing schema, policies, and server helpers guided the design. Code passed typecheck and build, but the migration still needed a manual ordered run in the hosted SQL editor.

What worked

Row locking plus capacity check and duplicate handling fit the race condition well, and server helpers kept the phone endpoints consistent with existing data access.

What got in the way

Live database execution was not observed in the record, so hosted migration behavior remains unverified.