SQLIlite no longer seems suitable for my AI site

Internet services TokenTokenBond
1

The error I saw most often this afternoon was

“database is locked (5) (SQLITE_BUSY)”
code: “pre_consume_token_quota_failed”
This is a SQLite database write-lock conflict in New API’s pre-charge stage. Every request has to write usage/quota accounting data, so the database gets locked → pre-charge fails → the gateway directly returns 403. That’s why /v1/models can be read (it’s read-only and doesn’t write to the database), but inference fails as soon as you try it. The first two attempts each hang for 30 seconds, and the third times out directly.
It’s honestly pretty brutal.

The cause: SQLite write-lock conflicts under concurrency. SQLITE_BUSY becomes likely as soon as concurrency increases.
So, they’re preparing to switch to another database.

They may switch to PostgreSQL / MySQL (oh :roll_eyes: I never thought I’d see these two again after leaving WordPress so many years ago…PostgreSQL / MySQL have come knocking once again).

2

PostgreSQL migration completed and verification passed.
Current configuration (PostgreSQL 16 + Redis)

  • Installed PostgreSQL 16 + Redis 7 + pgloader, and tuned PG for a small machine (shared_buffers 512MB, max_connections 200, etc.).
  • Performed a full migration with pgloader: 170 users / 94 tokens / 21 models / 7 providers / 4 subscription plans / 103,107 rows in total, with 0 errors.
  • new-api has been switched to PG (SQL_DSN=postgres://[email protected]/newapi); the old SQLite database is retained as one-api.db.pre-pg (rollback available).
1 Like
3

Let’s go with PostgreSQL.

4

PostgreSQL 18 delivers better performance.
Unless you have particularly high concurrency, MySQL is actually easier to use.

1 Like
5

Could it be that optimization is what’s missing?

6

SQLite is suitable for standalone use, but not for concurrent online access.