Fresh install gives Server could not be contacted because of old pgadmin4.db

[cschot]

Describe the bug
After a fresh install it tool a long time for pgadmin to try to start. Than I got the infamous Server could not be contacted error.
I read this could be because of old files in the Appdata folder.
So I checked %appdata%\pgAdmin. (Note that this is not the pgadmin4 folder)
There was an old pgadmin4.db file from 2019.
When I deleted that, the app could be started.

Error messages
In the GUI: Server could not be contacted

In the log file(whole file below):
ERROR pgadmin: Database migration failed
(....)
sqlalchemy.exc.NoSuchTableError: user_old

Expected behavior
I expect 4 changes:

1. A successful database migration for old databases
2. An error message in the GUI that makes sense
   • Server could not be contacted -> Database migration failed
3. Easier troubleshooting
   • A link in the fatal error gui to the logs
   • Report the database path in the logs
   • A link in the fata error gui to a troubleshooting webpage with common error fixes
4. Easier bug reporting
   • A button in the fatal error gui to create an github issue with

Desktop (please complete the following information):

• OS: Windows 11 26100.8246
• pgAdmin version: 9.15
• Mode: Desktop

Additional context

Log

2026-05-24 16:45:32,290: ERROR	pgadmin:	Database migration failed
2026-05-24 16:45:32,313: ERROR	pgadmin:	Traceback (most recent call last):
  File "D:\Program Files\pgAdmin 4\web\pgadmin\__init__.py", line 390, in upgrade_db
    db_upgrade(app)
    ~~~~~~~~~~^^^^^
  File "D:\Program Files\pgAdmin 4\web\pgadmin\setup\db_upgrade.py", line 25, in db_upgrade
    flask_migrate.upgrade(migration_folder)
    ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\flask_migrate\__init__.py", line 111, in wrapped
    f(*args, **kwargs)
    ~^^^^^^^^^^^^^^^^^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\flask_migrate\__init__.py", line 200, in upgrade
    command.upgrade(config, revision, sql=sql, tag=tag)
    ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\alembic\command.py", line 483, in upgrade
    script.run_env()
    ~~~~~~~~~~~~~~^^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\alembic\script\base.py", line 545, in run_env
    util.load_python_file(self.dir, "env.py")
    ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\alembic\util\pyfiles.py", line 116, in load_python_file
    module = load_module_py(module_id, path)
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\alembic\util\pyfiles.py", line 136, in load_module_py
    spec.loader.exec_module(module)  # type: ignore
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^
  File "", line 1023, in exec_module
  File "", line 488, in _call_with_frames_removed
  File "D:\Program Files\pgAdmin 4\web\pgadmin\setup\..\..\migrations\env.py", line 95, in 
    run_migrations_online()
    ~~~~~~~~~~~~~~~~~~~~~^^
  File "D:\Program Files\pgAdmin 4\web\pgadmin\setup\..\..\migrations\env.py", line 87, in run_migrations_online
    context.run_migrations()
    ~~~~~~~~~~~~~~~~~~~~~~^^
  File "", line 8, in run_migrations
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\alembic\runtime\environment.py", line 969, in run_migrations
    self.get_context().run_migrations(**kw)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\alembic\runtime\migration.py", line 626, in run_migrations
    step.migration_fn(**kw)
    ~~~~~~~~~~~~~~~~~^^^^^^
  File "D:\Program Files\pgAdmin 4\web\migrations\versions\aff1436e3c8c_.py", line 32, in upgrade
    meta.reflect(op.get_bind(), only=('server',))
    ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\sql\schema.py", line 5903, in reflect
    Table(name, self, **reflect_opts)
    ~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "", line 2, in __new__
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\util\deprecations.py", line 281, in warned
    return fn(*args, **kwargs)  # type: ignore[no-any-return]
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\sql\schema.py", line 429, in __new__
    return cls._new(*args, **kw)
           ~~~~~~~~^^^^^^^^^^^^^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\sql\schema.py", line 483, in _new
    with util.safe_reraise():
         ~~~~~~~~~~~~~~~~~^^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\util\langhelpers.py", line 121, in __exit__
    raise exc_value.with_traceback(exc_tb)
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\sql\schema.py", line 479, in _new
    table.__init__(name, metadata, *args, _no_init=False, **kw)  # type: ignore[misc] # noqa: E501
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\sql\schema.py", line 861, in __init__
    self._autoload(
    ~~~~~~~~~~~~~~^
        metadata,
        ^^^^^^^^^
    ...<4 lines>...
        resolve_fks=resolve_fks,
        ^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\sql\schema.py", line 893, in _autoload
    conn_insp.reflect_table(
    ~~~~~~~~~~~~~~~~~~~~~~~^
        self,
        ^^^^^
    ...<4 lines>...
        _reflect_info=_reflect_info,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\engine\reflection.py", line 1580, in reflect_table
    self._reflect_fk(
    ~~~~~~~~~~~~~~~~^
        _reflect_info,
        ^^^^^^^^^^^^^^
    ...<7 lines>...
        reflection_options,
        ^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\engine\reflection.py", line 1781, in _reflect_fk
    sa_schema.Table(
    ~~~~~~~~~~~~~~~^
        referred_table,
        ^^^^^^^^^^^^^^^
    ...<5 lines>...
        **reflection_options,
        ^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "", line 2, in __new__
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\util\deprecations.py", line 281, in warned
    return fn(*args, **kwargs)  # type: ignore[no-any-return]
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\sql\schema.py", line 429, in __new__
    return cls._new(*args, **kw)
           ~~~~~~~~^^^^^^^^^^^^^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\sql\schema.py", line 483, in _new
    with util.safe_reraise():
         ~~~~~~~~~~~~~~~~~^^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\util\langhelpers.py", line 121, in __exit__
    raise exc_value.with_traceback(exc_tb)
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\sql\schema.py", line 479, in _new
    table.__init__(name, metadata, *args, _no_init=False, **kw)  # type: ignore[misc] # noqa: E501
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\sql\schema.py", line 861, in __init__
    self._autoload(
    ~~~~~~~~~~~~~~^
        metadata,
        ^^^^^^^^^
    ...<4 lines>...
        resolve_fks=resolve_fks,
        ^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\sql\schema.py", line 893, in _autoload
    conn_insp.reflect_table(
    ~~~~~~~~~~~~~~~~~~~~~~~^
        self,
        ^^^^^
    ...<4 lines>...
        _reflect_info=_reflect_info,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\engine\reflection.py", line 1580, in reflect_table
    self._reflect_fk(
    ~~~~~~~~~~~~~~~~^
        _reflect_info,
        ^^^^^^^^^^^^^^
    ...<7 lines>...
        reflection_options,
        ^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\engine\reflection.py", line 1781, in _reflect_fk
    sa_schema.Table(
    ~~~~~~~~~~~~~~~^
        referred_table,
        ^^^^^^^^^^^^^^^
    ...<5 lines>...
        **reflection_options,
        ^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "", line 2, in __new__
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\util\deprecations.py", line 281, in warned
    return fn(*args, **kwargs)  # type: ignore[no-any-return]
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\sql\schema.py", line 429, in __new__
    return cls._new(*args, **kw)
           ~~~~~~~~^^^^^^^^^^^^^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\sql\schema.py", line 483, in _new
    with util.safe_reraise():
         ~~~~~~~~~~~~~~~~~^^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\util\langhelpers.py", line 121, in __exit__
    raise exc_value.with_traceback(exc_tb)
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\sql\schema.py", line 479, in _new
    table.__init__(name, metadata, *args, _no_init=False, **kw)  # type: ignore[misc] # noqa: E501
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\sql\schema.py", line 861, in __init__
    self._autoload(
    ~~~~~~~~~~~~~~^
        metadata,
        ^^^^^^^^^
    ...<4 lines>...
        resolve_fks=resolve_fks,
        ^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\sql\schema.py", line 893, in _autoload
    conn_insp.reflect_table(
    ~~~~~~~~~~~~~~~~~~~~~~~^
        self,
        ^^^^^
    ...<4 lines>...
        _reflect_info=_reflect_info,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "D:\Program Files\pgAdmin 4\python\Lib\site-packages\sqlalchemy\engine\reflection.py", line 1548, in reflect_table
    raise exc.NoSuchTableError(table_name)
sqlalchemy.exc.NoSuchTableError: user_old

[asheshv]

Hi @cschot — thanks for the detailed report and for taking the time to dig out the actual cause. Your detective work on finding the stale pgadmin4.db in %appdata%\pgAdmin is exactly what made this diagnosable. There are two pull requests up that address the parts of this fixable in code right now, and notes on the bigger UX ideas below.

What was actually going wrong, in plain terms

PgAdmin stores its own settings (registered servers, your saved preferences, etc.) in a little local database file. On Windows that's usually somewhere under %appdata%\pgAdmin. Old versions of pgAdmin from many years ago used a slightly different folder name (pgAdmin instead of pgAdmin4) — and your machine had a leftover database file from a 2019 install sitting in the old folder. When you installed pgAdmin 9.15, it found that old file and tried to upgrade it to the current format.

The upgrade ran a step from October 2019 that asks the database, "tell me about the server table you have." The database faithfully reports back, "the server table references something called user_old..." — but user_old was a temporary table that got removed in a later cleanup migration that your DB never completed. So pgAdmin asks for details about user_old, the database says "never heard of it", and the whole upgrade aborts with the cryptic error you saw in the log. The desktop GUI then surfaces the generic "Server could not be contacted" message, which isn't really what happened — but it's how the GUI is wired up right now.

Deleting that 2019 file (as you did) bypassed the upgrade entirely by giving pgAdmin a clean slate to write to.

What I've put up to fix this

Two PRs, intentionally separated so review and revert are easier:

#10011 — Fix the actual upgrade crash

The 2019 upgrade step (and 13 other similar steps) ask the database to describe a table and follow all its foreign-key references by default. The follow-the-references part is what trips on user_old. None of the upgrade steps actually need the referenced tables — they only update data on the table they asked about — so the fix tells the database to skip the cascade. Tested empirically against both a stale-FK SQLite database (your scenario) and against PostgreSQL (the other configuration option). Both work cleanly.

After this merges, future pgAdmin upgrades won't trip on leftover databases with stale references — they'll just complete the upgrade and start normally.

#10012 — Make the log actually tell you which database file failed

When the upgrade does crash (for any reason, not just yours), the log will now say something like:

Database migration failed (SQLite config DB at: C:\Users\<you>\AppData\Roaming\pgAdmin\pgadmin4.db)

— so the next person hitting any kind of upgrade failure can immediately see which file to look at, without going on a %appdata% treasure hunt the way you had to. (And if they have an external Postgres setup, the URI is logged with the password masked out.)

The two bigger UX ideas

You asked for two more things, which I think are very fair but didn't bundle into these PRs because they're meaningfully larger work:

• "Server could not be contacted" → "Database migration failed" in the GUI: this means changing the desktop wrapper to distinguish between "the migration crashed during startup" and "the running pgAdmin server isn't responding" — currently both end up in the same dialog. Real fix, worth doing, but it lives in different code (the Electron desktop side and the Python startup-error handling) and warrants its own focused PR.
• A button in the error dialog to create a GitHub issue: also a great idea, but it's a feature, not a bug fix — and there are some real product decisions involved (auto-attaching the traceback raises privacy concerns; encoding the right amount of context in a URL has limits; etc.). Probably better tracked as its own feature request so it gets the discussion it deserves.

I'd suggest separate issues for those two; happy to file them if you'd like, or you can.

Workaround right now

What you already did (deleting the stale 2019 pgadmin4.db) is the correct workaround — nothing more graceful is available until #10011 merges. The file lives at %appdata%\pgAdmin\pgadmin4.db (note the missing 4 in the folder name — that's the giveaway it's the leftover from before pgAdmin renamed its data directory).

Sorry for the rough first impression of v9.15; it was a real bug. Hope this helps clarify what was happening.

[dpage]

This was fixed and is included in pgAdmin 4 9.16 (via commit 303f6a2). The fix is listed in the 9.16 release notes; the auto-close keyword on the merged PR didn't fire, so closing manually. Please reopen if you still see it on 9.16+.