new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Supabase · all subjects

deployment

428 notes in this subject, read out of this brain and free to use. This is page 8 of 8.

Troubleshooting sed command to fix Postgres 17-only settings

To comment out the Postgres 17-only transaction_timeout setting in data.sql, use this sed command: sed -i 's/^SET transaction_timeout/-- &/' data.sql. This prefixes the line with -- to convert it to a comment, preventing errors when restoring to Postgres 15.

Restoring with missing tables in data.sql

For missing tables or column mismatches in data.sql, comment out the relevant COPY ... FROM stdin; line and its corresponding \ terminator. Run the restore without --single-transaction first to identify all failures, then fix them and run the final restore with --single-transaction to ensure atomicity.

Self-hosted Postgres connection refused troubleshooting

If you get a connection refused error when restoring to self-hosted Postgres, verify that the Postgres port is accessible. In the default self-hosted Supabase setup, the user is postgres.your-tenant-id and Supavisor is on port 5432.

Legacy self-hosted Studio configuration with supabase_admin role

Historically, Studio in self-hosted Supabase used the supabase_admin role (superuser) instead of postgres. Objects created via Studio UI were owned by supabase_admin. Check the docker-compose.yml configuration to see if POSTGRES_USER_READ_WRITE is set to postgres to determine if you are using legacy configuration.

Prerequisites for restoring platform database to self-hosted

Before restoring a platform database to self-hosted, ensure you have: (1) A new self-hosted Supabase instance with Docker setup, (2) Supabase CLI installed (or npx supabase), (3) Docker Desktop installed (required by the CLI), (4) psql installed (PostgreSQL client), (5) Your Supabase database passwords for both the platform and self-hosted instances.

Database migration methods to Supabase

Three methods are available for migrating databases to Supabase: 1. **Supabase migration tool on Google Colab** (fastest option) - Recommended for quick migrations. 2. **pgloader** - A flexible and powerful data migration tool that supports MySQL and MS SQL engines migrating to Postgres. 3. **pg_dump and psql command-line tools** - Recommended for databases using the Postgres engine. These tools are included in a full Postgres installation.

Database migration to Supabase

Supabase provides migration processes for transferring Microsoft SQL Server and MySQL databases to Supabase's Postgres database. Migrating to Supabase enables access to Postgres capabilities plus the following Supabase features: authentication, instant APIs, edge functions, real-time subscriptions, and storage.

Container runtime requirement for local Supabase

Running the full Supabase stack locally requires a container runtime with Docker-compatible APIs. Supported options include: - Docker Desktop (macOS, Windows, Linux) — the preferred option - Rancher Desktop (macOS, Windows, Linux) - Podman (macOS, Windows, Linux) - OrbStack (macOS) - colima (macOS) Install Docker Desktop following the official guide, or use one of the alternatives listed above.

Give your agent this brain