Skip to main content
Pinega
Use dark theme Menu

Technology programmes

Research becomes technology only after its boundaries survive implementation.

Pinega groups related database-systems work into programmes with explicit maturity, evidence, and product intent. Pinega Engine is the first active implementation programme; the other directions remain research or portfolio candidates.

RESEARCH MODEL IMPLEMENT MEASURE PRODUCT

Current portfolio map

Programmes are named by ownership and evidence, not by marketing ambition.

No item below is presented as a shipped product unless a runnable, supported release and measured claim exist.

Active design

Pinega Engine

An extension-oriented PostgreSQL OLTP engine with out-of-place versions, Pinega-owned persistence and buffer management, and one PostgreSQL WAL boundary.

Architecture and decisions
Research

Query optimisation and AI

Cardinality reasoning, decorrelation, dependency-driven rewrites, materialised views, recursive queries, and MCTS/RL join-order selection.

Research areas
Research platform

Correctness and verification tooling

Executable histories, deterministic testing, lifecycle models, semantic diagrams, and future tools for concurrent and transactional correctness.

Research method
Portfolio direction

Distributed systems

Replication, consensus, clocks, distributed transactions, failure models, and MPP execution remain research directions without a committed product boundary.

Research areas

Pinega Engine

An OLTP architecture with explicit storage, lifetime, and durability contracts.

This is an accepted programme direction for PostgreSQL 19. Individual mechanisms remain subject to implementation and measurement.

  1. 01
    PostgreSQL integrationExtension-only Table AM boundary, callbacks, snapshots, transaction identity, and SQL-visible behaviour
    target
  2. 02
    Mutable version storeOut-of-place versions, explicit visibility metadata, stable identities, and postponed analytical storage
    design
  3. 03
    Pinega buffer poolShared-memory frames, protect/pin/revalidate, cache-aware placement, retirement, and reclamation
    research
  4. 04
    PostgreSQL WALOne authoritative durability and transaction-commit pipeline for the current architecture
    decision
The OLAP/Vortex direction is deliberately excluded from the OLTP MVP and remains a later programme boundary.

Accepted boundaries

Current decisions are explicit, but implementation maturity remains visible.

One PostgreSQL WAL

The current engine architecture uses PostgreSQL WAL rather than creating a second independent commit and durability subsystem.

Extension-only first

The active direction targets PostgreSQL 19 through supported extension boundaries and a narrow C ABI around Rust/pgrx code.

Performance remains a hypothesis

Version layout, cache behaviour, contention, recovery, and operational cost must be measured against PostgreSQL heap and relevant engines.

Promotion rule

A programme becomes a product only after six boundaries are credible.

  1. 01
    Novelty

    The capability is meaningfully differentiated from upstream and existing products.

  2. 02
    Correctness

    Safety, progress, durability, and failure assumptions are stated and tested.

  3. 03
    Performance

    Representative benchmarks demonstrate value without hiding operational costs.

  4. 04
    Product boundary

    Users, workloads, compatibility, deployment, support, and non-goals are explicit.

  5. 05
    Maintainability

    CI, reproducible builds, observability, documentation, and upgrade paths exist.

  6. 06
    Commercial fit

    Licensing, IP, customer value, and portfolio ownership support a sustainable offering.

Follow the evidence

Research explains the claims; documentation explains what works today.

The technology catalogue intentionally separates active design, research infrastructure, and portfolio directions.

Research Documentation