Self-Hosted 2.0.0 bugs & infos

When testing 2.0.0 here is what i found

Bugs

• New console does not allow to create new orgs (multi-org visible, but the create button is missing)

Others infos

• In 2.0.0 VectorsDB/DocumentsDB are not visible in the UI, it is intended and will be released in a later version once it's more stable. So i would recommend disabling embedding as well to free up some resources while thoses DBs are disabled.
• When using S3, and when in the executor DSN you use the url= param, you should remove the bucket name from the URL. The executor now reuse the one saved in the database path. (e.g. s3://{{ $accessKey }}:{{ $secret }}@localhost/?region={{ $region }}&url={{ $endpoint }} instead of s3://{{ $accessKey }}:{{ $secret }}@localhost/{{ $bucket }}?region={{ $region }}&url={{ $endpoint }})
• When upgrading the instance from 1.9.6, in addition of the migrate command you also need to run the usage-setup command. Else the usage won't work and throw error 503.

Workarounds

Create org from API

# Login
curl -sS -c cookies.txt -X POST 'https://YOUR_HOST/v1/account/sessions/email' \
  -H 'Content-Type: application/json' \
  -H 'X-Appwrite-Project: console' \
  -d '{"email":"YOUR_EMAIL","password":"YOUR_PASSWORD"}'

# Create org
curl -sS -b cookies.txt -X POST 'https://YOUR_HOST/v1/teams' \
  -H 'Content-Type: application/json' \
  -H 'X-Appwrite-Project: console' \
  -d '{"teamId":"unique()","name":"My Organization"}'

Official fixes

(none at the moment)

What and how i tested

I tested a deployment on 2.0.0 with primary maria or psql databases (primary mongo was tested in 1.9 and connection method didn't change). Also tested migration from 1.9.6 to 2.0.0, tested S3 support and finally tested to make a script to migrate primary maria to psql. (the db migration script will be available in this thread, and in my helm chart repo in the #channel thread once it's done)

For each of the above scenario :

• i created a user
• a database, table and row
• created a storage bucket, and a file, with a check of the preview
• created a function (starter node) and tested to execute it with /ping
• created a site and checked if the screenshot worked

-# I will update this message if i find more bugs or others people find some so we have kinda of a mega thread to resolve all issues in self hosted

The script basicly read your maria tables, map the tables to psql (with types changes from a read deployed psql instance for verification), then move the data.

The process to change the primary DB would be :

• Spin up a PostgreSQL alongside your MariaDB
• Setup your PostgreSQL
• Shutdown Appwrite
• Run the migration
• Change the envs to use PostgresSQL as the pirmary DB
• Start appwrite again
• ONLY IF EVERYTHING IS GOOD (you have all your data and and you can continue doing your stuff), you can now remove MariaDB - tho i would still recommend keeping at least the volume for a week just in case

# requirements
pip install pymysql psycopg2-binary

# run
MARIA_HOST=127.0.0.1 MARIA_PORT=13306 MARIA_USER=user MARIA_PASSWORD=password MARIA_DB=appwrite \
PG_HOST=127.0.0.1 PG_PORT=15432 PG_USER=user PG_PASSWORD=password PG_DB=appwrite \
python3 maria-to-postgres.py --drop-schema

# --drop-schema wipes the PG target appwrite schema first, not needed.

Regarding the databases stats empty, only in the database grid view, here is the AI summary of the issue :

What’s going on

• The project Usage → Databases page sums databases.operations.reads/writes for the whole project → you see numbers.
• The databases list cards call the same metrics filtered with resourceId = <databaseId>.

In ClickHouse right now:

So the list query finds nothing → empty sparkline.

Why
Row/document handlers do:

$usage
    ->setResource('database')
    ->setResourceInternalId((string) $database->getSequence())
    ->addMetric(...);  // resourceId left empty

They never call setResourceId($database->getId()). On request shutdown, empty resourceId is filled with the project id (fillMissingResource('project', ...) in general.php). Still broken on main the same way.

Gauges (tables/rows/storage from stats-resources) correctly use the database id — only the operations events used by the list cards are wrong.

Nothing to fix in the chart for this. Fix belongs in Appwrite: set setResourceId($database->getId()) (and ideally setResourcePath(...)) wherever DB ops are recorded.