Fulltext index creation fails due to InnoDB row size limit

I'm running a self-hosted Appwrite 1.8.1 instance and encountering an issue when creating fulltext indexes on a collection.

The Problem:
Fulltext index creation fails with this error in appwrite-worker-databases logs:

MariaDB logs show:

Root Cause:
My collection has ~100 string attributes. With UTF8MB4 encoding, each VARCHAR(n) uses up to n * 4 bytes. The total row size exceeds InnoDB's 8,126 byte limit, so MariaDB cannot add the hidden FTS_DOC_ID column required for fulltext indexes.

My Workaround:
I manually converted several large VARCHAR columns to TEXT in MariaDB:

ALTER TABLE _14_database_2_collection_3
  MODIFY COLUMN psedescription TEXT,
  MODIFY COLUMN notes TEXT,
  -- ... etc

This reduced the row size below the limit and fulltext indexes now work. However:

• Editing these attributes in the Appwrite console reverts them to VARCHAR
• I need to avoid running migrations that might revert the changes

Questions for the team:

1. Is there a recommended way to handle collections with many string attributes that exceed the row size limit?
2. Would Appwrite consider using TEXT instead of VARCHAR for larger string attributes (e.g., size > 255)?
3. Is there a safe way to persist these column type changes so they survive attribute edits and migrations?
4. Any other recommendations for this use case?

Environment:

• Appwrite 1.8.1 (self-hosted)
• MariaDB 10.11
• Collection has ~100 attributes, mostly strings

Thanks for any guidance!

You can try executing

ALTER TABLE your_table_name ROW_FORMAT=DYNAMIC;

I'm not sure if Appwrite will reset the table, but you can give it a try.

The DYNAMIC row format automatically stores long strings in "overflow pages," retaining only a 20-byte pointer in the original row.

@user could you please advise?

this is what I used to solve the problem but I am not sure if it's the right way or if it will affect anything else:

docker exec appwrite-mariadb mysql -uroot -p'xxxxxxx' appwrite -e "
ALTER TABLE _14_database_4_collection_3 
  MODIFY COLUMN damage_description TEXT,
  MODIFY COLUMN psedescription TEXT,
  MODIFY COLUMN email_directions TEXT,
  MODIFY COLUMN notes TEXT,
  MODIFY COLUMN another_loss_location_on_policy TEXT,
  MODIFY COLUMN estimated_repair_cost TEXT,
  MODIFY COLUMN reportFileURL TEXT,
  MODIFY COLUMN additional_pse_1 TEXT,
  MODIFY COLUMN additional_pse_2 TEXT,
  MODIFY COLUMN additional_pse_3 TEXT,
  MODIFY COLUMN additional_pse_4 TEXT,
  MODIFY COLUMN remediation_company TEXT,
  MODIFY COLUMN secondary_location_of_loss TEXT,
  MODIFY COLUMN location_of_loss TEXT,
  MODIFY COLUMN leaked_overflowed TEXT,
  MODIFY COLUMN \`test-custom-peril\` TEXT,
  MODIFY COLUMN adjuster_name TEXT,
  MODIFY COLUMN insured_name TEXT,
  MODIFY COLUMN building_occupancy TEXT,
  MODIFY COLUMN building_occupied_by TEXT,
  MODIFY COLUMN company TEXT,
  MODIFY COLUMN pa_company TEXT,
  MODIFY COLUMN plumber_name TEXT,
  MODIFY COLUMN remediation_contact_name TEXT,
  MODIFY COLUMN building_purchase_date TEXT;
" 2>&1

after testing, the issue is not with the columns sizes, but with the number of columns