SQLite path or Postgres URL is required

createDatabase switches on config.type and validates the field that backend needs before constructing an adapter.

The two forms

SQLite path is required for SQLite database
Postgres connection URL is required for Postgres database

Same shape, different backend. You selected a database type and did not supply the one piece of information that type requires.

What causes it

Type set, connection unset. A config that specifies type: 'postgres' while the environment variable holding the URL is empty or missing.

An empty string rather than undefined. Worth calling out because it is the version people lose time to: a variable set to "" is present but falsy, and looks correct in a config dump. Every check here is truthiness, so blank fails exactly like absent — but a dump shows the key existing, which reads as configured.

Wrong variable name. The value is set under a name nothing reads.

How to fix it

Supply the connection detail for the backend you chose. For local development that is a SQLite file path; for the hosted platform it is a Postgres URL.

If you are on Postgres and using a pooler, the port matters more than it looks — a transaction-mode pooler does not support prepared statements, so the client must disable them. That is a different failure and a much more confusing one: intermittent "prepared statement already exists" errors under concurrency rather than a clean startup refusal.

This check runs at construction for the same reason the HTTP adapter validates its URL there — a configuration problem should stop a process from starting, not wait to surface under load.

A note on where this is validated

The check sits inside the switch on config.type, so each backend validates only what it needs. That looks like a small detail and it prevents a common alternative: a single up-front check requiring both a SQLite path and a Postgres URL regardless of which one is in use.

Per-branch validation means the error names the field the chosen backend actually requires, rather than listing every field any backend might want.