Integrations
Farming Labs ORM lets a package or app write its storage layer once, then run it through the actual database or ORM stack the app already owns.
That usually means:
- define one schema with
@farming-labs/orm - generate app-facing artifacts when a stack wants them
- run the unified query/runtime layer against the real client the app passes in
So instead of building one adapter for Prisma, another for Drizzle, another for Kysely, another for MongoDB, and another for Firestore, the package can keep one storage contract and let the runtime layer handle the translation.
If you want the exact support answer, use the Support Matrix. This page is the simpler overview.
Integration families
Generation-first SQL stacks
Use these when the app wants generated artifacts:
- Prisma generation
- Drizzle generation
- safe SQL generation
These are the right fit when the app already wants schema.prisma, generated
Drizzle tables, or plain SQL DDL files as part of its own workflow.
Runtime-first SQL and graph stacks
Use these when the app already owns a live relational client:
- Prisma
- Drizzle
- Kysely
- MikroORM
- TypeORM
- Sequelize
- EdgeDB / Gel
- Neo4j
- Cloudflare D1
- direct SQL clients
This is the path for package authors who want to accept a raw client and keep the higher-level storage logic unchanged.
PostgreSQL platforms
Hosted PostgreSQL platforms such as Supabase can fit through either the raw PostgreSQL layer or the direct Supabase JS client runtime.
That means the same schema can still power:
- generated Prisma / Drizzle / SQL output
- live ORM queries through a PostgreSQL client or a Supabase client
- setup helpers when the app chooses the PostgreSQL path
Document and key-value runtimes
Farming Labs ORM also supports document and key-value style runtimes when the app is not SQL-first:
- MongoDB
- Mongoose
- Cloudflare KV
- Redis / Upstash Redis
- Firestore
- DynamoDB
- Unstorage
These runtimes still keep the same schema and query API shape, but they rely more heavily on fallback relation loading and ORM-managed lookup behavior rather than native SQL joins.
Two important boundaries:
- Firestore, Cloudflare KV, Redis, and Unstorage do not have SQL-style schema push, so setup helpers are intentionally no-op there
- Unstorage is useful for lightweight records, sessions, tokens, and package-owned state, but it is not the recommended runtime for highly relational or join-heavy workloads
What “supported” means
When a runtime is supported here, the unified ORM API already translates into real calls for that stack.
Examples:
@farming-labs/orm-prismatranslates into Prisma delegate calls@farming-labs/orm-drizzletranslates into Drizzle-backed queries@farming-labs/orm-kyselytranslates into Kysely-backed queries@farming-labs/orm-mikroormtranslates into MikroORM-backed relational operations@farming-labs/orm-sqltranslates into direct SQL operations@farming-labs/orm-typeormtranslates into TypeORM-backed relational operations@farming-labs/orm-sequelizetranslates into Sequelize-backed relational operations@farming-labs/orm-edgedbtranslates into Gel SQL-backed relational operations@farming-labs/orm-neo4jtranslates into Neo4j-backed graph/document operations through the shared ORM surface@farming-labs/orm-d1translates into Cloudflare D1 binding operations@farming-labs/orm-kvtranslates into Cloudflare KV namespace operations@farming-labs/orm-redistranslates into Redis and Upstash-compatible key-value operations@farming-labs/orm-supabasetranslates into direct Supabase table API operations@farming-labs/orm-firestoretranslates into Firestore document operations@farming-labs/orm-dynamodbtranslates into DynamoDB document / key-value operations@farming-labs/orm-unstoragetranslates into Unstorage-backed key-value operations@farming-labs/orm-mongoand@farming-labs/orm-mongoosetranslate into MongoDB-oriented document operations
Guides
· · · · · · · · · · · · · · · ·How is this guide?