7. Future Considerations
7.1 Future Considerations
The following considerations apply to the evolution of the query layer after the Prisma-to-Kysely migration is completed:
| Consideration | Recommendation | Rationale |
|---|---|---|
| Full Prisma Client removal | SHOULD | After all tenant SQL endpoints are migrated and validated, the TenantPrismaClient dependency, PrismaManager client cache, and Prisma Engine binary SHOULD be removed to eliminate dead code and reduce footprint |
| ATS-main database migration | MAY | The AtsPrismaClient for the ATS-main database MAY be evaluated for Kysely migration in a separate RFC if similar overhead is observed |
| Kysely type generation pipeline | SHOULD | A build-time type generation step SHOULD be formalized to derive Kysely database interface types from the Prisma schema or database introspection, preventing schema drift |
| Shared query composition utilities | SHOULD | Common query patterns (pagination, dynamic filtering, sorting, tenant scoping) SHOULD be extracted into shared utilities within @pnats/schema-manager to reduce per-module duplication |
| Connection pool monitoring | SHOULD | The shared pg.Pool SHOULD expose metrics (active connections, idle connections, wait queue depth) for observability and capacity planning |
| Prisma Migrate replacement | MAY | If Prisma Migrate's dependency on the Prisma schema becomes a maintenance burden after query-layer migration, an alternative migration tool MAY be evaluated in a separate RFC |
| MongoDB client evaluation | MAY | MongoDB Prisma clients are unaffected by this RFC; a separate evaluation MAY determine whether alternative MongoDB drivers provide similar benefits |
| Performance regression testing | SHOULD | Automated performance benchmarks SHOULD be integrated into the CI pipeline to detect query-layer regressions as endpoints are migrated |