Every few years someone predicts the end of SQL. Then the replacement grows a query language, then transactions, then indexes — and the industry quietly rediscovers why the relational model survived: it separates what you want from how it is stored, and it gives concurrent writers rules everyone can reason about. PLOMID starts from that foundation rather than around it.
Why SQL endures
SQL is a contract between the application and the storage underneath. The application states predicates, joins, and aggregates; the engine decides access paths, join order, and layout. That separation is what lets a storage engine improve — better indexes, smarter pruning, tighter pages — without rewriting a single application query.
It is also the most portable skill in data infrastructure. Choosing SQL as the primary surface means every developer, every driver, and every migration tool keeps working. The platform page states this directly: familiar surfaces first, new models second.
Transactions you can reason about
The unit that matters is the transaction. In PLOMID, multi-statement writes group under BEGIN … COMMIT, with ON CONFLICT handling idempotent inserts and RETURNING echoing what was written:
BEGIN;
INSERT INTO customers (id, name, tier) VALUES (42, 'Acme Foundry', 'pilot')
ON CONFLICT (id) DO UPDATE SET tier = EXCLUDED.tier;
INSERT INTO orders (id, customer_id, total) VALUES (9001, 42, 18400.00);
COMMIT;Reads run under snapshot isolation at read committed: readers see a consistent snapshot and never block writers. Two honest boundaries apply in the current version — standalone SAVEPOINT is a parse error, and a rollback inside an explicit transaction is a full rollback, so transactions should be designed retryable from the start. The transactions documentation records both.
Indexes and access paths
An index is a promise about how a query narrows its work before touching a row. PLOMID keeps two structures with clearly separated jobs: a durable B-tree that remains the authority for lookups, ranges, and uniqueness, and a transient in-memory ART for fast paths that can always be rebuilt.
CREATE INDEX orders_customer_ts ON orders (customer_id, placed_at);
EXPLAIN SELECT id, total FROM orders
WHERE customer_id = 42 AND placed_at > now() - INTERVAL '30 days';EXPLAIN shows the chosen path before the query runs — predicate, index, and scan shape — which is how you confirm the planner sees what you think it sees. Time-ordered predicates additionally prune through zone maps before any page is read, as described in Bringing SQL and JSON Workloads Together.
How a statement executes
Every statement travels the same stages, in the same order:
| Stage | What happens |
|---|---|
| Parse | The text becomes a structured statement; syntax errors stop here. |
| Plan | Predicates, join order, and access paths are chosen once. |
| Snapshot scan | Rows are read under a fixed snapshot; concurrent writes do not disturb the read. |
| Evaluate | Predicates, projections, aggregates, and ordering run per row. |
| Persist | Writes go to the WAL first, then to pages; only committed data becomes visible. |
No stage is skipped and none is special-cased per model — the same pipeline serves rows, documents, and events, which is the subject of Building a Unified Data Layer for Modern Applications.
Where SQL meets the rest
SQL is the foundation, not the ceiling. The same transaction that inserts an order row can carry a JSON payload beside it; the same table can hold a TIMESTAMPTZ column that time-window queries prune efficiently. Each of those directions is covered in its own note — documents, time-ordered data, and the storage layout underneath them all.
The rule for all of it: SQL semantics stay boring on purpose, so the interesting parts can happen elsewhere.
