Introducing forge-sql-orm: Type-Safe ORM for @forge/sql Using Drizzle

Forge Forge Platform and Tools
, , ,
5

Hi Varun, thanks a lot for the kind words and support — it really means a lot!

I wasn’t affected by the Drizzle + Forge issue myself — I started using Drizzle when it was already resolved,
but it’s great to know the path is clearer for everyone else now.

Feedback from working with Forge SQL:

  1. Timeout-sensitive migrations
    If a migration contains many steps or involves heavier ALTER TABLE operations, there’s a risk of hitting Forge web/scheduler timeouts.
    This can lead to ALTER TABLE being successfully applied, but the corresponding insert into the migration log never completing — causing the next run to retry the same schema change and fail with an error like “column already exists.”
  2. Concurrent migration execution
    There’s currently no way to guarantee that only one migration process runs at a time.
    If multiple web triggers, event triggers, or scheduled tasks execute concurrently, they may all try to apply pending migrations — leading to race conditions or conflicting DDL operations.
    One potential direction could be support for SQL-level locking via GET_LOCK(...) / RELEASE_LOCK(...) (which TiDB supports),
    or perhaps another mechanism for coordinating safe execution — like using app.storage as a lightweight lock.

At the moment, these types of coordination issues (timeouts, concurrent execution) are left for developers to handle themselves at the application level.
It would be great to see Forge offer some built-in primitives or patterns for safe, idempotent orchestration across triggers and scheduler functions.

Thanks again for listening!

— Vasiliy