Explanation · Design contract
Pinega Engine architecture
This page explains accepted architectural boundaries. It is not an installation guide and does not imply that every mechanism below is already implemented or benchmarked.
PostgreSQL integration
Pinega Engine is designed to enter PostgreSQL through extension APIs, especially the Table Access Method boundary. PostgreSQL remains responsible for SQL-visible transaction identity, snapshots, and surrounding executor/catalogue integration. The extension side should keep a narrow explicit C ABI around Rust/pgrx and pg_sys interactions.
Mutable version store
The OLTP path uses out-of-place row versions in Pinega-owned persistent files rather than PostgreSQL heap blocks. Visibility metadata is explicit so version evaluation, handles, and later SIMD processing can be designed around the engine's own representation.
The analytical immutable Vortex-based direction is a later programme layer and is not merged into the OLTP MVP.
Pinega-owned shared buffer pool
Because the mutable store uses custom persistent files rather than PostgreSQL blocks, Pinega owns the corresponding shared-memory buffer pool. The research direction includes stable frames, generation/version handles, protect-or-pin plus revalidate, explicit retirement/reclamation, and cache/coherence/NUMA-aware placement.
Lock-free and wait-free mechanisms are research and implementation targets, not a blanket claim that the production buffer manager already satisfies those progress guarantees.
Durability: one PostgreSQL WAL
Accepted decision
PostgreSQL WAL remains the single write-ahead logging and commit boundary. The MVP may log complete tuple images; logical replication is in scope, while physical standby and aggressive GC/space reuse may follow after the core path is validated.
This prevents a second independent WAL-like commit protocol from becoming an accidental distributed durability problem inside the extension.
Architecture is not performance evidence
The architecture proposes mechanisms intended to improve OLTP behaviour and make concurrency lifetimes explicit. Performance, scalability, crash-safety, and PostgreSQL-compatibility claims require implementation plus benchmark and correctness evidence before they can be promoted.
The public Technology summary owns the portfolio-level view; the Research catalogue owns active questions and evidence.