Teldrive 1.6.x to 1.8.x Upgrade Struggles (Oracle PostgreSQL)

Spent the whole day wrestling with the Teldrive 1.8.3 update. I struggled heavily with DB migration errors, but finally fixed them via manual SQL patches with AI's help! I even updated the VPS, and search times plummeted from tens of seconds to just a few, vastly speeding up Everything indexing as well. After a lot of trial and error, the performance upgrade is a success! 😎

Trusting AI and Taking the Plunge!

It's already been well over two years since I started using Teldrive as my unlimited cloud storage. Recently, something seemed off with Everything—my go-to universal search tool on Windows—so I needed to re-index my entire Teldrive mounted via Rclone. The sheer volume of data was one thing, but the indexing speed was absolutely abysmal. That's when a thought crossed my mind!

'Would updating Teldrive speed up the indexing process?'

Considering the latest version is 1.8.3, the 1.6.3 version I’ve been using is practically an expired, obsolete build. However, in the IT world, there's a rather conservative golden rule: "If it ain't broke, don't fix it." Just like how I often put off Windows updates. I was hesitant because I had experienced a massive headache during a previous Teldrive update when tweaking the DB went terribly wrong. But now, I have a reliable AI assistant by my side. Since AI analysis suggested that updating to 1.8.3 would improve indexing and search speeds, I finally took the plunge.

Hold on! Backing up your DB before updating is an absolute must!!!

💡 Useful related posts

• 「Free Snapshot Backup Tool for Teldrive and PikPak Users(Korean)」

• 「Using Telegram as Unlimited Cloud Storage | Telegram Drive(Korean)」

• 「View other Teldrive-related posts(Korean)」

The First Hurdle: No Primary Key in the `users` Table

I had braced myself, but sure enough, I ran into an issue with the DB migration.

2026-07-28 13:19:34 ✗ ERROR [APP] failed to migrate database error=ERROR 20251007120000_kv.sql: failed to run SQL migration: failed to execute SQL query "CREATE TEMP TABLE bots_temp AS\nSELECT DISTINCT ON (user_id, token)\n user_id,\n token,\n bot_id\nFROM\n teldrive.bots\nORDER BY\n user_id, token, bot_id;\nDROP TABLE teldrive.bots;\nCREATE TABLE teldrive.bots (\n\tuser_id int8 NOT NULL,\n\ttoken text NOT NULL,\n\tbot_id int8 NOT NULL,\n\tCONSTRAINT bots_pkey PRIMARY KEY (user_id, token),\n\tCONSTRAINT bots_user_id_fkey FOREIGN KEY (user_id) REFERENCES teldrive.users(user_id)\n);\nINSERT INTO teldrive.bots (user_id, token, bot_id)\nSELECT user_id, token, bot_id FROM bots_temp;\nCREATE TABLE IF NOT EXISTS teldrive.kv (\n key text PRIMARY KEY,\n value BYTEA NOT NULL,\n created_at TIMESTAMP DEFAULT timezone('utc'::text, now()) NOT NULL\n);": ERROR: there is no unique constraint matching given keys for referenced table "users" (SQLSTATE 42830)

Versions up to 1.6.19 ran without a hitch, and the exact same issue occurred when trying to run version 1.7.0.

According to AI, this error isn't fatal enough to make you abandon the update, but it stems from subtle differences in the database structure. Decoding the error message: Teldrive 1.8.3 tries to reference the `user_id` column in the `users` table (Foreign Key) while creating a new `bots` table. However, it fails because there is no unique constraint on the `user_id` column in the current database's `users` table.

In my opinion, this is purely a Teldrive bug. The system should automatically handle migrating an older DB to the new format, but instead, it forces the user to do it manually.

The fix is to execute the following SQL queries in order using a DB management tool like pgAdmin or DBeaver (courtesy of Gemini 3.1 Pro).

DELETE FROM teldrive.users a USING teldrive.users b

WHERE a.ctid < b.ctid AND a.user_id = b.user_id;
ALTER TABLE teldrive.users ADD PRIMARY KEY (user_id);

The Second Hurdle: Upload Failures

After a few twists and turns—like the root folder mysteriously vanishing—it seemed like the 1.8.3 update was smoothly wrapping up thanks to that fix. However, while downloading and video playback worked perfectly, I couldn't upload any files. The key part of the error code looked like this:

error=ERROR: there is no unique or exclusion constraint matching the ON CONFLICT specification (SQLSTATE 42P10)

ERROR [API] request.failed error=ERROR: there is no unique or exclusion constraint matching the ON CONFLICT specification (SQLSTATE 42P10)

According to AI, this error occurs because a necessary Unique Constraint is missing from the database. It seems that versions 1.7.0 and later use an `ON CONFLICT` clause during file uploads to update existing files with the same name, or add them if they don't exist. For this to work correctly, a Unique Constraint tying together three columns—`(name, parent_id, user_id)`—must be defined in the `files` table. The 1.6.x database was missing this constraint, causing the upload error. Running the following SQL queries in order resolves this (courtesy of DeepSeek).

SELECT
name,
COALESCE(parent_id, '00000000-0000-0000-0000-000000000000'::uuid) as parent_id,
user_id,
COUNT(*)
FROM teldrive.files
GROUP BY name, COALESCE(parent_id, '00000000-0000-0000-0000-000000000000'::uuid), user_id
HAVING COUNT(*) > 1;

CREATE UNIQUE INDEX CONCURRENTLY unique_file_active
ON teldrive.files (name, COALESCE(parent_id, '00000000-0000-0000-0000-000000000000'::uuid), user_id)
WHERE status = 'active';

ALTER INDEX unique_file_active RENAME TO unique_file;

The Third Hurdle: Upload Issues Not Fully Resolved

Uploads worked after applying that, but the following error still persisted in the logs.

error=ERROR: there is no unique or exclusion constraint matching the ON CONFLICT specification (SQLSTATE 42P10)

The `files` table was fixed, but the `kv` table was also missing the same constraint (uniqueness for the KEY). The `kv` table is crucial for Teldrive, as it stores session info, temporary settings, and other Key-Value data. You could technically upload files while ignoring this error for now, but it’s a must-fix issue because it could cause major headaches later with maintaining logins, renewing bot sessions, and saving settings.

You can fix this error by executing these queries in order (DeepSeek).

Check for duplicate key values. If your DB is clean, nothing will be outputted.

SELECT key, COUNT(*) FROM teldrive.kv GROUP BY key HAVING COUNT(*) > 1;

ALTER TABLE teldrive.kv ADD PRIMARY KEY (key);

The Fourth Hurdle: Channel Change Error

After fixing the upload problem, everything ran fine until I realized I couldn't change channels. I suppose this is the final boss of this epic troubleshooting journey.

For reference, a crucial note in the update logs from 1.6.3 to 1.8.3 is the feature that automatically rolls over to the next channel when a specific channel gets full (v1.7.0). While Telegram's official limit is roughly 1 million files per channel, people note that Teldrive starts noticeably slowing down when loading or syncing file lists once you pass the 700k–800k mark. Therefore, it's highly recommended to keep the number of files per channel strictly under 300,000.

See below for the channel change error log and its one-line fix (DeepSeek).

2026-07-30 11:44:39 ✗ ERROR [DB] db.query_failed duration_ms=12 rows_affected=0 sql=INSERT INTO "teldrive"."channels" ("channel_name","user_id","selected","created_at","channel_id") VALUES ('My_Cloud',1387486203,true,'
2026-07-30 02:44:39.278',2236746563) ON CONFLICT ("channel_id") DO UPDATE SET "selected"=true RETURNING "channel_id" error=ERROR: there is no unique or exclusion constraint matching the ON CONFLICT specification (SQLSTATE 42P10)
026-07-30 11:44:39 ✗ ERROR [API] request.failed error=failed to update channel

ALTER TABLE teldrive.channels ADD CONSTRAINT channels_channel_id_unique UNIQUE (channel_id);

Today's MVP: DeepSeek!

After completing the update, the search speed became noticeably faster—dropping from tens of seconds to what feels like just a few—and the Everything indexing speed improved right alongside it. So, I highly recommend that users on older versions make the jump. However, since you never know what unexpected hiccups might pop up, I strongly suggest doing it when you have plenty of time to spare.

Today, I brought along DeepSeek, GPT, and Gemini as my AI assistants for this 1.8.3 update, but the ones that actually provided real solutions were Gemini and DeepSeek. GPT didn't offer a fix; instead, it kept beating around the bush, claiming it needed more information, and mindlessly repeated the same things over and over. It was exactly like a person talking in circles to avoid taking responsibility before making a decision. I solved the first issue with Gemini's solution, but it gave me a completely wrong fix for the second issue (the upload problem), which unfortunately forced me to restore the DB entirely.

After cluttering up the DB with various SQL queries trying to fix the issues post-update, I wiped it completely clean with a fresh DB restore and applied DeepSeek's solutions in order. That perfectly resolved all the problems mentioned above.

Just like before, it seems DeepSeek is by far the best option for SQL DB issues if you're a free-tier user. Also, don't forget to utilize debugging outputs to troubleshoot by using Teldrive's log options, as shown below.

teldrive run --config config.toml --log-level debug --log-db-level debug --log-tg-enabled --log-tg-level debug

Summary: 1.6.3 vs 1.8.3 Comparison

Category	1.6.3	1.8.3
Session Storage	PostgreSQL only (High DB load)	Selectable: PostgreSQL / BoltDB / Memory (Low DB load)
File Integrity	Legacy Hash Method	BLAKE3 Tree Hashing (Faster & safer)
File List Retrieval	Full Scan Method	SSE + Pagination (Faster response time)
Data Consistency	Allows Duplicates	Blocks Duplicates (Unique Constraints)
Channel Management	Manual Channel Addition Required	Auto Channel Rollover (v1.7.0)
Supported Formats	Limited	Added HEIF, HEIC, WebP, xz, tgz