ormDB for Content Management Systems
ormDB handles CMS workloads with graph fetches that load hierarchical content trees in single round-trips, built-in BM25 full-text search for content discovery, and safe migrations (A-D grading) that let content schemas evolve without downtime.
CMS data is hierarchical and relational
Content management systems model pages with sections, blocks, media attachments, authors, categories, and tags. Loading a single page requires traversing a deep tree of related content. With traditional databases, this means either N+1 queries or complex recursive SQL.
ormDB for content trees
ormDB is a relational database engine where graph fetches are the primary query primitive. A page load that fetches the page with its sections, blocks, and media is one query. The database understands the content tree structure natively.
Full-text search across all content is built in. No separate search infrastructure. Safe migrations let content schemas evolve as content types change — you see the impact grade before running any migration. ormDB integrates with ORMs like Prisma and Django for familiar CMS development workflows.
Loading a full page in one round-trip
A published article page — with its author, ordered sections, embedded media, category, and tags — is a single graph fetch instead of a cascade of lookups:
graph_fetch Page (slug = "launch-announcement", status = "published") {
title, slug, publishedAt,
author { name, avatarUrl },
sections [order: position] {
kind, body,
media { url, alt, width, height }
},
category { name, slug },
tags { name, slug }
}The database returns the entire content tree assembled and ready to render. There is no recursive CTE, no manual join stitching, and no N+1 fan-out as your page templates grow more nested.
Modeling reusable content blocks
Modern CMS platforms favor composable, block-based content. In ormDB you model each block type as an entity and connect them to pages through a native one-to-many relation, so reordering, reusing, and versioning blocks are ordinary relational operations. Because relations are first-class, a block referenced by many pages stays a single source of truth rather than duplicated JSON. See schema design patterns for structuring these relationships.
When another database fits better
ormDB is in Alpha (v0.1.0). If your CMS depends on a mature managed offering, PostgreSQL-specific extensions, or a large ecosystem of off-the-shelf plugins today, a proven database like PostgreSQL or a platform like Supabase is the safer production choice for now. ormDB is the strongest fit when deeply nested content trees, native search, and safe schema evolution are your primary pain points.
Frequently Asked Questions
How does ormDB handle hierarchical content?
Graph fetches load content trees with nested sections, media attachments, and metadata in a single query. No recursive SQL CTEs needed — ormDB understands the relation graph natively.
Can ormDB replace Elasticsearch for content search?
For most CMS search needs, yes. ormDB includes BM25-ranked full-text search with phrase matching, boolean queries, and stemming built into the engine, so your content and its search index live in one database instead of a separate Elasticsearch cluster you have to keep in sync.
How do content schemas evolve safely in ormDB?
Every migration is graded A to D before it runs. Adding a new nullable field to a content type is Grade A and applies instantly; renaming or dropping a field is flagged as Grade C or D so an editorial-schema change never silently deletes published content.
Does ormDB work with headless CMS frameworks?
Yes. ormDB is the database layer, so any headless CMS or custom content API built on Prisma, Django, or another supported ORM can point at ormDB instead of PostgreSQL. Your content models, GraphQL/REST resolvers, and admin tooling stay the same.
How does ormDB serve draft and published content?
Model a status field and a publishedAt relation on your content entities, then filter graph fetches by status. Because relations are native, a single fetch can return a published page with only its published sections and approved media, enforced consistently across your API.