You can easily change the source and recompile:

cd ~/src/sqlite  # or wherever your sqlite source tree is
make clean
sed -i -e 's/define PROMPT_LEN_MAX 20/define PROMPT_LEN_MAX 80/' src/shell.c.in 
make sqlite3

Then this works:

./sqlite3 /home/developer/var/mydatabase.sqlite
.prompt '/home/developer/var/mydatabase.sqlite> ' ' ..> '

If you are using Windows, one option is to make the database name the CLI's caption, thus:

.shell title I am using this.db

This is a manual process that would need to be repeaed everytime you .open another database in the same session.

The same "manual process" caveat applies to updating the prompt to show the filename.

Similar window title setting can be done with most Unix based terminal emulators as well. However, I suspect, that in all OSes, putting the window in full screen mode would likely hide such a title.

Anyway, I traced the origin of the 20-char limit as far back as 2002-04-18 with https://www.sqlite.org/src/info/e751338c468cdad7 (prior to that, they were inline hard-coded strings)

23 years later, is 20 chars still appropriate for an out-of-the-box experience, or can the default be made longer without requiring a local recompile?

or can the default be made longer without requiring a local recompile?

A recompile is necessary, because the prompt is in static memory, with a predefined size.

See the shell source

Sorry, that was meant as a question about updating that exact line of source to be longer out-of-box (thus, "without requiring a local recompile").

Of course, there is also always the option of replacing the use of static memory with allocated at startup (and reallocated if the user wants a longer prompt).

23 years later, is 20 chars still appropriate for an out-of-the-box experience, or can the default be made longer without requiring a local recompile?

FWIW, i've marked this thread in my inbox as to-revisit after the imminent 3.49.1 patch release is made. A quick test of extending that buffer to 128 bytes didn't reveal any weirdness (my initial concern was that it would interfere with the continuation marker, but it doesn't).

A very long prompt is probably going to want to include a newline at the end, else it gets awkward to have the input start at the mid-point of the console:

sqlite> .prompt '/home/stephan/f/s/lite/foo/bar/baz.db > '
/home/stephan/f/s/lite/foo/bar/baz.db > select
   ...> 1
   ...> from sqlite_schema
   ...> ;
/home/stephan/f/s/lite/foo/bar/baz.db > 

Awkward. Adding a newline would require that the .prompt command parse \n as a newline escape sequence.

Alternatively, we could move the continuation prompt appropriately far to the right, but that would possibly be even more awkward and would require a larger change than simply extending that buffer size does.

Adding a newline would require that the .prompt command parse \n as a newline escape sequence.

A workaround for this is to pass the newline in with the -cmd option. Example with the Bash shell:

sqlite3 -cmd '.prompt "sqlite
> "' example.db

23 years later, is 20 chars still appropriate for an out-of-the-box experience, or can the default be made longer without requiring a local recompile?

This is now set to 128 bytes in the current trunk. It would be interesting to make the size dynamic and to be able to handle escaped \n characters so that long prompts can end with one (see my previous response for why), but that would require a much more significant change. That hasn't been ruled out as an eventuality, but has been ruled out for today.