Bridge is a different design: Python expression layer over a Rust execution engine. This gives it a different performance profile and security model compared to pure-Python ORMs. The trade-off is a smaller ecosystem and fewer third-party extensions.
No. Bridge is async-only. All database operations require an async context (asyncio event loop). This is by design — the Rust engine runs on tokio, and blocking calls would defeat the purpose.
Yes. Use bridge reflect --url <URL> --table <TABLE_NAME> to introspect a table and generate a model class definition. You can then use that model directly.
Yes. connect() initializes a connection pool managed by the Rust engine (PoolManager). Sessions borrow connections from the pool. Pool configuration is handled internally — you get a pool per database URL.
Sessions always run within a transaction. transaction() creates a session, begins a transaction, and commits or rolls back on context exit. You can also create sessions explicitly with begin_session().
Bridge does not auto-flush on every mutation. Unflushed changes are held in the identity map's dirty tracker and are lost on crash. Only committed data is durable. For partial safety, call session.flush() at checkpoints.
Not yet. Relations assume single-column foreign keys. Composite foreign keys are tracked as a known limitation.
Yes. fetch_lazy() returns an AsyncIterator that yields model instances one at a time without loading the full result set into memory. This is suitable for large datasets.
The identity map is scoped per asyncio.Task. Different tasks within the same session have separate identity maps. This prevents memory leaks from long-lived tasks.
PostgreSQL, SQLite, MySQL, MariaDB, Oracle, MS SQL Server, CockroachDB, PlanetScale, Neon, YugabyteDB, Cloudflare D1, and Dolt.
See contributing.md.