📊 Performance Benchmarks (2026-2027)

SveltyCMS delivers enterprise-grade performance through its database-agnostic architecture. For the complete set of verified benchmarks, stress test results, and hardware context, please refer to the Performance Benchmarks document.

SQLite — Local/Edge (Verified August 2026)

Operation	Latency	RPS
FIND ONE	0.006 ms	129,080
FIND MANY (50)	0.056 ms	14,215
INSERT	0.064 ms	5,498–13,574
UPDATE	0.030 ms	12,735–14,956
DELETE	0.064 ms	8,158–14,422
NATIVE UPSERT	0.068 ms	9,009–12,227
COUNT CACHED	0.001 ms	491,434 req/s
LocalCMS SDK (Warm L1)	0.001 ms	511,829 req/s
LocalCMS SDK Overhead	—	0.00% (verified parity)

Dual-Runtime Profile (Node.js V8 vs. Bun JavaScriptCore)

SveltyCMS provides first-class support for both Node.js (>=24) and Bun (>=1.3 / 1.4):

• Node.js 24+ (V8 TurboFan): Recommended for long-running production servers. In full-stack CMS workloads involving deep middleware chains, session HMAC cryptography, GraphQL AST parsing, and Drizzle query construction, V8’s TurboFan JIT compiler delivers 1.8× to 2.4× higher sustained throughput (4,000+ RPS on findById) and tighter p99 tail latency.
• Bun 1.4+ (Bun.serve): Recommended for developer tooling (bun install / bun test), CLI scripts, and serverless / edge containers where sub-10ms cold start latency and low idle memory are prioritized.

Core database layer (all 4 engines)

Optimizations live in shared core, not one dialect:

Shared module	Engines	Effect
core/lookup-query.ts + SqlAdapterCore.findOne	SQLite, PostgreSQL, MariaDB	{_id} / {_id,tenantId} / + scalar status → findById then in-memory status match (publication clamp stays on the PK ultra path; draft $in still uses full translation)
core/lookup-query.ts (parseIdLookup + isDeleted)	SQLite, PostgreSQL, MariaDB, MongoDB	Routes { _id, isDeleted: false } soft-delete checks directly into compiled findById raw SELECT execution — avoids full query translation AST overhead
SqlAdapterCore.findMany id ultra path	SQLite, PostgreSQL, MariaDB	Pure {_id} list calls → findById (after before-hooks, same semantics as findOne); ~10× faster than dynamic-SQL list path
MongoCrudMethods.findMany id ultra path	MongoDB	Same shape: {_id} list calls → lean findOne, tenant from options or query
SqlAdapterCore.findById + SQLite rawFindById	SQLite raw SELECT; PG/Maria eq+limit	Fast primary-key reads
SqlAdapterCore.update re-read via findById	All SQL when RETURNING empty / non-returning	Faster than post-update findOne
insertReturnsRows / updateReturnsRows	SQLite + PostgreSQL (Drizzle RETURNING); MariaDB raw UPDATE…RETURNING fast path	Single RT on all four engines
Raw INSERT…RETURNING fast path	PostgreSQL, MariaDB, SQLite	One-RT insert via tagged template / prepared pool.execute / wrapped prepared SQL — skips Drizzle AST on write. PG rawInsertReturning honors skipReturning (no-read-back synthesis, seed/system callers)
Raw UPDATE…RETURNING (PG) + no-read-back skipReturning	PostgreSQL, MariaDB, SQLite	PG: tagged-template UPDATE (314 → 444 RPS, 99% of ceiling). skipReturning: true reconstructs the row from prepared values (full-doc callers): MariaDB UPDATE ~2× (431 → 828, up to 1.2k). SQLite: raw prepared-statement UPDATE…RETURNING via rawUpdateReturning hook (2026-08): UPDATE 0.125 → 0.029 ms (6.1 → 18.8k RPS), faster than INSERT; skipReturning also raw (0.071 → 0.024 ms). Central param coercion in prepareAndExecute (boolean→1/0, Date→epoch ms, object→JSON, Uint8Array kept binary) — raw paths never pre-map params (double-coercion cost + blob corruption)
hooks/request-classifier.ts ($O(1)$ Segment Sets)	HTTP Request Pipeline	Static Set lookups (CACHEABLE_SEGMENTS_SET, ADMIN_APP_SEGMENTS_SET) replace linear array prefix iterations across 100% of incoming HTTP requests
services/security/threat-scan.ts (linear WAF / AuthGuard)	HTTP Request Pipeline + payload analysis	O(n) indexOf / char-code scanners replace per-request RegExp engines for SQLi/XSS/traversal/prototype-pollution (ReDoS-proof). Clean ASCII URLs skip decodeURIComponent; honeypot and scanner-bot UA use prefix/token walks; analyzeRequest splits pathname/search without new URL(). Shared by Layer 0 WafGuard and AuthGuardService. SQL prepareValues uses hasIsoDateTimePrefix (char-code) instead of /^\d{4}-\d{2}-\d{2}T/
Widget glob index (scanner.getComponentLoader)	Collection list + entry editor	One-shot ${folder}:{input\|display} Map; no per-field glob scan. List cells retry when the widget registry is ready; plugin columns skip disabled plugins; plugin tabs load only when selected. 50-field resolve 0.053 → 0.023 ms (self-measured 2026-08-23)
utils/fast-json.ts (fastEscapeString Char Loop)	String Serialization	Pure integer character-code scan replaces RegExp engine evaluation for clean ASCII strings — 5×–10× faster JSON escaping on hot serialization paths
utils/native-utils.ts (HEX_TABLE Token Generation)	Security / CSPRNG	256-entry precomputed byte hex lookup table replaces .toString(16).padStart(2, "0") inside hot crypto loops — 3×–5× faster session/token generation
graphql/loaders.ts (Zero-Allocation Batching)	GraphQL Layer	In-place batch slicing (ids.length <= BATCH_SIZE) and direct string-keyed Map caching eliminate thousands of intermediate string/array copies per request
SqlAdapterCore Reusable Table References (_lastTableRef)	SQLite, PostgreSQL, MariaDB	Typed instance reference eliminates per-query getter/setter closure allocations across getColumn, getPhysicalSelection, mapQuery, and prepareValues
utils/native-utils.ts (timingSafeStringEqual)	Security / Cryptography	Constant-time O(max(lenA, lenB)) bitwise accumulator eliminates subtle CPU cache-line timing side-channel attacks across token, webhook, and signature comparisons
utils/hook-utils.ts (STATIC_BASE_HEADER_PAIRS)	HTTP Request Middleware	Pre-filtered static header pairs array avoids per-request Object.entries allocation and conditional filtering during response construction
databases/auth/permissions.ts Fast-Path & Zero-Alloc	Auth / RBAC Layer	Canonical isAdmin(user) short-circuit combined with direct string key checks eliminates redundant mapping and evaluation passes on high-frequency API endpoints
core/batch-module.ts Single-Pass Map Grouping	SQLite, PostgreSQL, MariaDB	O(1) single-lookup map grouping avoids duplicate .has() + .get() hashing cycles during batch operation coalescing
rawBulkUpdate CASE fast path (heterogeneous bulk UPDATE)	SQLite, PostgreSQL, MariaDB	Heterogeneous bulk updates (batch.bulkUpdate with per-row payloads) collapse N per-row UPDATE statements into ONE SET "col" = CASE "_id" WHEN ? THEN ? … ELSE "col" END statement (statement-cache friendly) per chunk; constant columns (updatedAt/tenantId) use plain SET. Values come from prepareUpdateValues (full crud.update parity incl. the JSON data blob), chunks run inside an explicit transaction (all-or-nothing), the WHERE is tenant-scoped (fail-closed MULTI_TENANT), and any failure falls back to the transactional per-row loop. Measured on SQLite: 100-row heterogeneous bulk UPDATE 22.7ms → 0.88ms avg (25.9×, 44 → 930 RPS) — and it fixes the Drizzle .set() “column not found” error the old loop threw for blob-field payloads on PG/MariaDB. MongoDB already coalesced via bulkWrite; its filters are now tenant-scoped and updatedAt-stamped to match crud.update. The homogeneous bulkUpdate fast path is routed through prepareValues too — Drizzle .set() silently DROPS keys that are not physical columns, so homogeneous blob-field payloads (e.g. { title, count }) previously returned success:true without persisting anything (the Zahl-Feld class); prepareValues moves them into the data blob and preserves number types. Write-path trims: per-table date-column key set (_dateKeyCache, WeakMap-keyed by the table def) replaces the per-key *Date/*At/*Time string heuristics + String(columnType) allocations in prepareValues (identical predicate, once per def); synthesizeInsertRow reuses the warm _tableColumnsCache instead of re-walking getTableColumns per insert (the single biggest measured adapter-write win: INSERT 0.127→0.048ms, UPDATE 0.114→0.027ms, BULK INSERT 100 1.99→1.10ms on the adapter benchmark, stable across runs); convertISOToDates honors inPlace for objects so the freshly-built values object is not Object.assign-copied again per write.
convertDatesToISO / convertISOToDates Array In-Place	SQLite, PostgreSQL, MariaDB, MongoDB	In-place array traversal inside convertDatesToISO and convertISOToDates when inPlace: true, eliminating .map() array allocations across multi-record reads
collection-filter-engine.ts Static Field Sets	Collection Filter Service	Static pre-allocated sets (SYSTEM_FILTERABLE_FIELDS, SYSTEM_SEARCHABLE_FIELDS) eliminate per-field array literal allocations during query compilation
convertDatesToISO zero-work fast path	All SQL	In-place conversion returns the row untouched when no Date instances and no JSON-string columns (content rows store ISO strings); on the zero-work path an already-parsed blob (PostgreSQL jsonb arrives as an object, not a string) is still flattened into the row so blob fields stay visible; skipJson: true opts out (projection-only reads)
convertArrayDatesToISO in-place loop	All SQL + MongoDB	When inPlace: true (standard on query execution), performs direct indexed loop over the existing row array instead of allocating intermediate arrays with .map(), halving garbage collection overhead on multi-record result sets
Pre-compiled FLAC (collection:role) allowed Sets	All API / Content Pipelines	Pre-compiles and memoizes allowed field Set instances once per (collection, role) pair and executes single-resolution response filtering via Object.hasOwn traversal, eliminating per-record new Set() and Object.keys() allocations across paginated responses
Compact Keyset Cursors (k1:{dir}:{id})	All SQL + MongoDB	Emits and parses lightweight delimited base64url keyset tokens (<20 bytes) for standard ID-ordered pagination without JSON.stringify/JSON.parse overhead, preventing packet fragmentation over mobile & edge networks
Schema Allowed Filter Field Memoization	Query Filters & Smart Table	Attaches compiled _allowedFilterFieldIds Set<string> directly to the schema model on first lookup, avoiding dynamic Set construction and field iteration on every filtered list request
Schema-Specific Fast String Builders (fast-json.ts)	Auth, Roles, Media, Nodes	Pre-compiled string builders (serializeUserSafe, serializeRoleSafe, etc.) eliminate generic V8 reflection on high-frequency models, delivering up to 3x faster JSON serialization with 0 intermediate object allocation
Direct Pass-Through Streaming Chunks (streaming.ts)	API Streaming & Exports	streamingRawJsonResponse pipes raw database JSON slices directly to ReadableStream chunks with pre-encoded singleton tokens, avoiding JSON.parse + JSON.stringify round-trips during exports
Row-store hybrid (scalar fields → columns)	All SQL	SELECTIVE materialization: only fields with a query benefit become physical columns — indexed/unique fields (real constraints + indexed filters/sorts) or an explicit materialize: true opt-in, always scalar-shaped (allowlist in drizzle-sql-helpers). All other fields stay in the data blob, keeping rows narrow on network adapters (every extra column costs a bind on writes + a decode on reads; measured PG INSERT +51% / FIND MANY +99% when ALL scalars were materialized, while unindexed columns only served filters). Filters/sorts on materialized fields use real columns/indexes; the read merge treats columns as authoritative (data fills only gaps); legacy rows are backfilled from data on column creation (idempotent UPDATE); raw findById selects materialized columns; boolean columns coerce 0/1 → true/false on the raw paths; atomicIncrement targets the column when materialized. Also fixed a pre-existing silent ALTER no-op (PRAGMA ran through stmt.run()), PG/Maria dead columns (createModel made them; getTable never registered them), and the stale-materialized-column drift class (createModel never DROPPED columns/indexes from earlier full-materialization runs — dead indexes measurably slowed writes; tables rebuilt under the selective policy recovered the BULK INSERT regression)

| LocalCMS and HTTP turbo sit above this layer — same gains on every adapter:

SDK write-path slice	Before	After	Note
Lazy module singletons (workflow/response-cache/pub-sub/outbox)	3.5k create / 3.4k update	4.0k / 6.3k	per-write await import() cost 30–60µs each — resolved once, hot path = promise resolves
Plugin-registry views (getAll() / hook presence)	allocates mapped array + hook walk per mutation	O(1) cached (invalidated on register)	called twice per SDK create/update by triggerLifecycleHook
Outbox emit (buffered)	crypto UUID + getDb() per emit	crypto UUID stamped at emit time (~1µs); trailing 25ms debounce (reset per emit) + hard-max 512 via setImmediate — write bursts become one insertMany, never a same-tick SQLite mutex steal	measured 28µs → ~5µs; full-pipeline create tax vs adapter ~11%
Audit hook (after-insert)	logs every insert incl. outbox flush batches	skips svelty_outbox (internal machinery); sync-first flags; skipReturning bulk flush	the outbox→audit cascade (1000-entry flushes on the write path) was the hidden tax
Full-pipeline SDK create (SQLite)	2.7k RPS	3.7–7.6k RPS	outbox delta vs disabled: +121.8% → +22–75%; detached 10–14.4k (host-load dependent; range measured on the isolated benchmark DB)

HTTP turbo / LocalCMS → ICrudAdapter.findOne|insert|update
  → SqlAdapterCore (SQLite | Postgres | MariaDB)
  → MongoCrudMethods (MongoDB)

Core ↔ adapter communication (all 4 engines)

Every request — LocalCMS SDK or HTTP — uses the same write pipeline. The database adapter is a direct in-process call, not an HTTP hop:

1. Valibot sanitization (once, in core).
2. Cached schema + widget transforms (fields._activeWidgets, reused accessor).
3. db.crud.insert / update / find on the active adapter.
4. Single-statement native driver execution (SQL UPDATE … RETURNING / Mongo findOneAndUpdate $set).
5. Off-path microtasks: outbox, L2 invalidation, webhooks, audit.

Adapters do not re-validate payloads (Mongo runValidators: false on hot writes). createdAt is insert-only on SQL and Mongo. Partial SQL updates omit an empty data={} blob.

BENCHMARK is not a write-path cheat. isBenchmarkExternalServicesDisabled() only skips outbound webhooks, SMTP, and similar network I/O so the matrix does not contact third parties. Persistence, Valibot, RBAC, RETURNING/$set, and L1 invalidation run the production path. skipSideEffects: true is an explicit SDK option (bulk seed / import), reported as a separate (detached) column — it is not toggled by BENCHMARK. Ambient BENCHMARK was removed from SQL skipReturning so insert/update benches measure the same SQL as production.

Layer	What stays on the response path	What is detached
Core schema / widgets	In-memory LRU + field-cached transforms	—
Adapter write	One prepared statement / atomic $set	—
Session (warm)	LRU / turbo context — 0 DB round-trips	—
Session (cold)	auth.validateSession (session⋈user JOIN); no fall-through to two extra queries	L2 session cache fill
Mutation HTTP 200	Sync L1 responseCache walk	L2 pattern scans (void / 10ms batch)
Boot	Topological plugin-registry with zero settling delay	FULL phase (cache warm, jobs) → WARMED

LocalCMS collections hot path (create / update / findById)

Slow SDK entry paths historically paid for work that was not needed on simple schemas. Current design (CollectionsNamespace in src/services/sdk/namespaces/collections-namespace.ts):

Optimization	Effect
Schema hot flags (_hasActiveWidgets, _hasNumberFields, _hasSanitizableFields, _hasHooks)	Skip field walks, hooks import, and modifyRequest when unused
findById single-id → crud.findOne	Avoid $in findMany + full batch machinery cost for one id
findMany pure-_id → findById (after before-hooks)	List path with an id filter pays raw-SELECT speed (~10×) instead of dynamic SQL
SDK find({ _id }) → findById	Collections find() with a pure id filter returns { data: [row] } via the single-id path (no findMany / coalesce / list cache key)
Warm peekReadySchema	Cached schemas skip the await getSchema() microtask on find/create/update/delete
Same-tick batch window for concurrent findById	Still coalesces N+1 without always using multi-id queries
Sync FNV query-hash for list cache keys	No async hash-wasm on every find()
Static CacheCategory import	No dynamic import on cache set
Entry mutations do not bump contentStore.contentVersion	Avoids nav/SSE structure invalidation on every write
Path + alias indexes on contentStore	O(1) getNodeByPath / collection alias lookup
Workflow definition negative cache (60s)	Create path skips DB miss for collections without workflows
Parallel afterMutation + afterSave	Write post-hooks no longer serialize
Outbox kill-switch pre-check before dynamic import	Write microtask skips the outbox module import when DISABLE_OUTBOX=true (the only opt-out; ambient benchmark env toggles removed)
Lazy module singletons on the write path	Per-write await import(workflow/response-cache/pub-sub/outbox) cost 30–60µs each even when cached; resolve once, hot path becomes a promise resolve — full-pipeline create 3.5k → 4.0k RPS, update 3.4k → 6.3k RPS
Deduped cache-invalidation patterns	Per-write pattern fan-out cut from 9 clears to 6 (identical generated keys)
Field-cached widget transforms (modify-request.ts)	Active modifyRequest widgets resolved once onto fields._activeWidgets; reused accessor + context — no per-field spread/closure alloc
Document writes skip schema-structure cache keys	post-write.ts no longer purges cms:content_structure on entry mutations — getSchema() stays an in-memory LRU hit
createdAt immutability on UPDATE	SQL prepareValues + Mongo $set omit createdAt on updates; partial SQL updates skip empty data={} blobs
Mutation cache invalidation off the response path	handle-api-requests L1 walk is sync; L2 deletes/pattern scans are fire-and-forget / 10ms-batched so they never add to 200 latency
Cross-chunk service singletons (globalThis)	responseCache, webhookService, automationService share one instance across Rolldown chunks — invalidations apply immediately

SDK tax suite: tests/benchmarks/local-cms-crud.test.ts measures cms.collections.create / update / findById vs adapter findOne (not raw db.crud alone). tests/benchmarks/local-sdk-vs-direct.test.ts reports the full pipeline (all post-write side effects executing: outbox INSERT, cache-pattern invalidation, workflow init, pubsub — create ≈2.0k RPS, update ≈2.5k RPS on SQLite) and the detached number via the documented skipSideEffects: true option (create ≈4.9k, update ≈4.4k). No environment flags are involved — benchmarks run the same code path production runs.

HTTP findById turbo lane + responseCache

Authenticated GET short-circuit (handleTurboGet → L1 responseCache):

Fix	Why
successResponse stashes apiBody	Turbo/write path can re-use one stringify
Weak-ETag path still writes responseCache	Collections findById used weak ETag and previously never warmed turbo L1
Sync generateContentEtag	Dropped async hash-wasm on GET miss path
Real session turbo warm	Benchmark logins populate turboAuthCache via the real auth pipeline — turbo fires with real cookies (benchmark pseudo-sessions removed 2026-08)
API cache writes use buildUserResponseCacheKey	Same key as handleTurboGet (was writing only cacheService under a different key)

# Rebuild required before HTTP turbo numbers pick up hook/handler changes
bun run build
bun test tests/benchmarks/api-latency.test.ts   # cold (cache-busted) + TURBO-HIT
bun test tests/benchmarks/local-cms-crud.test.ts

When enterprise auth extras are disabled/optional: middleware still enforces core auth + RBAC for protected routes; SAML/SCIM/2FA/passkeys add cost only when configured (see Authentication System).

How to re-baseline after changes:

BENCHMARK_RECORD=1 bun test tests/benchmarks/database-performance.test.ts
bun test tests/benchmarks/local-api-throughput.test.ts
bun test tests/benchmarks/api-latency.test.ts
bun test tests/benchmarks/local-cms-crud.test.ts
bun test tests/benchmarks/mixed-workload.test.ts
bun run test:unit -- tests/unit/services/local-cms.test.ts

Middleware & Request Lane Pipeline (Verified August 2026)

Every request is classified in O(1) by classifyRequest() (src/hooks/request-classifier.ts) before the middleware sequence. Responses carry x-svelty-lane for observability and load-balancer routing.

Request Lane	Latency	RPS
Turbo Pipeline (Light)	0.294 ms	3,130
Full Security + Auth	0.884 ms	962
REST with API Caching	0.856 ms	1,029
GraphQL Query Caching	0.865 ms	1,018
Health Check Fast Path	0.572 ms	1,749
Static Asset Fast Path	0.586 ms	1,524

What each lane does

Lane	When	Pipeline cost
FAST_STATIC	/favicon.ico, /robots.txt, /_app/*, /static/*	Skip full stack; long-cache headers
HEALTH	/health, /api/system/health	Immediate JSON health (no auth/DB wait)
HYPER_TURBO	Authenticated GET/HEAD on cacheable API prefixes + warm session	handleTurboGet may serve pre-stringified body + ETag
API_READ	Public/unauthenticated GET API, or non-cacheable GET	Full security + auth path
API_WRITE	POST/PUT/PATCH/DELETE	Full CSRF + RBAC + mutation pipeline
APP_SSR	Admin pages (/dashboard, /config, /collections, … + locales)	Full SSR pipeline. /dashboard hydrates layout + widget.json picker in load(); widget Svelte chunks stay lazy.
BOOTSTRAP	/setup, /login, /auth	Setup/auth shell
FILES	/files/*, /media/* downloads	File server path
PUBLIC_SITE	Non-admin public pages	Public SSR

Cacheable API prefixes (eligible for HYPER_TURBO when a session cookie or Authorization is present): /api/collections, /api/content, /api/settings, /api/system, /api/graphql, /api/media, /api/dashboard, and related admin namespaces listed in CACHEABLE_PREFIXES.

GraphQL / REST response cache (operator view)

Path	Warm hit (typical)	What is skipped on hit
HTTP GET (Turbo lane)	~0.25–0.35 ms	Full handler body recompute; uses user-scoped response cache
HTTP POST GraphQL (handler)	~0.45–0.65 ms	Yoga re-parse / JIT cold cost when L1 has body+etag tuple
LocalCMS in-process	~0.016 ms	No HTTP; still zero-tax vs direct adapter

Cache keys are user-scoped (u:{userId}:…) with deep-sorted GraphQL variables so multi-tenant / multi-user isolation holds. Mutations invalidate via responseCache (res:* / GraphQL patterns).

Tests (pyramid):

Layer	File	Contract
Unit	tests/unit/core/request-classifier-and-response-cache.test.ts	All lanes + auth_sessions turbo detection + GraphQL key isolation
Unit	tests/unit/hooks/handle-turbo-get-lane.test.ts	TURBO-HIT vs miss, Host cookie, POST skip
Integration	tests/integration/api/request-lane-headers.test.ts	Live x-svelty-lane + health JSON + dashboard __data.json
E2E	tests/e2e/routes/system/hooks-lane-smoke.spec.ts	Admin session shell + /health browser request
Bench	tests/benchmarks/lane-router-attribution.test.ts	Classification throughput

Cross-Database Impact (All 4 Engines)

Optimization	SQLite	PostgreSQL	MariaDB	MongoDB
Schema-aware row conversion	✅ Full	✅ Full	✅ Full	N/A (own path)
Ring-buffer result pool	✅ Full	✅ Full	✅ Full	✅ Full
Conditions array pool	✅ Full	✅ Full	✅ Full	N/A (own path)
Fused mapQuery (no IR objects)	✅ Full	✅ Full	✅ Full	✅ Full
for…in (zero Object.entries)	✅ Full	✅ Full	✅ Full	✅ Full
Pre-allocated meta object	✅ Full	✅ Full	✅ Full	✅ Full
MariaDB double-parse isolated	N/A	✅ Benefit	✅	N/A
Parallel list + count (websiteTokens.getAll)	✅ Full	✅ Full	✅ Full	✅ Full
Prepared-statement cache	✅	N/A (driver caches)	N/A (driver prepared)	N/A
Projection (fields → skip data blob)	✅	✅	✅	✅ (driver)
Single-statement deleteMany	✅	✅	✅	✅ (native)
Raw UPDATE…RETURNING write fast path	✅	✅ (Drizzle)	✅	✅ (findOneAndUpdate)
Skip driver re-validation on hot writes	N/A	N/A	N/A	✅ (runValidators:false on update/upsert — Valibot already ran at the SDK/API layer; restore keeps validators for unique-collision detection)
Targeted column UPDATE (omit empty data)	✅	✅	✅	✅ ($set only provided fields)
createdAt insert-only	✅	✅	✅	✅ (stripped from $set)
postgres.js JSON/array param bind	N/A	✅ (::jsonb)	N/A	N/A

SQL family gets ~5-8 fewer allocations per filtered query. MongoDB gets ~2-3 fewer (result pool + fused mapQuery) plus no per-document validation re-run on update/upsert. All 4 databases benefit from shared BaseAdapter optimizations.

Credential list hot-path

system.websiteTokens.getAll() keeps admin tables sub-millisecond under multi-tenant filtering ({ tenantId, name } compound index):

• MongoDB — crud.findPage with limit+1 hasMore + total: "exact" (count goes through the 30s L1 wrapper)
• SQL engines — parallel SELECT … LIMIT n+1 + COUNT(*) (Promise.all in relational-system.ts); sentinel row trimmed before scrubbing hashes

Product-layer list & count (equal on all engines)

Design rule: Prefer cheaper correctness tiers by default. Exact cardinality is opt-in. Optimizations live in the shared ICrudAdapter contract — not engine-specific call sites — so SQLite, PostgreSQL, MariaDB, and MongoDB gain together.

findPage + hasMore (limit + 1)

Admin and API list UIs no longer need findMany + count for “next page?” semantics.

const page = await db.crud.findPage(
  "posts",
  { status: "publish" },
  {
    limit: 50,
    tenantId,
    total: "none", // default — no COUNT(*)
  },
);
// page.data = { items, hasMore, pageSize, nextCursor? }

Option	Behavior
total: "none" (default)	Single query with limit + 1; hasMore from row count
total: "exact"	Adds exact count after the page fetch
total: "estimate" / "auto"	Adds approximate total when safe (see count modes)

Implementation: SqlAdapterCore.findPage, MongoCrudMethods.findPage, pure helpers in core/page-utils.ts. Tenant guard forwards findPage. Schema proxy: db.posts.findPage({ filter, limit, cursor }).

Keyset cursor (deep pages)

nextCursor is an opaque base64url payload (id + optional sort field/value + direction). Pass it as options.cursor on the next call:

• Ignores offset when cursor is set (avoids OFFSET N scans)
• Filter merge uses Mongo-style $lt/$gt/$or/$and — SQL mapQuery and Mongo both understand them
• Default sort when omitted: { _id: -1 } for stable keyset order
• Legacy plain _id strings still decode as cursors

When total is requested, findMany and count run in parallel (count still hits the 30s L1 cache).

Unified count(..., { mode })

Mode	When	Semantic
exact	Billing, RBAC, uniqueness	True cardinality
estimate	Dashboards / badges when unfiltered	Engine stats / metadata
auto (default)	General	Estimate if empty filter + no tenantId; else exact

Estimate is never used for tenant-scoped filters (would leak whole-table cardinality). Eligibility: shouldUseEstimateCount() in core/page-utils.ts.

Engine	Estimate path
MongoDB	estimatedDocumentCount() (WiredTiger metadata)
PostgreSQL	pg_class.reltuples
MariaDB / MySQL	information_schema.TABLES.TABLE_ROWS
SQLite	sqlite_stat1 when ANALYZE present; else exact (already sub-ms)

Short-lived tenant count cache (L1 / L2)

createCountCachedCrud (core/count-cache.ts) wraps crud.count after the tenant guard in db.ts:

• TTL: 30 seconds (COUNT_CACHE_TTL_SECONDS)
• Key: count:{collection}:{mode}:{includeDeleted}:{filterHash} (tenant-namespaced by cacheService)
• Tags: count, count:{collection}, collection:{collection} → cleared with invalidateQueryCache
• Bypass: options.bypassCache: true

Equal benefit: after the first miss, repeated admin badge / dashboard counts hit L1 (~0.024 ms on all engines in the 2026-08-04 re-baseline).

Verified gains (2026-08-04 re-bench, local Docker / embedded)

Suite: BENCHMARK_RECORD=1 bun test tests/benchmarks/database-performance.test.ts
Hardware: same host as prior adapter baseline. Redis disabled. Includes keyset scenarios.

Scenario	SQLite	PostgreSQL	MariaDB	MongoDB
FIND PAGE (50 hasMore)	0.086 ms	1.008 ms	0.664 ms	0.867 ms
LIST+COUNT (legacy)	0.192 ms	2.233 ms	1.086 ms	4.925 ms
findPage vs legacy	~2.2×	~2.2×	~1.6×	~5.7×
FIND PAGE keyset (page 2)	0.072 ms	0.996 ms	0.645 ms	0.748 ms
FIND MANY offset 50	0.050 ms	0.904 ms	0.585 ms	0.705 ms
COUNT exact (filtered, no cache)	0.120 ms	2.197 ms	0.936 ms	3.817 ms
COUNT ESTIMATE (unfiltered)	0.023 ms	0.745 ms	0.502 ms	0.492 ms
COUNT CACHED (L1 hit)	0.024 ms	0.024 ms	0.029 ms	0.025 ms
estimate vs exact	~5×	~3×	~1.9×	~7.8×
cached vs exact	~5×	~90×	~32×	~150×

getCollectionData now uses findPage with total: "auto" only when includeMetadata is true; list-only paths skip count entirely.

PostgreSQL raw-path identifier quoting fix (2026-08-11)

Bug: the PG adapter’s raw findById and raw UPDATE…RETURNING paths interpolated the table name unquoted (exec.unsafe(getTableName(table))). PostgreSQL folds unquoted identifiers to lowercase, so any mixed-case collection table (e.g. collection_BenchmarkStable) raised 42P01 relation does not exist on every call and silently fell back to the slower Drizzle path — the raw fast paths had never engaged for mixed-case collections (the only kind the content system creates). MariaDB/SQLite were unaffected (backticks / case-insensitive identifiers).

Fix: quote the identifier in both raw paths ("${name.replace(/"/g, '""')}").

Measured (honest production server, real session, Docker PostgreSQL, tmp-profile probe):

Cell	Before	After
HTTP update (client-observed)	6.21 ms	4.34 ms (−30%)
Update handler + adapter (ns:persist)	3.1–5.9 ms	1.7–2.5 ms
Random read (cache miss)	0.70 ms	0.57 ms

Reads/writes on mixed-case collections now use the prepared raw statements (parse-once + bind/execute reuse) exactly like lowercase test collections did.

Philosophy

SveltyCMS implements best-practice performance patterns from day one. Every feature is built with performance as a core requirement, not an afterthought. The 2027 allocation-floor work pushes the database layer to the practical limit of the current architecture (Drizzle ORM + DatabaseResult contract). Product-layer list/count contracts (above) reduce round-trips before that floor matters.

2027 Allocation-Floor Optimizations

Schema-Aware Row Conversion

Instead of checking every row key against DATE_FIELDS/JSON_FIELDS Set lookups on every row read/write, table schemas are pre-computed once during table creation. Only known date and JSON columns are converted — eliminating per-row Set.has() calls and enabling targeted iteration.

// Before: checks every key against Sets
for (const k in row) {
  if (DATE_FIELDS.has(k)) {
    /* convert date */
  } else if (JSON_FIELDS.has(k)) {
    /* parse JSON */
  }
  result[k] = row[k];
}

// After: only touches known columns
registerTableSchema("posts", ["_id", "title", "createdAt", "metadata"]);
// converts only "createdAt" (date) and "metadata" (JSON) — skips everything else

Registrations are additive — knowledge only grows: a later registerTableSchema call that includes materialized/boolean columns augments an earlier base-only registration (and a later partial registration never shrinks the maps). Both the physical (collection_…) and logical table names are registered so raw and Drizzle paths share the same schema knowledge.

Canonical collection naming (2026-08-20)

All physical collection table/model names derive from one function — normalizeCollectionTableName() in src/databases/core/collection-name.ts (prefix-aware, hyphen-stripping, idempotent). Consumers: the SQL adapters’ getTable()/_warmTableRegistry()/createModel cleanup, createIndexes() (DDL), registerTableSchema() variant keys, MongoDB’s normalizeCollectionName()/createModel()/deleteModel(), the Local SDK, and API handlers. This closes two latent hyphenated-id mismatches: SQL CREATE INDEX previously targeted a phantom table name, and MongoDB previously registered two different Mongoose models (full-schema vs generic) for the same hyphenated collection.

SQLite INSERT/UPDATE templates (2026-08-23)

SQLite rawInsertReturning now matches PostgreSQL: one cached INSERT … VALUES (?) per table/column-set, no RETURNING *, row synthesized from bound values (CMS tables have no insert triggers). UPDATE SQL is cached per (table, column-set, tenant clause, skipReturning) so the SET list is not rebuilt on every PATCH.

GraphQL Yoga bypass for catalog/health (2026-08-23)

contentSystemHealth and allCollections are single-root in-memory queries. After auth, the GraphQL handler answers them without Yoga/JIT (field projection from the selection set). Shared parse cache so comment-busted response-cache keys still reuse the same DocumentNode for JIT on everything else.

QueryBuilder list conversion (2026-08-23)

Admin collection lists use queryBuilder().execute(), not crud.findMany. That path now registers the table schema and converts rows in place (same maps as findMany) so MariaDB/PostgreSQL/SQLite lists do not allocate a new object per row or walk unknown keys. exists() is SELECT _id … LIMIT 1 (Mongo: findOne + _id projection) instead of COUNT(*) / countDocuments. Mongo upsert is one findOneAndUpdate with upsert: true — _id stays on the filter so $setOnInsert never carries it (Mongoose 9 rejects _id there).

Automation event→flow index (2026-08-23)

AutomationService keeps a per-tenant event → active event-triggered flows Map, rebuilt on cache refresh, save, and delete. handleEvent does one Map lookup and returns immediately when nothing subscribes to the event — content mutations no longer scan every flow. A compiled-query cache for SQL list/filter reads was measured and dropped: a single DB read is already ~6 µs (~10% of a REST list), so the rewrite would save <0.5% of a request.

Fused Query Construction (SQL + MongoDB)

Both mapQuery implementations now build database conditions directly from user queries without intermediate IR (Intermediate Representation) objects. The old pattern (query → QueryIR → LogicalGroup → QueryCondition[] → SQL conditions) is replaced with a single fused walk.

• SQL path (drizzle-sql-helpers.ts): addFilterConds + addSingleCondition build SQL[] directly
• Mongo path (mongodb/adapter-core.ts): addMongoConds + addMongoCondition build filter objects directly
• Eliminated: QueryIR, LogicalGroup, QueryCondition[] intermediates (~3-5 objects per filtered query)
• Eliminated: All Object.entries() array allocations (replaced with for...in)

Ring-Buffer Result Pool

All BaseAdapter.wrap() calls now use a 64-slot ring-buffer pool for { success, data } result wrappers. Pooled slots are safe in single-threaded JS — callers consume results synchronously after await. Eliminates 100% of result wrapper allocations.

Ring-Buffer Conditions Array Pool

Filtered queries (mapQuery) reuse conditions: SQL[] arrays from a 32-slot ring-buffer pool instead of allocating [] each time. Arrays are cleared via .length = 0 without deallocation.

Pre-Allocated Meta Object

The { executionTime } meta sub-object is pre-allocated once per adapter. wrap() mutates this._meta.executionTime instead of creating a new object per call.

MariaDB Double-Parse Isolation

MariaDB’s native JSON columns can double-encode. The double-parse loop is now opt-in (mariaDoubleParseJson: true) — PostgreSQL and SQLite paths never pay this cost.

SQLite RETURNING Cache

The insertMany path caches whether RETURNING is supported per SQLite instance. Avoids repeated try/catch + logger.warn overhead in benchmarks and unsupported table scenarios.

Zero-Tax SDK Dispatcher

Self-overwriting getters eliminate Proxy overhead after first access. Verified: 0.00% middleware tax (LocalCMS is statistically identical to direct adapter calls).

Structural Improvements (Shared by All Adapters)

• Proxy extraction: 3 scattered Proxy factories → 1 shared core/proxy-utils.ts with 23 dedicated tests
• Tenant filter centralization: ~4+ duplicate sites → single source of truth in relational-utils.ts
• Query IR removal: standalone query-ir.ts removed; translator inlined into the only 2 real consumers
• Mongo file reduction: 43 → 39 files (4 thin module/model pairs merged)
• Code reduction: 1,105 lines deleted across 36 files
• Lazy Zero-Allocation GraphQL Loaders: Eager per-request user, media, and collection loaders are refactored into on-demand lazy getters, eliminating memory overhead on requests that do not query those fields.
• Direct Primary Key Index Loading: Replaced MongoDB-style $in filter translations with explicit, database-agnostic db.crud.findByIds index lookups, allowing SQL and document database engines to resolve relational widget fields with zero query-parsing overhead.

Phase 1: Database Indexing & Optimization

Status: ✅ FULLY IMPLEMENTED Impact: Exponential query speedup (O(n) → O(log n))

Background IndexOptimizer service automatically manages database performance through schema-driven indexing, background building, and multi-database support (MongoDB Compound/Text, SQL B-Tree).

Batch Relational Upserts

setMany, content-node upserts, and crud.upsert / crud.upsertMany (when the filter is _id) use true multi-row INSERT ... ON CONFLICT DO UPDATE via Drizzle ORM. PostgreSQL/SQLite use excluded.*; MariaDB/MySQL use VALUES(). Non-PK filters still fall back to findOne + insert/update. Collection import (bulkImportCollectionDocuments) is findByIds + insertMany/upsertMany per 100-row chunk — not N findOne calls.

Negative Caching

O(1) missing-key cache prevents “DB miss storms” (verified 2392x speedup for repeated misses).

Prefix-Bucketed Invalidation

O(1) namespace clearing replaces O(N) cache scans.

---

Operator Guide: Further Server Performance Gains

SveltyCMS ships with strong defaults. Use this checklist on top of the lane/cache stack above — none of it requires forking core code.

1. Request lanes & application cache (CMS-level)

Goal	What to do
Maximize Turbo GET hits	Keep real session cookies (auth_sessions / __Host-auth_sessions / __Secure-auth_sessions) or Bearer tokens on cacheable GETs; anonymous traffic stays on API_READ and never uses turbo auth.
Warm GraphQL reads	Prefer idempotent GETs with stable query + variables for public/catalog data; POST still caches when the handler warms responseCache, but GET turbo short-circuits earlier.
L2 shared cache across nodes	Enable Redis (USE_REDIS / private config) so cacheService L2 + response-cache L2 are shared; without Redis, each node only has L1 Maps.
Avoid self-inflicted misses	Content mutations already invalidate response cache; custom bulk scripts should call the same invalidation paths (or restart) so clients do not serve stale turbo bodies.
Observe lanes in production	Log or sample x-svelty-lane at the reverse proxy; high API_WRITE or low HYPER_TURBO share usually means missing auth headers on GETs or traffic outside CACHEABLE_PREFIXES.
Health checks	Point load balancers at /health (lane HEALTH) — not admin SSR — so probes stay sub-ms and do not warm auth/session paths.
LocalSDK vs HTTP	Server-side code should use LocalCMS / Local SDK (documented zero-tax path). Never fetch('/api/…') from +page.server.ts for hot paths.

2. Database server tuning (engine-level)

SveltyCMS ships with zero-configuration defaults that work out of the box with any Docker Compose setup. For production or high-throughput workloads, the following database-level tuning tweaks can yield 2-10x latency improvements without changing any CMS code.

MariaDB / MySQL

Setting	Default (Docker)	Recommended	Why
max_connections	151	500–1000	Default ceiling easily exhausted under concurrent CMS workloads. Verified: Max_used_connections=152 exceeded the 151 cap, causing connection saturation and 1041ms HTTP latency spikes.
innodb_buffer_pool_size	128 MB	70-80% of available RAM	Tiny default forces constant disk reads. For a 4 GB container: innodb_buffer_pool_size=3G. This is the single most impactful tuning knob for MariaDB performance.
innodb_log_file_size	96 MB	512 MB – 2 GB	Larger redo logs reduce write contention and checkpoint pressure.
innodb_io_capacity	200	2000–5000	Modern SSDs can handle 50k+ IOPS. Default throttles InnoDB background I/O.
innodb_flush_log_at_trx_commit	1 (fsync per commit)	2	Setting to 2 avoids per-commit fsync (flushes once per second). Caution: trade 1-second durability window for faster writes — acceptable for most CMS workloads.
table_open_cache	2000	4000–8000	Reduces table open/close churn when many collections are active.

Measured gains with all tweaks (Intel i7-13700H, Docker, MariaDB 12.2.2):

Operation	Default (avg / p95)	Tuned (avg / p95)	Improvement
INSERT	1.229ms / 3.061ms	0.791ms / 1.100ms	-36% / -64%
DELETE	2.044ms / 2.664ms	0.665ms / 0.827ms	-67% / -69%
BULK INSERT (100)	5.497ms / 10.170ms	4.460ms / 6.772ms	-19% / -33%
TX Commit	4.268ms / 8.675ms	2.250ms / 3.869ms	-47% / -55%
TX Rollback	3.016ms / 5.393ms	3.450ms / 6.188ms	~same
INSERT RPS	716 req/s	994 req/s	+39%
DELETE RPS	428 req/s	1,293 req/s	+202%
TX Commit RPS	225 tx/s	371 tx/s	+65%

Read operations (SELECT, FIND) are minimally affected by tuning on small datasets because the default 128MB buffer pool is sufficient for light workloads. Gains compound significantly on production datasets (10k+ entries) and under concurrent multi-tenant load.

Docker Compose override example (docker-compose.override.yml):

services:
  mariadb:
    command:
      - --max_connections=500
      - --innodb_buffer_pool_size=4G
      - --innodb_log_file_size=512M
      - --innodb_io_capacity=2000
      - --innodb_flush_log_at_trx_commit=2

PostgreSQL

Setting	Default (Docker)	Recommended	Why
max_connections	100	200–400	Default caps connection pool quickly. Beyond 400, add PgBouncer for connection pooling.
shared_buffers	128 MB	25% of available RAM	Default is too small for active working sets.
effective_cache_size	4 GB	75% of available RAM	Helps query planner choose index scans over seq scans.
work_mem	4 MB	16–64 MB	Per-sort/join memory. Important for complex relational queries.
wal_buffers	4 MB	64 MB	Reduces WAL write contention during bulk operations.
random_page_cost	4.0	1.1	Modern SSDs have near-zero seek cost. Lower value encourages index scans.
synchronous_commit	on	off	Disables per-transaction fsync. Caution: 1-second durability window for ~10x faster writes.

Measured gains with all tweaks (Intel i7-13700H, Docker, PostgreSQL 18.3):

Operation	Default (avg / p95)	Tuned (avg / p95)	Improvement
INSERT	2.201ms / 4.301ms	1.463ms / 1.850ms	-34% / -57%
UPDATE	3.036ms / 4.437ms	1.424ms / 1.729ms	-53% / -61%
DELETE	2.587ms / 3.112ms	1.200ms / 1.422ms	-54% / -54%
NATIVE UPSERT	2.638ms / 3.208ms	1.235ms / 1.454ms	-53% / -55%
TX Commit	4.620ms / 7.688ms	4.029ms / 6.843ms	-13% / -11%
INSERT RPS	431 req/s	577 req/s	+34%
UPDATE RPS	305 req/s	603 req/s	+98%
DELETE RPS	333 req/s	703 req/s	+111%
HTTP E2E RPS	810 req/s	999 req/s	+23%

Write-heavy operations (INSERT, UPDATE, DELETE, UPSERT) benefit most from synchronous_commit=off and larger shared_buffers. Read operations see moderate gains from better query planning (random_page_cost=1.1, effective_cache_size=6GB). The HTTP E2E throughput improves by 23% as the cumulative middleware + DB pipeline becomes more efficient under load.

⚡ Application Environment Overrides for Low-Latency Development & Benchmarking

SveltyCMS supports native environment variable overrides to tune database session parameters directly from .env or process environment, eliminating the need to modify external database container files:

Environment Variable	Target Database	Default	Fast Dev / Benchmark Setting	Impact & Behavior
PG_SYNCHRONOUS_COMMIT	PostgreSQL	on	off or local	Bypasses per-transaction disk fsync. Reduces write latencies from ~15ms down to ~1-2ms for local dev and benchmarks.
PG_WORK_MEM	PostgreSQL	Default (4MB)	32MB or 64MB	Prevents disk spilling for complex sorts/joins during dynamic content queries.
SQLITE_SYNCHRONOUS	SQLite	NORMAL	NORMAL / OFF	Controls SQLite synchronous write durability (NORMAL recommended for WAL mode).
SQLITE_BUSY_TIMEOUT	SQLite	30000	30000	Busy lock wait timeout (30s) preventing concurrent writer lock errors under load.
SQLITE_WAL_AUTOCHECKPOINT	SQLite	2000	2000 or 5000	Page count for auto-flushing dirty WAL pages to main file, smoothing out p99 tail spikes.
MARIADB_SESSION_INIT	MariaDB	None	Custom SQL	Allows executing session-level SQL commands per new connection checked out from the pool.
TEST_MODE	MongoDB	w: 1, j: true	—	Sandbox isolation only (bench DB + test config); the adapter never changes write concern from environment flags.

🚀 Core CMS Application Code Optimizations (Universal Across All 4 Adapters)

In addition to database-level session settings, SveltyCMS incorporates pure application-layer code optimizations in the core API dispatcher, schema validation engine, and audit pipeline. These zero-allocation optimizations apply universally to all 4 database adapters (PostgreSQL, MariaDB, SQLite, MongoDB) as well as core CMS database tables:

1. Copy-On-Write Request Body Sanitization (src/content/content-utils.ts):

   • prepareCollectionFields() uses a single-pass Copy-On-Write pattern (sanitize + maxLength + null-row strip in one schema walk).
   • For 99% of normal write payloads, zero shallow object copies ({ ...data }) are allocated, eliminating memory churn before reaching any database adapter.

2. Asynchronous Non-Blocking Microtask Audit Logger (src/services/security/audit-service.ts):

   • Uses static node:crypto imports during SSR module load and a serialized chainLock queue to guarantee cryptographic hash chain integrity under concurrent writes.
   • Database after-insert audit hooks operate via non-blocking microtasks (this.log(...).catch(...)).
   • Enables tamper-evident SHA-256 hash chaining in memory without delaying HTTP response latency.

3. High-Efficiency Role & Permission Cache (src/databases/auth/permissions.ts):

   • Evaluates RBAC permissions using compiled Uint32Array role bitsets and 5-minute LRU permission caching.
   • Reuses mapped roleIds across cache reads and writes to eliminate duplicate array mapping allocations.

🛡️ Benchmark Integrity & Anti-Cheating Guarantees

SveltyCMS achieves sub-millisecond query execution (0.839ms findById) through architectural efficiency, not by cheating, bypassing validation, or short-circuiting production contracts:

Integrity Standard	SveltyCMS Guarantee	Why It Matters
Full Security Contract Parity	100% Active (Authentication, RBAC, Valibot validation, multi-tenant isolation, SHA-256 audit logging)*	SveltyCMS runs the full production middleware stack on every request. (Note: Audit logging is physically bypassed only when explicitly configured with DISABLE_AUDIT_LOGS=true during bulk benchmark data generation)
Real Database I/O	10,000 real documents on native PostgreSQL 18 / SQLite / MariaDB / MongoDB	No mock responses or dummy fallbacks. Queries hit real indexed database tables. (Earlier 2026-08 tables were measured on PostgreSQL 16; the matrix now pins postgres:18.)
Zero ORM Overhead (Direct SQL Helpers)	Uses native Drizzle SQL helpers & raw driver bindings rather than heavy ORM query builder abstractions	Heavy ORMs (Drizzle ORM dynamic joins, Knex AST generators) consume high CPU per request. SveltyCMS bypasses ORM compilation tax to run raw parameterized SQL directly.
Verified SDK Parity	0.00% overhead verified between LocalCMS SDK and raw DB driver	Accessing content via SDK matches raw database driver execution speed without proxy tax.

MongoDB

Setting	Default (Docker)	Recommended	Why
wiredTigerCacheSizeGB	50% of RAM − 1 GB	60-70% of available RAM	On machines with <8GB RAM, the default may be too small. On machines with >16GB RAM, defaults are already generous and tuning yields minimal gain.
maxConnections	1000	2000+	Default is generous; only raise if you see connection saturation. Connections available on a typical system exceed 400k.
syncdelay	60s	Keep default	Lower values do NOT improve performance — more frequent journal flushes add I/O overhead. Verified: syncdelay=10 made 1000-doc inserts 26% slower (43ms vs 34ms) on the same hardware. Keep default at 60s; reduce only if you need tighter durability guarantees.

Measured baseline (Intel i7-13700H, 31GB RAM, Docker, WiredTiger cache 16GB):

Metric	Default	Notes
INSERT 1000 docs (1KB each)	34ms (29,412 ops/s)	Cache already 16GB — no disk bottleneck
READ 1000 docs	14ms (71,429 ops/s)	All in cache
HTTP E2E (Truth Audit)	1.175ms avg / 2.157ms p95	851 req/s

All 4 Adapters Now Run Under Bun

All four database adapters (MariaDB, PostgreSQL, SQLite, MongoDB) run natively under bun test — no need for vitest/Node.js for any database.

The fix: A v8 shim in src/utils/v8-shim.ts patches process.getBuiltinModule('v8') to return a safe stub for startupSnapshot.isBuildingSnapshot() — the only Bun-incompatible API call in the dependency chain:

Layer	Technology	Bun compat
ORM	Mongoose 9.x	✅ Works
Driver	mongodb npm package	✅ Works
Serialization	bson	✅ Shimmed — v8.isBuildingSnapshot() → returns false

Previously (pre-shim):

NotImplementedError: node:v8 isBuildingSnapshot is not yet implemented in Bun.
    at node_modules/bson/lib/bson.cjs:2610:30

Now: The bson package loads cleanly under Bun, and all MongoDB benchmarks pass (database-performance, transaction-acid, truth-latency, etc.) with no runtime differences from SQL adapters.

The benchmark matrix runner no longer needs special vitest dispatch for MongoDB — every database uses bun test uniformly.

SQLite

SQLite is embedded (no Docker tuning needed). For WAL mode (enabled by default in SveltyCMS):

Setting	Default	Recommended	Why
PRAGMA cache_size	-2000 (2 MB)	-64000 (64 MB)	Larger page cache reduces disk reads.
PRAGMA mmap_size	0 (disabled)	26843545600 (26 GB)	Memory-maps the database file for zero-copy reads.

These SQLite PRAGMAs are set automatically by SveltyCMS on connection — no manual action required.

High Performance Core vs Enterprise Compliance Mode (AUDIT_CHAIN_SYNC)

SveltyCMS supports two operational modes for audit logging and revision management:

1. High Performance Core (Default: AUDIT_CHAIN_SYNC=false):

   • Database writes (INSERT / UPDATE) return sub-5ms latencies directly to the caller.
   • Crypto SHA-256 Merkle-tree hash chaining, content revision snapshotting, and L2 cache invalidation pattern purges are dispatched asynchronously via microtask background queues.
   • Eliminates all write-path CPU & IO penalties, outperforming Payload, Directus, and Strapi on write benchmarks.

2. Enterprise Compliance Mode (AUDIT_CHAIN_SYNC=true):

   • Cryptographic SHA-256 audit chaining and revision creation run synchronously inside the database write transaction.
   • Ensures zero-latency audit durability and instant Merkle-tree verification for ISO 27001, SOC2, and EU GDPR regulated environments.

Metric	High Performance Core (false)	Enterprise Compliance (true)	Impact
Create Latency	~4.20 ms	17.66 ms	4.2x faster writes
Update Latency	~4.80 ms	23.82 ms	5.0x faster updates
Mixed RPS	2,800+ req/s	1,987 req/s	+41% throughput

Redis

Redis is used for caching layers (L2 cache, rate limiting, session store). In-memory — tuning focuses on eviction policy, persistence, and connection handling.

Setting	Default (Docker)	Recommended	Why
maxmemory	0 (no limit)	70-80% of available RAM	Prevents Redis from consuming all host memory under cache-heavy workloads.
maxmemory-policy	noeviction	allkeys-lru	Evicts least-recently-used keys when memory limit is hit. Prevents write errors on cache saturation.
tcp-keepalive	300s	60s	Detects dead connections 5x faster, freeing connection slots under concurrency.
timeout	0 (no timeout)	300s	Closes idle client connections after 5 minutes. Prevents connection leak accumulation.
maxclients	10000	20000	Default is generous; only raise if you see connection saturation.
save	3600 1 300 100 60 10000 (RDB snapshots)	"" (disable)	Disabling RDB persistence avoids fork pauses. Caution: trade durability for latency stability — acceptable when Redis is a cache (not primary store).
appendonly	no	no	Keep AOF off for cache-only Redis. Enabling adds fsync overhead with no benefit for ephemeral cache data.

Measured gains with all tweaks (Intel i7-13700H, Docker, redis-benchmark -c 10 -n 5000 -d 100):

Metric	Default	Tuned	Improvement
SET throughput	138,889 req/s	156,250 req/s	+12.5%
GET throughput	161,290 req/s	166,667 req/s	+3.3%
p50 latency	0.039ms	0.039ms	~same

Docker Compose override example (docker-compose.override.yml):

services:
  redis:
    command:
      - --maxmemory 2gb
      - --maxmemory-policy allkeys-lru
      - --tcp-keepalive 60
      - --timeout 300

Docker Compose Override — All Databases

Combine all overrides into a single docker-compose.override.yml alongside your existing compose.yaml:

services:
  mariadb:
    command:
      - --max_connections=500
      - --innodb_buffer_pool_size=4G
      - --innodb_log_file_size=512M
      - --innodb_io_capacity=2000
      - --innodb_flush_log_at_trx_commit=2

  postgres:
    command:
      - -c max_connections=400
      - -c shared_buffers=2GB
      - -c effective_cache_size=6GB
      - -c work_mem=32MB
      - -c wal_buffers=64MB
      - -c random_page_cost=1.1
      - -c synchronous_commit=off

  redis:
    command:
      - --maxmemory 2gb
      - --maxmemory-policy allkeys-lru
      - --tcp-keepalive 60
      - --timeout 300

Runtime Engine Tuning: Node.js 24 vs Bun 1.3+

SveltyCMS supports dual-target execution on both Node.js (>=24) and Bun (>=1.3):

                  ┌────────────────────────────────────────────────────────┐
                  │                 SveltyCMS Dual Engine                  │
                  └───────────────────────────┬────────────────────────────┘
                                              │
                     ┌────────────────────────┴────────────────────────┐
                     ▼                                                 ▼
        ┌─────────────────────────┐                       ┌─────────────────────────┐
        │   Node.js 24 Runtime    │                       │     Bun 1.3+ Runtime    │
        │       (index.cjs)       │                       │      (index.bun.ts)     │
        ├─────────────────────────┤                       ├─────────────────────────┤
        │ • Google V8 SIMD JSON   │                       │ • Native Bun.serve HTTP │
        │ • Mature Streams        │                       │ • Native bun:sqlite     │
        │ • Best for high JSON API│                       │ • Zero-copy WebSockets  │
        └─────────────────────────┘                       └─────────────────────────┘

Microbenchmark Comparison (Intel i7-13700H)

Operation / Primitive	Node.js 24 (V8)	Bun 1.3+ (JSC)	Winner	Notes
Bun.serve (Native HTTP)	—	14,290 req/s	🥇 Bun (+58%)	Zero-copy C++/Zig networking
node:http Server	9,022 req/s	12,048 req/s	🥇 Bun (+33%)	Emulated HTTP server
AsyncLocalStorage	Baseline	2.5× faster	🥇 Bun	Lightweight context propagation
HMAC-SHA256 (Crypto)	Baseline	2.6× faster	🥇 Bun	Native BoringSSL/Zig bindings
JSON.parse / JSON.stringify	1.9× faster	Baseline (JSC)	🥇 Node.js	V8 SIMD optimized JSON parser
bun:sqlite (In-Memory)	129k RPS	274k+ RPS	🥇 Bun (+112%)	Direct C FFI with zero Node binding tax

Choosing the Right Production Runtime

• Deploy on Node.js 24 (npm run start:node / node index.cjs) when:

  • You operate high-volume REST/GraphQL APIs with heavy JSON serialization and relational databases (PostgreSQL, MariaDB, MongoDB).
  • You deploy to traditional hosts (Plesk Passenger, Docker Node containers, AWS ECS).

• Deploy on Bun 1.3+ (bun run start:bun / bun index.bun.ts) when:

  • You use SQLite / Edge deployments (bun:sqlite delivers 274k+ QPS).
  • You utilize high-concurrency WebSockets / Yjs collaboration on /ws.
  • You need fast cold starts (<100ms) on serverless or container autoscale.

Hardware-adaptive profile (2026-08)

SveltyCMS detects the host machine once at process start and tunes every CPU-critical subsystem to it (@utils/hardware-profile → shared global registry → all modules/workers read the same object). The CMS runs lean on a 1-core VPS and fully parallel on a 24-core workstation — no config file required.

Global CPU budget — HARDWARE_CPU_BUDGET (default 0.75). The reserved share stays for co-hosted services on all-in-one deployments; set 1 when the app server is dedicated (managed/remote DB):

Deployment	Setting	Effect
All-in-one VPS (DB + Redis + nginx)	HARDWARE_CPU_BUDGET=0.75 (default)	25% headroom for the co-hosted stack
Dedicated app server (managed DB)	HARDWARE_CPU_BUDGET=1	CMS may use the full machine

Workload-prioritized allocation — each subsystem gets a share of the budget appropriate to its nature (media is bursty and CPU-hungry → largest slice; DB fan-out is most conservative so a co-hosted DB server never starves):

Subsystem	Share of budget	Env override	Notes
Media (sharp/libvips)	up to 50% of physical cores	SHARP_CONCURRENCY	12-way parallel variant pipelines saturate first — measured flat beyond this
DB pool (MariaDB/PG/Mongo)	2 queries per budget core	DB_POOL_SIZE	Conservative — every query burns CPU on the (possibly co-hosted) DB server
Module workers	50%, capped at 8	MODULE_WORKER_POOL_SIZE	Each worker loads a full module graph
Compile (content sync)	75%, capped at 32	COMPILE_CONCURRENCY	CPU-bound collection compilation
Jobs (background)	50%	JOB_CONCURRENCY	Keeps the request path responsive
libuv threadpool	logical cores	UV_THREADPOOL_SIZE	I/O threads block — they don’t steal CPU from co-hosted services
Mongo minPool	25% of budget, capped 10	MONGO_MIN_POOL_SIZE	Pre-spawned sockets scaled down on weak hosts
Compression	weak boxes: gzip 4 / br 4	—	Keeps CPU on the request path, not the ratio

The detected profile is surfaced in boot logs, the setup-wizard completion response, and /api/dashboard/system-info (dashboard CPU widget). GPU: sharp/libvips has no GPU backend — media parallelism is CPU-tier capped; further media gains come from variant dedup/deferral, not more threads.

---

---

Compliance Disclaimer: Based on publicly available documentation as of August 2026. [EU Directive 2006/114/EC]