Limiting DML operations according to platform limits

[mdevils]

Hello @vzakharchenko!

First of all, thank you for this great library.

Before I go and work on a PR, I'd like to check if the ForgeSQL DML query / minute limits are respected by this library.

[vzakharchenko]

Hi! Thanks a lot for the kind words 🙂

Just to clarify — forge-sql-orm is a thin driver between Forge SQL and Drizzle ORM. It focuses mainly on:

• Strict TypeScript typings for your DB schema;
• A nice, type-safe query builder (via Drizzle);
• Auto-generated models and relations;
• A better developer experience when building Forge apps.

That means it doesn’t hide or bypass any Forge limits — so yeah, the per-minute DML/query limits from Forge SQL fully apply here too.

Since Drizzle is mostly a query builder, it’s up to developers to optimize queries and work within those limits. Batching (e.g. multi-row inserts) is supported, but there’s no built-in throttling or retry logic at the moment.

If you're thinking about contributing something in that area, feel free to open a discussion or draft PR — I’d love to explore it together!

[vzakharchenko]

By the way, just curious — do you have something specific in mind for enforcing DML limits?

Since each Forge resolver runs in complete isolation (like a separate Lambda), there's no shared memory or global state. And using @forge/api storage wouldn't really help either — it has its own rate limits and lacks atomic operations, so that could just shift the problem elsewhere.

Would love to hear how you're thinking of tackling that!

[mdevils]

I've previously faced rate limits of the KV storage of Forge

And at least in our case if was enough to limit request rate along with retry logic using a library like this (https://github.com/mdevils/capacity-limiter).

We mostly faced rate limiting in our Async Events. Maybe in forge-sql-orm it would be useful to catch rate limit errors and have a retry logic in those cases.