Forma FAQs
Short answers to the questions that come up most about online DDL, JSONB, MongoDB, and the EAV "anti-pattern," plus where Forma sits: one JSON Schema drives validation, storage, and CRUD APIs, and pushes data into the lakehouse for OLAP.
What is Forma's positioning?
Forma simplifies backend work end to end. One JSON Schema defines storage and validation, drives hot-table and EAV writes, exposes frontend-friendly querying and CRUD APIs, and feeds CDC into the lakehouse for OLAP (Intro, Part 3).
Forma is not trying to be another database. The point is to put field changes, type safety, query performance, and lakehouse integration on one development path, with as little friction as possible.
Databases have online DDL, so why bother with Forma?
Online DDL reduces locking, not the delivery path. Code changes, index design, and regression testing still take hours or days, while AI fields change daily across 10-50 variants, a mismatch that Part 1 explains in Flexibility without DDL.
In Forma, adding a field means updating JSON Schema metadata. Writes take effect immediately, with no table or index changes.
Beyond avoiding DDL, what workflow does Forma change?
AI apps already need JSON Schema to steer LLM output and define API contracts. Forma reuses that single schema for type validation and storage mapping, so there's no duplicate modeling or migration (Part 1).
In CRUD, the schema decides which fields get a real B-tree column in the hot table, which means fewer hand-written mappers. On the data path, CDC replicates the same rows to Parquet and DuckDB, so OLAP doesn't need a second derived model (Part 3).
PostgreSQL has JSONB with GIN/B-tree, so what's the issue?
Range or sort on JSONB still requires an expression index, and that's DDL again (Part 1). Worse, a partial update rewrites the whole blob, inflating WAL and replication cost (see write amplification). And JSONB features tie you to PostgreSQL, which makes moving across databases or cloud services harder (Part 1).
Forma instead uses pre-indexed typed hot columns: mapping a field is a metadata-only change through JSON Schema, and the EAV layer stays plain, portable SQL.
Why not just use MongoDB?
MongoDB suits schema-free document workloads. Forma is the better fit when you need SQL JOINs, full ACID, the PostgreSQL ecosystem, and low-cost cold storage (Part 1). Cold data lands in Parquet and DuckDB with predictable cost and consistency controls (Part 3).
Isn't EAV an anti-pattern? How does Forma avoid the traps?
The hot table materializes the hottest ~20% of fields as real columns with B-tree indexes, so range and sort queries avoid full scans (Part 1). N+1 is handled by a single CTE that aggregates with JSON_AGG: 101 round-trips become 1; Part 2 has the derivation. The cold/hot split keeps consistency: DuckDB and Parquet hold history, while Anti-Join plus a Dirty Set keep federated queries free of dirty reads (Part 3).