Turn a DATABASE_URL into config.

Database URLTry an example

This page reads it in your browser and sends nothing you paste anywhere.

Hide the password in the results below

What's in a database URL

A database URL holds a whole connection in one line, in the shape scheme://user:password@host:port/database?options. Hosts such as Railway, Heroku, Render, Supabase and Neon hand you one as DATABASE_URL. The scheme names the engine. postgres:// and postgresql:// are the same, mongodb+srv:// finds its servers through DNS, and rediss:// is Redis over TLS.

Most frameworks can read the URL as it is. Laravel reads it from DB_URL, Rails from DATABASE_URL, Prisma and node-postgres take it whole, and Django reads it through the dj-database-url package. Laravel, Django and Rails also take the parts one by one, and the converter writes those settings so you can see which value goes where.

Options after the ?, such as sslmode=require, carry over where the framework has a setting for them. Rails takes all of them. Django's OPTIONS takes the ones libpq or mysqlclient knows. node-postgres takes sslmode, application_name and options. Prisma keeps the whole URL. Laravel gets a line to add for sslmode. The converter names any option it leaves out.

Pooled and direct connections

Supabase lists four ways to connect to one database: direct, its shared pooler in session mode, the same pooler in transaction mode, and a dedicated pooler. Neon gives you two URLs, pooled and direct. A pooled URL shares a small set of server connections between many clients, which suits serverless functions that open a connection per request. A direct URL connects each client straight to Postgres, with no pooler between. In transaction mode a pooler hands the server connection back after every transaction, so a migration tool or pg_dump that expects one session from start to finish needs the direct URL. The converter names the mode when it recognises the host, and writes the direct URL for a Neon or Supabase transaction-mode pooled one. Supabase's direct host is IPv6 unless the project has the IPv4 add-on. From an IPv4-only network, use session mode on port 5432 of the pooler host instead.

Moving the database

The move commands dump the old database to a file and load it into the new one. They only name the variables DATABASE_URL and NEW_DATABASE_URL. To set the first, type read -rs DATABASE_URL; export DATABASE_URL, press Enter and paste the old URL. Then do the same for NEW_DATABASE_URL with the new one. For Postgres that's the new database's direct or session-mode URL, since pg_restore can't run through a transaction pooler. For a Neon or Supabase transaction-mode pooled URL the dump reads DIRECT_URL instead, and the converter shows the direct URL to paste into it. read -s doesn't echo what you paste, and the URL never appears in a command, so your shell history doesn't save it. The MySQL commands ask for the password instead, and the database you restore into must already exist. Put the new server's host, port and user in place of NEW_HOST, NEW_PORT and NEW_USER. mysqldump's --events needs the EVENT privilege, so if the dump stops with error 1044, grant it or drop --events. Dumped routines and events keep their DEFINER clauses, and restoring them on managed MySQL may need SUPER, SET_USER_ID, or SET_ANY_DEFINER on MySQL 8.2 and later. The app should stop writing while the dump runs, or the new copy misses whatever came in after it started. For Redis the converter writes a redis-cli --rdb snapshot command, and the Redis answer above covers a switch by replication. A Redis URL with a password and no user gets default as its user, because redis-cli 6 and 7 refuse the empty one.