Skip to content

Documentation

Database Documentation Hub

Central hub for SveltyCMS database architecture β€” 4 production adapters, findPage/hasMore, count modes + cache, allocation-floor engine, and zero-tax LocalCMS.

8/4/2026
5 min read Edit on GitHub

Welcome to the SveltyCMS Database Engine documentation. Our architecture is built on the principle of Strict Agnosticism, allowing you to swap between NoSQL and Relational engines without changing a single line of application logic.


πŸ“š Documentation Structure

1. Database-Agnostic Architecture

  • Core Infrastructure β€” db.ts lifecycle, self-healing proxy, plugin-registry topological boot, LocalCMS SDK
  • Database Methods Interface β€” IDBAdapter namespaces: auth, crud, content, media, system, batch, collection
  • Database Resilience β€” Error handling, retry logic, circuit breaker, connection health monitoring
  • Performance Architecture β€” findPage / count modes / count cache (equal on all engines), allocation-floor, schema-aware conversion, ring-buffer pools

2. Engine Implementations

  • SQLite Implementation βœ… Platinum β€” Default for local/edge. Sub-ms CRUD, WAL mode, zero network overhead.
  • PostgreSQL Implementation βœ… Production β€” Enterprise scaling, native JSONB, GIN indexing, PgBouncer support.
  • MariaDB Implementation βœ… Production β€” High-concurrency pooling via mysql2, shared findPage / count estimate path.
  • MongoDB Implementation βœ… Production β€” NoSQL engine, safeQuery security, wire compression.

πŸ—οΈ Architecture Overview

graph TD subgraph App["Application Layer"] B[Routes / Components] C[Business Logic] end subgraph Core["Database Manager (db.ts)"] D[Self-Healing Proxy] E[Double-Check Boot: IDLE β†’ READY] end subgraph Interface["IDBAdapter (db-interface.ts)"] F[7 Namespaced Interfaces] G[DatabaseResult Contract] end subgraph Adapters["4 Production Engines"] H[(MongoDB)] I[(MariaDB)] J[(PostgreSQL)] K[(SQLite)] end B & C --> Core Core --> Interface Interface --> H & I & J & K

Shared list & count contract (all adapters)

API Default product use Benefit
crud.findPage Admin/API lists (total: "none") One query; hasMore via limit+1 β€” no COUNT
crud.count({ mode }) Badges / dashboards exact | estimate | auto
Count L1 cache (30s) Repeated tenant counts ~0.024 ms hits after warm (all engines)

Details and measured gains: Performance Architecture Β· method signatures: Database Methods.


πŸ›‘οΈ Shared Security Principles (All Adapters)

  • 4-Layer Defense-in-Depth: Middleware β†’ Dispatcher β†’ Handler β†’ Page Action

  • Tenant Isolation: Every query scoped by tenantId at adapter level β€” architecturally impossible to bypass

  • Credential Hashing: Website tokens and API keys are stored as SHA-256 digests only; plaintext is returned once on creation. See system.websiteTokens.

  • Tenant-Scoped Bearer Lookup: Auth passes locals.tenantId into credential lookups (aligned with auth.getApiKey) to narrow multi-tenant queries.

  • MongoDB Soft-Delete Safety: safeQuery() applies isDeleted: { $ne: true } so legacy documents without the field remain visible to active queries.

  • SSRF Prevention: Cloud storage adapters validate endpoints before connection

  • NoSQL Injection Protection: sanitizeMongoQuery blocks $where, $function, $expr

  • CSPRNG-Only Tokens: globalThis.crypto.getRandomValues(), no Math.random() fallback

  • Fail-Closed API: Unmapped namespaces return 403 by default

πŸ”„ Shared Resilience Patterns (All Adapters)

  • Circuit Breaker: 5 consecutive failures β†’ 60s open β†’ probe recovery
  • Self-Healing Reconnection: Auto-recovery on connection loss + HMR reload
  • Exponential Backoff with Jitter: 1sβ†’2sβ†’4sβ†’8sβ†’16s, Β±500ms
  • Connection Pool Diagnostics: GET /api/database/pool-diagnostics + dashboard widget β€” see Database Resilience
  • Migration Safety: CREATE TABLE IF NOT EXISTS β€” idempotent

⚑ 2027 Allocation-Floor Optimizations

Optimization SQLite PostgreSQL MariaDB MongoDB
Schema-aware row conversion βœ… βœ… βœ… N/A
Ring-buffer result pool (64 slots) βœ… βœ… βœ… βœ…
Conditions array pool (32 slots) βœ… βœ… βœ… N/A
Fused mapQuery (no IR objects) βœ… βœ… βœ… βœ…
for…in (zero Object.entries) βœ… βœ… βœ… βœ…
Pre-allocated meta object βœ… βœ… βœ… βœ…
MariaDB double-parse isolated N/A βœ… Benefit βœ… N/A
Prepared-statement cache βœ… N/A (driver) N/A (driver) N/A
Projection (fields β†’ skip data) βœ… βœ… βœ… βœ… (driver)

SQL family: ~5-8 fewer allocations per filtered query. MongoDB: ~2-3 fewer (result pool + fused mapQuery). All 4: benefit from shared BaseAdapter optimizations.

πŸ“ˆ Performance Benchmarks (SQLite, Latest)

Operation Latency RPS
FIND ONE 0.090 ms 10,386
DELETE 0.051 ms 14,447
Peak Throughput β€” 15,617 req/s
LocalCMS SDK Overhead β€” 0.00%

Full cross-database benchmarks: Performance Benchmarks.

Adapter Selection Guide

Scale Recommended DB Why
Dev, edge, small teams SQLite (default) In-process, zero network, sub-ms CRUD
Production single node PostgreSQL JSONB, FTS, replication ready
Enterprise / K8s PostgreSQL + PgBouncer + Redis Horizontal scale, cross-node invalidation
Global / multi-region PostgreSQL + replicas + CDN Read replicas, geo-distribution

MongoDB for unstructured/high-volume. MariaDB for MySQL-compatible setups (planned). SQLite, PostgreSQL, and MongoDB are production-ready.


Last Updated: 2026-06-22 (website-token credential hardening, safeQuery soft-delete fix, parallel SQL list+count) Maintained by: SveltyCMS Team

databasearchitecturehub
Was this page helpful?