Úvod
Každá skutečná Next.js aplikace dříve nebo později narazí na moment, kdy potřebuje databázi. E-shop, SaaS platforma, blog s adminem – bez spolehlivé databázové vrstvy se prostě neobejdete. A právě tady přichází na řadu ORM nástroje, díky kterým můžete s databází pracovat typově bezpečně přímo z TypeScriptu.
V roce 2026 se v Next.js ekosystému jasně vyprofilovaly dva hlavní hráči: Prisma a Drizzle ORM. Oba řeší ten samý problém – jak propojit vaši aplikaci s relační databází. Přistupují k němu ale fundamentálně jinak. Prisma vsází na vlastní schémovací jazyk a vysokou úroveň abstrakce. Drizzle naopak zrcadlí SQL syntaxi přímo v TypeScriptu a drží se co nejblíž databázi.
Tak pojďme na to. V tomhle průvodci si oba nástroje projdeme prakticky – nastavíme je v Next.js 16 s App Routerem, napíšeme CRUD operace v Server Components i Server Actions a porovnáme je z hlediska výkonu, velikosti balíčku, DX i edge kompatibility. Na konci budete vědět, který z nich se hodí pro váš konkrétní projekt.
Prisma 7: Co je nového a jak začít
Prisma 7, vydaná koncem roku 2025, přinesla asi nejzásadnější architektonickou změnu v historii tohoto ORM. Celý Rust engine, který dříve běžel jako samostatný proces vedle vaší Node.js aplikace, je pryč. Úplně. Prisma 7 je teď čistě TypeScriptová a query compiler běží jako WebAssembly modul přímo na hlavním vlákně JavaScriptu.
Co to znamená v praxi? Menší balíček, žádné binárky ke stahování při instalaci a lepší kompatibilita s moderními JavaScript runtime prostředími.
Ale pozor – je tu jedna zásadní změna, na kterou se připravte: driver adaptery jsou teď povinné. Nemůžete jen tak vytvořit instanci PrismaClient a jet. Musíte explicitně poskytnout databázový driver. Upřímně, ze začátku mě to trochu překvapilo, ale dává to smysl – máte plnou kontrolu nad tím, jak se aplikace připojuje k databázi.
Instalace a nastavení Prisma 7 v Next.js 16
Začneme instalací potřebných balíčků. Pro PostgreSQL (nejčastější volba pro Next.js aplikace) potřebujete:
npm install @prisma/client @prisma/adapter-pg pg
npm install -D prisma @types/pg
Inicializujte Prisma v projektu:
npx prisma init
Prisma 7 vytvoří dva důležité soubory. Prvním je klasický schema.prisma, ale s jednou zásadní změnou – blok datasource už neobsahuje URL databáze. Ta se přesunula do nového konfiguračního souboru prisma.config.ts:
// prisma.config.ts
import path from "node:path";
import type { PrismaConfig } from "prisma";
export default {
earlyAccess: true,
schema: path.join(__dirname, "prisma/schema.prisma"),
} satisfies PrismaConfig;
A samotné schéma vypadá takto:
// prisma/schema.prisma
generator client {
provider = "prisma-client"
output = "../app/generated/prisma"
}
datasource db {
provider = "postgresql"
}
model User {
id Int @id @default(autoincrement())
email String @unique
name String?
posts Post[]
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
}
model Post {
id Int @id @default(autoincrement())
title String
content String?
published Boolean @default(false)
author User @relation(fields: [authorId], references: [id])
authorId Int
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
}
Všimněte si dvou věcí: provider v generátoru musí být "prisma-client" (ne starší "prisma-client-js") a doporučuje se nastavit vlastní výstupní cestu přes output. Tohle je drobnost, ale ušetří vám to bolesti hlavy později.
Singleton pattern – prevence vyčerpání connection poolu
Tohle je naprosto klíčové. Vážně.
Při vývoji Next.js hot-reloaduje změněné soubory, a bez singleton patternu by každý reload vytvořil novou instanci PrismaClient s vlastním connection poolem. Po pár úpravách vám databáze odmítne další připojení a vy budete zírat na chybovou hlášku a přemýšlet, co se stalo.
// lib/prisma.ts
import { PrismaClient } from "@/app/generated/prisma/client";
import { PrismaPg } from "@prisma/adapter-pg";
const globalForPrisma = globalThis as unknown as {
prisma: PrismaClient;
};
function createPrismaClient() {
const adapter = new PrismaPg({
connectionString: process.env.DATABASE_URL,
});
return new PrismaClient({ adapter });
}
const prisma = globalForPrisma.prisma || createPrismaClient();
if (process.env.NODE_ENV !== "production") {
globalForPrisma.prisma = prisma;
}
export default prisma;
Tenhle soubor zajistí, že v celé aplikaci existuje jen jedna instance PrismaClient. V produkci se vytvoří nová instance, v development režimu se uloží do globálního objektu a při hot-reloadu se znovu použije. Jednoduchý trik, ale bez něj se neobejdete.
Migrace a generování klienta
Po definici schématu spusťte migrace a vygenerujte klienta:
npx prisma migrate dev --name init
npx prisma generate
Prisma vytvoří migrační SQL soubory ve složce prisma/migrations/ a vygeneruje typově bezpečného klienta do vámi určené výstupní složky. Nic složitého.
Drizzle ORM: SQL-first přístup v TypeScriptu
Drizzle ORM zastává úplně jinou filozofii: „Pokud znáte SQL, znáte Drizzle." Žádný vlastní schémovací jazyk, žádný generační krok, žádný runtime overhead. Vaše schéma je čistý TypeScript, dotazy vypadají jako SQL a návratové typy se automaticky inferují.
A je extrémně lehký – celý balíček má kolem 7,4 kB. Pro srovnání, Prisma 7 je i po odstranění Rust engine výrazně větší. Na serverless platformách jako Vercel Functions nebo AWS Lambda to znamená znatelně rychlejší studené starty. A to je něco, co vaši uživatelé ocení.
Instalace a nastavení Drizzle v Next.js 16
Instalace je příjemně přímočará:
npm install drizzle-orm pg
npm install -D drizzle-kit @types/pg
Vytvořte konfigurační soubor drizzle.config.ts v kořenu projektu:
// drizzle.config.ts
import { defineConfig } from "drizzle-kit";
export default defineConfig({
schema: "./src/db/schema.ts",
out: "./drizzle",
dialect: "postgresql",
dbCredentials: {
url: process.env.DATABASE_URL!,
},
});
Definice schématu v TypeScriptu
Tady je ten klíčový rozdíl oproti Prisma. Schéma definujete přímo v TypeScriptu pomocí funkcí z Drizzle – žádný vlastní DSL, žádný generátor:
// src/db/schema.ts
import {
pgTable,
serial,
text,
boolean,
integer,
timestamp,
} from "drizzle-orm/pg-core";
import { relations } from "drizzle-orm";
export const users = pgTable("users", {
id: serial("id").primaryKey(),
email: text("email").notNull().unique(),
name: text("name"),
createdAt: timestamp("created_at").defaultNow().notNull(),
updatedAt: timestamp("updated_at")
.defaultNow()
.notNull()
.$onUpdate(() => new Date()),
});
export const posts = pgTable("posts", {
id: serial("id").primaryKey(),
title: text("title").notNull(),
content: text("content"),
published: boolean("published").default(false).notNull(),
authorId: integer("author_id")
.notNull()
.references(() => users.id),
createdAt: timestamp("created_at").defaultNow().notNull(),
updatedAt: timestamp("updated_at")
.defaultNow()
.notNull()
.$onUpdate(() => new Date()),
});
export const usersRelations = relations(users, ({ many }) => ({
posts: many(posts),
}));
export const postsRelations = relations(posts, ({ one }) => ({
author: one(users, {
fields: [posts.authorId],
references: [users.id],
}),
}));
Všimněte si, že relace definujete odděleně od tabulek pomocí funkce relations(). Je to explicitnější než Prismino automatické odvození relací – musíte přesně říct, jaké vztahy mezi tabulkami existují. Některým to přijde ukecané, ale já osobně oceňuju tu transparentnost. Přesně víte, co se děje.
Připojení k databázi
Vytvoření databázové instance je o něco jednodušší než u Prisma:
// src/db/index.ts
import { drizzle } from "drizzle-orm/node-postgres";
import { Pool } from "pg";
import * as schema from "./schema";
const globalForDb = globalThis as unknown as {
pool: Pool;
};
const pool =
globalForDb.pool ||
new Pool({
connectionString: process.env.DATABASE_URL,
});
if (process.env.NODE_ENV !== "production") {
globalForDb.pool = pool;
}
export const db = drizzle(pool, { schema });
I u Drizzle je důležité použít singleton pattern pro connection pool. Stejný problém jako u Prisma – hot-reload a vyčerpání spojení. Nezapomínejte na to.
Migrace
Drizzle Kit generuje SQL migrační soubory z vašeho TypeScript schématu:
npx drizzle-kit generate
npx drizzle-kit migrate
Migrační soubory najdete ve složce drizzle/. Na rozdíl od Prisma jsou to čisté SQL soubory, které můžete snadno upravit před spuštěním. Malá, ale důležitá rada: vždy používejte strict: true v konfiguraci drizzle-kit. Bez něj může Drizzle interpretovat přejmenování sloupce jako smazání a vytvoření nového – a tím přijdete o data. Stalo se to nejednomu vývojáři.
CRUD operace v Server Components
Next.js 16 s App Routerem vám umožňuje volat databázové dotazy přímo v Server Components. Žádná API vrstva, žádný fetch. Komponenta běží na serveru, takže má přímý přístup k databázi. Pojďme se podívat, jak vypadají stejné operace v obou ORM.
Čtení dat – Prisma
// app/posts/page.tsx (Server Component)
import prisma from "@/lib/prisma";
export default async function PostsPage() {
const posts = await prisma.post.findMany({
where: { published: true },
include: { author: true },
orderBy: { createdAt: "desc" },
take: 10,
});
return (
<div>
<h1>Publikované články</h1>
{posts.map((post) => (
<article key={post.id}>
<h2>{post.title}</h2>
<p>Autor: {post.author.name}</p>
<p>{post.content}</p>
</article>
))}
</div>
);
}
Čtení dat – Drizzle
// app/posts/page.tsx (Server Component)
import { db } from "@/src/db";
import { posts, users } from "@/src/db/schema";
import { eq, desc } from "drizzle-orm";
export default async function PostsPage() {
const allPosts = await db.query.posts.findMany({
where: eq(posts.published, true),
with: { author: true },
orderBy: [desc(posts.createdAt)],
limit: 10,
});
return (
<div>
<h1>Publikované články</h1>
{allPosts.map((post) => (
<article key={post.id}>
<h2>{post.title}</h2>
<p>Autor: {post.author.name}</p>
<p>{post.content}</p>
</article>
))}
</div>
);
}
Na první pohled vypadají oba přístupy dost podobně. Prisma používá objekt s vlastnostmi jako where, include, orderBy. Drizzle nabízí relační query API (db.query), které je syntakticky blízké, ale podmínky se píší pomocí funkcí jako eq(), gt(), like(). Pokud jste zvyklí psát SQL, Drizzle vám bude připadat přirozenější.
Alternativní Drizzle syntax – select builder
Drizzle nabízí i SQL-like select builder pro složitější dotazy, a tohle je podle mě jedna z jeho největších výhod:
const result = await db
.select({
id: posts.id,
title: posts.title,
authorName: users.name,
})
.from(posts)
.innerJoin(users, eq(posts.authorId, users.id))
.where(eq(posts.published, true))
.orderBy(desc(posts.createdAt))
.limit(10);
Tenhle přístup se víc podobá psaní surového SQL a dává vám plnou kontrolu nad tím, jaké sloupce se vrací. U Prisma byste pro ekvivalentní výstup museli použít select parametr, což funguje, ale není to tak elegantní.
Mutace přes Server Actions
Pokud jste si přečetli náš průvodce Server Actions, víte, že mutace dat v Next.js 16 probíhají přes funkce s direktivou "use server". Obě ORM se s nimi integrují naprosto hladce.
Vytvoření záznamu – Prisma
// app/actions/posts.ts
"use server";
import { revalidatePath } from "next/cache";
import prisma from "@/lib/prisma";
import { z } from "zod";
const CreatePostSchema = z.object({
title: z.string().min(1, "Název je povinný").max(200),
content: z.string().optional(),
authorId: z.coerce.number().int().positive(),
});
export async function createPost(formData: FormData) {
const parsed = CreatePostSchema.safeParse({
title: formData.get("title"),
content: formData.get("content"),
authorId: formData.get("authorId"),
});
if (!parsed.success) {
return { error: parsed.error.flatten().fieldErrors };
}
await prisma.post.create({
data: {
title: parsed.data.title,
content: parsed.data.content,
authorId: parsed.data.authorId,
},
});
revalidatePath("/posts");
}
Vytvoření záznamu – Drizzle
// app/actions/posts.ts
"use server";
import { revalidatePath } from "next/cache";
import { db } from "@/src/db";
import { posts } from "@/src/db/schema";
import { z } from "zod";
const CreatePostSchema = z.object({
title: z.string().min(1, "Název je povinný").max(200),
content: z.string().optional(),
authorId: z.coerce.number().int().positive(),
});
export async function createPost(formData: FormData) {
const parsed = CreatePostSchema.safeParse({
title: formData.get("title"),
content: formData.get("content"),
authorId: formData.get("authorId"),
});
if (!parsed.success) {
return { error: parsed.error.flatten().fieldErrors };
}
await db.insert(posts).values({
title: parsed.data.title,
content: parsed.data.content ?? null,
authorId: parsed.data.authorId,
});
revalidatePath("/posts");
}
Aktualizace a mazání
U aktualizace a mazání je syntaktický rozdíl výraznější, tak se na to pojďme podívat:
// Prisma – aktualizace
await prisma.post.update({
where: { id: postId },
data: { title: "Nový název", published: true },
});
// Drizzle – aktualizace
await db
.update(posts)
.set({ title: "Nový název", published: true })
.where(eq(posts.id, postId));
// Prisma – smazání
await prisma.post.delete({
where: { id: postId },
});
// Drizzle – smazání
await db.delete(posts).where(eq(posts.id, postId));
Vidíte ten rozdíl? Drizzle syntaxe je prakticky 1:1 s SQL příkazy UPDATE ... SET ... WHERE a DELETE FROM ... WHERE. Prisma používá objektový přístup, který je abstraktnější. Pro vývojáře zvyklé na SQL bude Drizzle přirozenější. Pro ty, kdo preferují OOP styl, bude pohodlnější Prisma. Ani jeden přístup není objektivně lepší – záleží na vašich preferencích a zkušenostech týmu.
Výkon a velikost balíčku: Praktické srovnání
Výkonnostní debata mezi Prisma a Drizzle se s příchodem Prisma 7 hodně změnila. Pojďme se podívat na konkrétní čísla.
Velikost balíčku
Drizzle ORM má velikost kolem 7,4 kB. To je opravdu málo. Prisma 7, i po odstranění Rust engine, je výrazně větší kvůli WebAssembly query compileru a generovanému klientovi. Na serverless platformách se tento rozdíl reálně projevuje při studených startech – Drizzle aplikace prostě naběhnou rychleji.
Runtime výkon
Drizzle generuje SQL stringy přímo, bez mezivrstvy. Prisma 7 query compiler (ten WebAssembly modul) provádí transformaci z Prisma query API do SQL, což přidává minimální, ale měřitelný overhead.
Upřímně řečeno – u většiny aplikací tenhle rozdíl nepoznáte. Samotné vykonání databázového dotazu trvá řádově déle než transformace v ORM vrstvě. Ale pokud provádíte stovky dotazů za sekundu, každá milisekunda se počítá.
Typová kontrola
Tady je to zajímavé. Prisma používá generování kódu – typy se předpočítají při prisma generate a editor je pouze načte. Drizzle spoléhá na typovou inferenci v reálném čase. Výsledek? Podle benchmarků Prisma vyžaduje řádově stovky typových instanciací, zatímco Drizzle může vyžadovat desítky tisíc.
Typová kontrola s Prisma je tak přibližně 2–3× rychlejší. U velkých projektů s desítkami tabulek to reálně pocítíte ve VS Code (pomalejší autocomplete, vyšší spotřeba paměti TypeScript serveru).
Edge Runtime kompatibilita
Tady Drizzle jasně vede. Díky minimální velikosti a absenci externích binárních závislostí Drizzle funguje nativně na edge runtime – Vercel Edge Functions, Cloudflare Workers, Deno Deploy. Bez problémů.
Prisma 7 na edge runtime nepodporuje přímé připojení k databázi. Musíte použít Prisma Accelerate – placenou proxy službu, která funguje jako prostředník mezi vaší edge funkcí a databází. Funguje to dobře, ale je to další závislost a další náklady.
Pokud plánujete nasazení na edge, Drizzle je v tuhle chvíli jednoznačná volba. Pokud používáte standardní Node.js runtime na Vercelu, výkonnostní rozdíl bude minimální.
Integrace s Cache Components a use cache
Next.js 16 přináší direktivu "use cache" pro explicitní cachování (podrobnosti najdete v našem průvodci Cache Components). Obě ORM s ní fungují bez problémů, ale pár specifik je dobré znát.
Cachování databázových dotazů
// app/posts/page.tsx
import { cacheLife } from "next/cache";
export default async function PostsPage() {
"use cache";
cacheLife("hours");
// Tento dotaz se provede pouze jednou a výsledek se cachuje
const posts = await prisma.post.findMany({
where: { published: true },
orderBy: { createdAt: "desc" },
});
return (
<ul>
{posts.map((post) => (
<li key={post.id}>{post.title}</li>
))}
</ul>
);
}
Funguje to identicky s Drizzle – prostě nahradíte Prisma dotaz Drizzle dotazem a je to. Direktiva "use cache" cachuje celý výstup komponenty, takže databázový dotaz se provede jen při prvním renderování nebo po invalidaci cache.
Pozor na Prisma 7 a NowGenerator
Starší verze Prisma 7 měly nepříjemný problém s Cache Components – synchronní volání new Date() při inicializaci generovalo chybu „dynamic usage" uvnitř cachovaných komponent. Dost frustrující bug. Naštěstí byl opraven ve verzi Prisma 7.6, která udělala NowGenerator líným. Pokud používáte starší verzi, aktualizujte co nejdřív.
Kdy zvolit Prisma a kdy Drizzle
Po tom, co jsme si oba nástroje prošli prakticky, pojďme se podívat na rozhodovací kritéria. Protože správná odpověď na otázku „Prisma nebo Drizzle?" je (jako vždycky) – záleží na kontextu.
Zvolte Prisma, když:
- Váš tým nemá hluboké znalosti SQL – Prisma abstrakce je přístupnější, obzvlášť pro juniorní vývojáře
- Potřebujete Prisma Studio – vizuální GUI pro prohlížení a editaci dat je při vývoji obrovská výhoda
- Pracujete s více typy databází – Prisma nativně podporuje PostgreSQL, MySQL, SQLite, MongoDB, CockroachDB i SQL Server
- Chcete kompletní ekosystém – Prisma Accelerate (connection pooling a caching), Prisma Pulse (real-time events) a další služby
- Rychlost typové kontroly je priorita – u velkých schémat je Prisma výrazně rychlejší v IDE
Zvolte Drizzle, když:
- Tým dobře zná SQL – Drizzle syntax je prakticky 1:1 mapování SQL příkazů
- Nasazujete na edge runtime – Vercel Edge Functions, Cloudflare Workers, bez nutnosti placených proxy služeb
- Minimální bundle size je klíčový – 7,4 kB vs. výrazně více u Prisma
- Chcete plnou kontrolu nad generovaným SQL – žádná abstrakce mezi vámi a databází
- Používáte serverless databáze – Drizzle má vynikající podporu pro Neon, Turso, PlanetScale a Cloudflare D1
Rozhodovací tabulka
Pro rychlé rozhodnutí:
- Startup s malým týmem a PostgreSQL na Vercelu → Drizzle (menší overhead, rychlejší cold starty)
- Enterprise aplikace s velkým týmem → Prisma (lepší DX pro smíšený tým, robustnější ekosystém)
- Edge-first aplikace → Drizzle (nativní edge podpora bez proxy)
- Rychlý prototyp → Prisma (Prisma Studio + intuitivní API zrychlí iteraci)
- Projekt s komplexními SQL dotazy → Drizzle (SQL-first přístup, žádné obcházení ORM u složitých queries)
Kompletní příklad: API pro správu článků
Na závěr si ukážeme kompletní příklad – jednoduchou aplikaci pro správu článků s oběma ORM. Server Components pro zobrazení, Server Actions pro mutace. Nic zbytečného navíc.
Verze s Prisma
// app/blog/page.tsx (Server Component)
import prisma from "@/lib/prisma";
import { Suspense } from "react";
import { CreatePostForm } from "./create-post-form";
async function PostList() {
const posts = await prisma.post.findMany({
include: { author: { select: { name: true } } },
orderBy: { createdAt: "desc" },
});
return (
<ul>
{posts.map((post) => (
<li key={post.id}>
<h3>{post.title}</h3>
<span>{post.author.name}</span>
<time>{post.createdAt.toLocaleDateString("cs-CZ")}</time>
</li>
))}
</ul>
);
}
export default function BlogPage() {
return (
<main>
<h1>Blog</h1>
<CreatePostForm />
<Suspense fallback={<p>Načítání článků...</p>}>
<PostList />
</Suspense>
</main>
);
}
Verze s Drizzle
// app/blog/page.tsx (Server Component)
import { db } from "@/src/db";
import { posts } from "@/src/db/schema";
import { desc } from "drizzle-orm";
import { Suspense } from "react";
import { CreatePostForm } from "./create-post-form";
async function PostList() {
const allPosts = await db.query.posts.findMany({
with: { author: { columns: { name: true } } },
orderBy: [desc(posts.createdAt)],
});
return (
<ul>
{allPosts.map((post) => (
<li key={post.id}>
<h3>{post.title}</h3>
<span>{post.author.name}</span>
<time>{post.createdAt.toLocaleDateString("cs-CZ")}</time>
</li>
))}
</ul>
);
}
export default function BlogPage() {
return (
<main>
<h1>Blog</h1>
<CreatePostForm />
<Suspense fallback={<p>Načítání článků...</p>}>
<PostList />
</Suspense>
</main>
);
}
Oba přístupy jsou funkčně ekvivalentní. Rozdíl je v syntaxi dotazů a ve filozofii – Prisma skrývá komplexitu za intuitivní API, Drizzle ji vystavuje s plnou typovou bezpečností. Obě varianty perfektně spolupracují se Server Components, Server Actions i Cache Components v Next.js 16. Vyberte si tu, která víc sedí vašemu týmu.
Často kladené otázky
Je Drizzle ORM dostatečně zralý pro produkční nasazení?
Rozhodně ano. Drizzle ORM je v roce 2026 plně produkčně připravený. Používají ho tisíce projektů včetně produkčních aplikací na Vercelu. Ekosystém je sice menší než u Prisma, ale základní funkce – dotazy, migrace, typová bezpečnost – jsou stabilní a spolehlivé.
Mohu migrovat z Prisma na Drizzle (nebo naopak) v existujícím projektu?
Ano, ale počítejte s tím, že to chce trochu úsilí. Databázové schéma zůstane stejné – mění se jenom ORM vrstva v kódu. Prisma nabízí oficiálního průvodce migrací z Drizzle. Opačným směrem je migrace pracnější, protože musíte ručně přepsat schéma z Prisma SDL do TypeScriptu. Doporučuju migrovat postupně, modul po modulu – nepokoušejte se to udělat celé najednou.
Jak řešit connection pooling na Vercelu?
Pro obě ORM doporučuju použít externího poskytovatele databáze s integrovaným connection poolingem – třeba Neon, Supabase nebo PlanetScale. Prisma navíc nabízí Prisma Accelerate jako placenou proxy službu. Na Vercelu serverless funkce nemají perzistentní spojení, takže connection pooling na straně databáze je pro výkon naprosto zásadní.
Podporuje Prisma 7 stále MongoDB?
Podpora MongoDB v Prisma 7 je omezená. Tým Prisma pracuje na nativní MongoDB integraci v rámci projektu Prisma Next, který by měl přinést věci jako agregace a šifrování na úrovni polí. Pokud stavíte MongoDB projekt, zatím spíš zvažte Mongoose nebo přímo MongoDB driver.
Který ORM je lepší pro TypedSQL a raw SQL dotazy?
Drizzle je navržen pro SQL-first přístup, takže raw SQL je přirozenou součástí jeho API. Prisma 7 ale přinesla TypedSQL – funkci, která validuje vaše raw SQL dotazy při buildu a vrací typované výsledky. Takže oba nástroje raw SQL zvládají dobře. Rozdíl je v tom, že u Drizzle je to základní filozofie, zatímco u Prisma spíš doplňková funkce.