Without the Generator

Without the generator (manual config)

The client extension works without the generator — pass the config directly. A Prisma internal-API change therefore can't fully break you, and you can adopt the runtime helpers without running the generator.

const prisma = new PrismaClient({ adapter }).$extends(
  timescaledb({
    hypertables: [{ table: "SensorReading", column: "time", chunkInterval: "1 day" }],
  }),
);

On the manual-config path, create policies at runtime via $timescale (addRetentionPolicy, addCompressionPolicy, addContinuousAggregatePolicy, enableChunkSkipping, …) instead of annotations.

The SQL builders are also exported from prisma-extension-timescaledb/core for hand-written migrations: createExtensionSql, createHypertableSql, createContinuousAggregateSql, createRetentionPolicySql, createCompressionPolicySql, createChunkSkippingSql.

Renamed tables/columns (@@map / @map)

@@map (table) and @map (column) are fully supported. The generator reads the real database names from the DMMF and emits all SQL against them, while the runtime keeps accepting and returning Prisma field names — so nothing in your application code changes.

/// @timescale.hypertable(column: "time", chunkInterval: "1 day")
model SensorReading {
  time        DateTime @map("ts")
  deviceId    Int      @map("device_id")
  temperature Float

  @@id([deviceId, time])
  @@map("sensor_readings")
}

// You still write Prisma field names; the runtime maps them to ts / device_id:
await prisma.sensorReading.timeBucket({
  bucket: "1 hour",
  range: { start, end },
  where: { deviceId: 1 },
  groupBy: ["deviceId"],
  aggregate: { avgTemp: { avg: "temperature" } },
});

If you use the manual config (no generator), provide the DB names yourself:

timescaledb({
  hypertables: [{
    model: "SensorReading",                 // Prisma model name (drives prisma.sensorReading.*)
    table: "sensor_readings",               // @@map table
    column: "ts",                           // @map time column
    columns: { deviceId: "device_id" },     // Prisma field -> DB column (where/groupBy/aggregate)
  }],
});

Multiple schemas (@@schema)

Multi-schema is supported. Models annotated with @@schema("metrics") (with the multiSchema preview feature) have their hypertables and continuous aggregates created in, and queried from, the right schema — the generator and runtime schema-qualify every relation ("metrics"."sensor_readings"). No extra configuration beyond the standard Prisma multiSchema setup.