You can take it
and go.

Take your database

Connect as postgres, the role that owns your database, with the connection string from the Console, and run:

pg_dump --no-owner --no-privileges "$DATABASE_URL" > koedodb-export.sql

This is an ordinary pg_dump. It takes the whole database: your tables, your row level security policies, your functions, and Auth’s tables with your users (auth.users, auth.identities, and the rest).

Put it somewhere else

Restore it with psql into any PostgreSQL 18:

psql "$TARGET_URL" -f koedodb-export.sql

If your policies name the API roles, those roles have to exist where you restore. On a plain PostgreSQL, create them first:

CREATE ROLE anon NOLOGIN;
CREATE ROLE authenticated NOLOGIN;
CREATE ROLE service_role NOLOGIN BYPASSRLS;

We test this: a dump taken as above is restored into a stock PostgreSQL 18, and the only thing that stopped it was the role anon, which that PostgreSQL did not have. What you restore into, and how, is up to you: the target has its own PostgreSQL version and its own setup (Supabase, for one, already has an auth schema of its own).

What comes with it, and what changes

Comes with it: your data, your schema, your policies, and your users with their stored password hashes, because KoedoDB runs upstream Supabase Auth.

Changes: the API keys and the signing keys belong to your project on KoedoDB. After you move, you set the keys and URLs of the new place in your app, and people who are signed in have to sign in again.

Nothing of ours in it: KoedoDB adds no triggers, functions or schemas of its own to your database, so the dump holds only what you made.

Your code

Your functions and your static site are your own files. Keep them in your own Git repository, as you would anywhere.