Current Status and Open Issues

Current Status and Open Issues

Verified against commit c42e19eba on 27 August 2026. Update this marker whenever the implementation-facing inventory is refreshed.

MemCP is Beta. Core SQL, persistence, compression, parallel scans, REST, and MySQL-protocol access are usable, but compatibility and complex planner cases continue to evolve.

MemCP's stated ambition remains a fast, compact database for mixed OLTP and OLAP. Measured OLAP and search-oriented workflows have reached up to 10× the performance of MariaDB/PostgreSQL, particularly where RecSets and compressed column scans avoid wide intermediate rows. Isolated OLTP paths currently take about 1.3–2.0× as long, but in complete WordPress- and wiki-style page builds this has made no significant difference to overall page-loading time in the measured application workflows. A PostgreSQL filtered-list workflow over approximately one million documents, by contrast, took around 30 seconds. The OLTP gap is tracked as JIT, compilation, point-path and compatibility work rather than used to dilute the search/analytics performance proposition.

For write-heavy workloads, project measurements have reached about 10× safe throughput with ENGINE=logged. That result is inseparable from its durability trade-off: the WAL survives a process crash but is not synchronized against kernel crash or power loss. sloppy instead publishes compressed main storage on the normal 15-minute rebuild cycle, which can protect SD-card lifetime for reconstructible data while accepting loss of the unrebuilt delta.

Readiness by area

Area	Current position	What adopters should verify
SQL applications	Broad tested relational subset, views, CTEs/subqueries, UNION, windows, DML/DDL, constraints, triggers, and JSON	Every production query, collation/type edge, error expectation, and metadata query
Transactions/durability	Implicit/explicit transactions, cursor stability, snapshot/OCC infrastructure, per-table engines, WAL/replay	Required isolation/conflict patterns, power-loss behavior, backup and restore
Analytics	Compressed columns, batch/parallel scans, grouping/windows, adaptive indexes and reusable physical structures	Plans, memory, concurrent write latency, warm/cold performance
Interfaces	MySQL TCP/socket, SQL/HTTP, PostgreSQL-syntax HTTP, RDF, Scheme/custom HTTP/WebSocket	Concrete connector/tool versions, authentication, protocol assumptions
Operations	Dashboard, processlist/cancellation, settings, logs, packaging, local/S3/Ceph storage	Monitoring, capacity, upgrades, restore drills, backend outages
Scale-out	Local sharding and parallel execution within one instance	Multi-node cluster/HA is not implemented as a production feature

This page intentionally does not duplicate a static TODO list. Current bugs, planned work, and release blockers live in the GitHub issue tracker.

Product and engineering roadmap

The repository also contains design documents for longer-term work. They describe direction and invariants, not promised release dates:

• Broader JIT and vectorized execution: compile more scan filters, expressions, storage decoders and reducers into tight architecture-specific loops while retaining safe interpreter fallback.
• Lower compile time: bounded planner traversals, structural sharing and recipe-based physical emission for very large application-generated queries.
• Remote SQL tables: treat MySQL/PostgreSQL sources as scannable relations with explicit capability discovery, predicate/projection pushdown, transaction limits and safe fallback.
• Vector search: combine scalar partition boundaries with local vector “bubble” clusters and hierarchical top-k search.
• Cluster mode: leaderless CRUSH directory assignment, MOESI-inspired shard caches, RADOS persistence and remote partial scans; a later distributed catalog removes global registries for extremely large deployments.
• Specialized indexes and RecSets: choose ranges, sparse IDs, bitmaps, prefix/full-text and computed access paths according to observed density and cost.

See Cluster Monitor, Query Planner and Physical Lowering, RecSets, JIT Compilation, Vectors and Data Auto Sharding and Auto Indexing.

Implemented since the old status page

• per-table ALTER TABLE … ENGINE transitions;
• configurable LRU memory management and system-pressure eviction;
• AUTO_INCREMENT persistence and tested unique/not-null/foreign-key behavior;
• main/delta ordered index merging and LIKE/pattern access improvements;
• persistent SQL triggers and computed-column invalidation hooks;
• cursor-stability transactions plus ACID snapshot/OCC infrastructure;
• UNION, windows, views, broad subquery decorrelation, and join reordering;
• cost-based physical lowering, RecSets, group caches, ORC, and plan variants;
• native x86-64 Scheme JIT for supported procedures;
• processlist, query cancellation, dashboard, metrics, logs, and packaging;
• S3-compatible and optional Ceph/RADOS persistence;
• MySQL/PostgreSQL live import and PostgreSQL dump/archive import.
• native BSON-backed MySQL and PostgreSQL JSON support, including path access, mutation, constructors, aggregates, relational expansion, and computed-index acceleration.

Outcome of the earlier roadmap

The former status page was also a design record. The compact inventory below preserves what those concrete proposals became instead of silently deleting them when they left the TODO list.

Earlier proposal	Outcome
ALTER TABLE … ENGINE	Implemented for all five engines; persisted → memory is deliberately destructive and documented as such.
LRU cleanup for temporary columns	Expanded into budgets and eviction for reloadable columns, indexes, computed data, keytables, cache tables and dictionaries; memory-engine rows remain non-evictable.
Change hooks for computed columns	Implemented through SQL triggers and internal dependency/invalidation triggers for computed, grouped, prejoined and ordered data.
Enforced foreign keys	Implemented for tested CREATE TABLE RESTRICT, CASCADE and SET NULL paths; some ALTER compatibility forms remain non-operative.
One memory-mapped database-sized key/value file	Not adopted. MemCP keeps versioned per-column files and WALs, with optional object backends; selected subsystems may still use mmap internally.
Merge sorted index delta data with the main index	Implemented with a compressed main permutation plus an ordered index-local delta structure.
One multi-table scan_star/merge-join operator	Superseded by reordered logical join trees and costed nested, indexed, ordered, RecSet, cached and parallel physical paths.
Process IDs, request context and kill switch	Implemented through PROCESSLIST, dashboard controls, KILL QUERY/CONNECTION and cancellation-aware waits.
Transaction insert/delete overlays and conflicts	Expanded into cursor-stability handling plus snapshot/OCC infrastructure, rollback, visibility and commit conflict checks.
LIKE indexes	Implemented as prefix/match boundaries with residual predicates whenever the boundary is only a candidate set.
SPARQL updates and OPTIONAL	Implemented for the tested DELETE/INSERT/WHERE, template and OPTIONAL subset; this is not complete SPARQL coverage.
AUTO_INCREMENT persistence	Implemented, including restart and ALTER behavior.
Convert subqueries into joins	Expanded into logical decorrelation of scalar, IN/NOT IN and EXISTS/NOT EXISTS forms before join ordering.
Shard group tables and prejoin complex plans	Implemented as costed physical alternatives alongside direct scans, FK/PK reuse, group caches and RecSets.
Restrict users to databases	Implemented through system users, grants, revokes and frontend enforcement.
DBeaver/phpMyAdmin metadata compatibility	Ongoing and version-specific; protocol, prepared statements, SHOW and selected INFORMATION_SCHEMA relations exist.
Native Scheme JIT	Implemented for supported x86-64 procedures with interpreter fallback.
Arbitrary HTTP/IPFS stream filenames	Not generally implemented; local files and supported archive paths are the documented contract.
Stable native C++/GPU plugin ABI	Not implemented; internal extension hooks are not a promised public plugin ABI.

The earlier multi-phase JSON plan is now represented by the implemented capability inventory in JSON and Supported SQL. Keeping it labelled as future work here would be misleading.

Areas still requiring verification

• complete MySQL/PostgreSQL grammar and metadata compatibility;
• rare correlated, outer-join, UNION, window, and three-valued-logic shapes;
• high-contention transaction behavior and long-running repartition/rebuild work;
• compatibility of individual ORMs and administration tools;
• platform coverage outside the main Linux/x86-64 development path;
• reproducible performance results across representative workloads.

Reporting a problem

Include the MemCP commit/version, schema, minimal query, expected result, actual result, ENGINE mode, frontend, and whether the problem reproduces after restart. For performance reports include row counts, EXPLAIN output, cache state, hardware, concurrency, raw timings, and a current-master comparison.