Skip to content

PRISMA_EVALUATION

Jump to bottom
Jayson Knight edited this page Jan 13, 2026 · 1 revision

Prisma ORM Evaluation for NoSQL Storage Classes

Overview

This document evaluates whether the existing NoSQL storage classes in the adblock-compiler project should migrate to or adopt Prisma ORM as an alternative storage backend.

Prisma Supported Databases

Prisma is a next-generation ORM for Node.js and TypeScript that supports the following databases:

Relational Databases (SQL)

Database Status Notes
PostgreSQL Full Support Primary recommendation for production
MySQL Full Support Including MySQL 5.7+
MariaDB Full Support MySQL-compatible
SQLite Full Support Great for local development/embedded
SQL Server Full Support Microsoft SQL Server 2017+
CockroachDB Full Support Distributed SQL database

NoSQL Databases

Database Status Notes
MongoDB Full Support Special connector with some limitations

Cloud Database Integrations

Provider Status Notes
Supabase Supported PostgreSQL-based
PlanetScale Supported MySQL-compatible
Turso Supported SQLite edge database
Cloudflare D1 Supported SQLite at the edge
Neon Supported Serverless PostgreSQL

Upcoming Features (2025)

  • PostgreSQL extensions support (PGVector, Full-Text Search via ParadeDB)
  • Prisma 7 major release with modernized foundations

Current Implementation Analysis

Current Architecture: Deno KV

The project currently uses Deno KV as the NoSQL storage backend:

NoSqlStorage (Deno KV)
├── CachingDownloader
│   ├── ChangeDetector
│   └── SourceHealthMonitor
└── IncrementalCompiler (MemoryCacheStorage)

Key Characteristics:

  • Embedded key-value store
  • Zero external dependencies
  • Hierarchical keys: ['cache', 'filters', source]
  • Native TTL support
  • Type-safe generic operations

Storage Classes Summary

Class Purpose Complexity
NoSqlStorage Core KV operations Low
CachingDownloader Smart download caching Medium
ChangeDetector Track filter changes Low
SourceHealthMonitor Track source reliability Low
IncrementalCompiler Compilation caching Medium

Comparison: Deno KV vs Prisma

Feature Comparison

Feature Deno KV Prisma
Schema Definition None (schemaless) Prisma Schema Language
Type Safety Manual generics Generated types
Queries Simple KV ops Rich query API
Relations Manual First-class support
Migrations None needed Built-in migrations
TTL Support Native Application-level
Transactions Atomic operations Full ACID
Tooling Minimal Prisma Studio, CLI
Runtime Deno only Node.js, Deno, Bun
Infrastructure Zero Database server required

Pros and Cons

Deno KV (Current)

Pros:

  • Zero infrastructure overhead
  • Built into Deno runtime
  • Simple API for KV operations
  • Native TTL with automatic cleanup
  • Works offline/locally
  • No configuration needed
  • Fast for simple operations

Cons:

  • Deno-specific (not portable to Node.js)
  • Limited query capabilities
  • No relational features
  • Less mature ecosystem
  • No built-in tooling for data inspection
  • Manual type definitions

Prisma

Pros:

  • Type-safe auto-generated client
  • Rich query API with filters, pagination, sorting
  • Built-in migrations and schema management
  • Cross-runtime compatibility (Node.js, Deno, Bun)
  • Excellent tooling (Prisma Studio, CLI)
  • Supports both SQL and MongoDB
  • Active community and documentation
  • Production-ready for scaled deployments

Cons:

  • Requires external database server
  • Additional complexity and dependencies
  • MongoDB connector has fewer features than SQL
  • Learning curve for schema definition
  • Overkill for simple caching use cases
  • TTL must be implemented in application code

Use Case Analysis

Current Use Cases

Use Case Data Pattern Complexity Deno KV Fit Prisma Fit
Filter list caching Simple KV with TTL Low Excellent Overkill
Health monitoring Append-only metrics Low Good Good
Change detection Snapshot comparison Low Good Good
Compilation history Time-series queries Medium Good Better

When to Consider Prisma

Prisma would be beneficial if:

  1. Cross-runtime support needed - Project needs to run on Node.js
  2. Complex queries required - Filtering, aggregation, joins
  3. Multi-instance deployment - Shared database across workers
  4. Data relationships - Related entities need referential integrity
  5. Audit/compliance needs - Full transaction logs, ACID guarantees
  6. Team familiarity - Team already uses Prisma in other projects

When to Keep Deno KV

Deno KV remains the better choice when:

  1. Simplicity is paramount - Current use cases are simple KV
  2. Zero infrastructure - No external dependencies preferred
  3. Deno-only deployment - No need for Node.js compatibility
  4. Local/offline use - Application runs standalone
  5. Minimal maintenance - No database to manage

Recommendation

Summary

For the current project requirements, Deno KV is the appropriate choice.

The existing storage patterns (caching, health monitoring, change detection) are well-suited to a simple key-value model. Adding Prisma would introduce unnecessary complexity without significant benefits.

Hybrid Approach (Optional)

If future requirements demand more sophisticated storage, consider a hybrid approach:

┌─────────────────────────────────────────────────────┐
│                  IStorageAdapter                     │
├─────────────────────────────────────────────────────┤
│  + set<T>(key, value, ttl?)                         │
│  + get<T>(key): StorageEntry<T>                     │
│  + delete(key)                                       │
│  + list<T>(options): StorageEntry<T>[]              │
└─────────────────┬───────────────────────────────────┘
                  │
    ┌─────────────┼─────────────┐
    ▼             ▼             ▼
┌─────────┐ ┌──────────┐ ┌─────────────┐
│ DenoKv  │ │  Prisma  │ │ InMemory    │
│ Storage │ │ Storage  │ │ Storage     │
└─────────┘ └──────────┘ └─────────────┘

This allows switching storage backends based on deployment environment without changing application code.

Implementation Status

The project now includes:

  1. IStorageAdapter - Abstract interface for storage backends
  2. DenoKvStorageAdapter - Current implementation using Deno KV
  3. PrismaStorageAdapter - Optional Prisma-based implementation
  4. prisma/schema.prisma - Prisma schema (for SQLite/PostgreSQL/MongoDB)

Conclusion

Aspect Recommendation
Current Usage Keep Deno KV
Future Growth Add storage abstraction layer
Prisma for MongoDB Only if cross-runtime needed
Prisma for SQL Consider for analytics/reporting features

The storage abstraction layer has been added to enable future migration if requirements change, without affecting the existing codebase.

References

Clone this wiki locally