NewDB: Redesign Strategies in Database Systems

• NewDB is a polysemous term that defines various next-generation database designs, encompassing distributed SQL with ACID guarantees, native HTAP, specialized storage, and even computational knot invariants.
• It replaces conventional boundaries between OLTP/OLAP, DBMS/ML stacks, and standard storage engines by integrating adaptive architectures and near-data machine learning, as demonstrated by notable performance boosts.
• The literature reveals both promising outcomes, such as tenfold speedups and significant space reductions, and inherent limitations in empirical evaluation and fully realized system integration.

Searching arXiv for papers using “NewDB” and closely related terms to ground the article. NewDB is not a single standardized artifact in the arXiv literature. The label is used in several distinct but structurally related ways: as shorthand for a next-generation relational or transactional DBMS that combines SQL and ACID semantics with scale-out execution; as a “native” architecture in which machine learning, hybrid transactional/analytical processing, or other domain logic is moved into the DBMS core; as a workload-specialized storage engine that replaces a generic key–value substrate with a native physical design; and, in a mathematically unrelated usage, as a computational database of knot invariants. What unifies these uses is not a common code base, but a recurrent design move: replacing a legacy boundary—between OLTP and OLAP, DBMS and ML stack, authenticated structure and storage engine, or tabulated values and inequality propagation—with a new internal representation better matched to the target problem (Moniruzzaman, 2014, Kang et al., 2023, Jordan et al., 4 Dec 2025, Jablonowski, 21 May 2026).

1. Scope of the term

In the surveyed literature, “NewDB” is best understood as a polysemous research term. In database systems papers, it typically denotes a new generation of DBMS design beyond conventional monolithic RDBMSs and beyond purely non-relational NoSQL stores. In other work, however, the same label names a concrete database artifact with a narrower domain, such as a knot-theoretic repository constructed by computational propagation of inequalities (Moniruzzaman, 2014, Jablonowski, 21 May 2026).

Usage of “NewDB”	Representative paper	Core object
Scale-out relational DBMS / NewSQL	"NewSQL: Towards Next-Generation Scalable RDBMS for Online Transaction Processing (OLTP) for Big Data Management" (Moniruzzaman, 2014)	SQL- and ACID-preserving distributed OLTP system
Native HTAP architecture	"NHtapDB: Native HTAP Databases" (Kang et al., 2023)	Unified OLTP, OLAP, and near-data ML engine
Architecture-less or autonomous DBMS	"AnyDB: An Architecture-less DBMS for Any Workload" (Bang et al., 2020); "NeurDB: An AI-powered Autonomous Data System" (Ooi et al., 2024)	Runtime-adaptive or AI-native DBMS
Native workload-specific storage engine	"A Fast Ethereum-Compatible Forkless Database" (Jordan et al., 4 Dec 2025); "High Performance Negative Database for Massive Data Management System of The Mingantu Spectral Radioheliograph" (Shi et al., 2017)	Specialized physical storage for a target workload
Knot-invariant database	"Integer Knot Invariants: Inequalities, Computations, and Open Problems" (Jablonowski, 21 May 2026)	Database of 33 integer-valued knot invariants

This multiplicity matters because the same term can refer either to a systems-level architectural program or to a specific domain database. A common misconception is that “NewDB” denotes one canonical post-SQL architecture. The literature here does not support that reading. It supports, instead, a family resemblance across redesign efforts.

2. NewDB as next-generation relational infrastructure

The most conventional systems use of the term is the one associated with NewSQL. In that formulation, NewSQL is “a class of modern relational database management systems (RDBMS) that provide the same scalable performance of NoSQL systems for online transaction processing (OLTP) read-write workloads while still maintaining the ACID guarantees of a traditional database system” (Moniruzzaman, 2014). The architectural features emphasized in this strand include distributed shared-nothing deployment, a three-tier organization into administrative, transactional-and-SQL, and storage-and-durability tiers, high per-node performance, in-memory relational processing, and “a non-locking concurrency control mechanism so real-time reads will not conflict with writes” (Moniruzzaman, 2014).

A more radical extension of this program appears in AnyDB. Rather than fixing shared-nothing, shared-disk, or shared-memory as a system identity, AnyDB proposes an “architecture-less” DBMS built from stateless AnyComponents driven by two streams: an event stream describing what to do and a data stream carrying the required state. By changing routing on a per-query basis, the system can mimic different architectures without reconfiguration, and its initial results report significant speed-ups across varying workloads relative to a static architecture (Bang et al., 2020). In this usage, NewDB does not merely scale out SQL; it turns architecture selection itself into a runtime optimization variable.

The “Intensional RDB” manifesto gives a different, logic-centered formulation of the same redesign impulse. It preserves the user-defined relational schema and SQL interface while parsing all standard RDB data into a single internal vector relation,

$$r_V(\texttt{r-name}, \texttt{t-index}, \texttt{a-name}, \texttt{value}),$$

so that relational tables become an “empty global schema” over a key/value-like physical substrate (Majkic, 2014). Query execution is then mediated by a GAV-style rewriting algorithm that rewrites SQL over the user schema into SQL over the vector relation. This design is explicitly framed as a unifying NewSQL model for Big Data and “Open schema” settings (Majkic, 2014).

Odysseus/DFS represents a more conservative but fully implemented route. It integrates a full relational DBMS with a distributed file system by replacing the storage manager and transaction manager with a Meta DFS File Manager and a DFS Transaction Manager, while leaving higher DBMS layers intact (Kim et al., 2014). Its key abstraction is the meta DFS file, an ordered set of one-block DFS files that gives a page-based DBMS the illusion of overwriteable files on top of a write-once distributed file system. The system preserves SQL, schemas, secondary indexes, and ACID transactions, while adopting a concurrency model that is serial with respect to write transactions and concurrent for read-only transactions (Kim et al., 2014).

Taken together, these systems show that “NewDB” in the relational sense is not one architecture but a design family. One branch keeps the classical DBMS stack and replaces the storage substrate; another replaces the architecture model itself; a third keeps SQL while virtualizing the physical schema beneath a uniform vector relation.

3. Native HTAP and AI-native interpretations

A second major use of NewDB concerns “native” systems that collapse boundaries between transaction processing, analytics, and machine learning. NHtapDB is explicitly presented as a “native HTAP” database, in which OLTP and OLAP are handled in one engine tailored to hybrid workloads, machine learning is embedded “near the data” inside the DBMS process, and storage uses a mixed-format layout rather than a dual-format row/column replica scheme (Kang et al., 2023). Its primary goals are real-time business insight, near-data machine learning, and true HTAP support for workloads in which OLAP queries run in-between online transactions.

The computation layer adds a near-data machine learning engine alongside a stateless SQL compute engine. The ML workflow is modeled as a reinforcement-learning loop with state $S$, action $A$, and reward $R$, and the recommendation module receives a weighted multi-dimensional reward

$$R^t = \beta + \lambda_1 R_p^t + \lambda_2 R_c^t + \lambda_3 R_{\text{text}}^t + \lambda_4 R_{\text{image}}^t + \lambda_5 R_r^t + \lambda_6 R_i^t$$

constructed from portrait alignment, click feedback, text and image query satisfaction, additional labels, and item-side information (Kang et al., 2023). Online learning is then driven by tuples $(S^t, A^t, R^t, S^{t+1})$, with training triggered by predefined change thresholds. The storage layer complements this with a mixed-format store that range-partitions tables into row groups and splits each group into row-based update partitions and column-based non-update partitions, thereby avoiding the row-to-column propagation overhead of dual-format HTAP systems (Kang et al., 2023).

NeurDB pushes this native interpretation further into an explicit AI×DB program. It is described as “an AI-powered autonomous data system designed to fully embrace AI design in each major system component and provide in-database AI-powered analytics” (Ooi et al., 2024). The architecture is organized around four pillars: an in-database AI-friendly ecosystem, an intelligent self-driving data system, privacy-preserving and trusted AI×DB, and automated performance modeling and validation. Its optimizer generates candidate plans by mutating cardinality estimates and then applies a Decision Transformer with hyper-networks and adapter layers for fast-adaptive plan selection. Its AI analytics layer provides model training, model selection, model slicing, and model fusion inside the database, and its self-driving layer applies the Filter-and-Refine Principle to optimization, concurrency control, and resource management (Ooi et al., 2024).

In these papers, NewDB no longer means merely “distributed SQL with ACID.” It means that inference, online learning, model lifecycle management, and workload adaptation become first-class DBMS concerns. A plausible implication is that the classical distinction between database kernel and surrounding application stack is being treated as an optimization barrier rather than as a principled system boundary.

4. Native storage specialization and nontraditional representations

A third usage of NewDB centers on native physical design for a narrowly specified workload. The Ethereum-compatible forkless database of 2025 is exemplary here. Its motivating observation is that Ethereum’s Merkle–Patricia Trie StateDB is a multi-version, append-only, copy-on-write authenticated structure designed for a forking chain, while fast-finality BFT or DAG-based chains are effectively linear and do not require multiple active state versions (Jordan et al., 4 Dec 2025). The proposed replacement is a native database implementation specialized for non-forking blockchains while maintaining Ethereum compatibility.

Its live state engine, LiveDB, is a mutable single-version trie whose nodes carry numeric IDs supplied by a persistence layer backed by file-mapped arrays. Node access is thereby reduced from the compounded trie-over-key–value-store behavior of Geth-style systems to direct indexed lookup, while hash computation remains Ethereum-compatible because nodes are still hashed as RLP-encoded structures with Keccak (Jordan et al., 4 Dec 2025). For validators, the paper reports ten times speedups and 99% space reductions; for archive nodes, it reports a threefold decrease in storage requirements (Jordan et al., 4 Dec 2025). The paired ArchiveDB then preserves block history in an append-only DAG-structured archive, storing one hash per node rather than duplicating child hashes in parents.

The negative database proposed for the Mingantu Spectral Radioheliograph exemplifies a different kind of specialization. Here the database does not store every observational record explicitly. Instead it stores a compact description of the normal structure of the data and the complement set of missing records. Formally, with universal set $F$, actual dataset $A \subseteq F$, and complement set $B = F \setminus A$, “if we can use $B$ to calculate $S$0, the database of $S$1 is a negative database” (Shi et al., 2017). The implementation uses a two-level key–value design over Redis or MySQL: minute-level keys map to file-level information, while file-level keys map to continuous frame runs and cumulative lost-frame counts. On a dataset of 406 real observational files from MUSER-I containing 7,795,200 frames, the RDBMS representation stored 7,795,200 records and used 843.3 MB, whereas the negative database contained only 812 records and occupied about 153 KB (Shi et al., 2017). Retrieval remained faster than the RDBMS for the tested real-data loss regime, but performance degraded with higher frame-loss ratios and became worse than the RDBMS at 5% loss (Shi et al., 2017).

These systems share an important characteristic: they do not primarily generalize the DBMS abstraction. They specialize it. One exploits forkless finality to eliminate unnecessary multi-version state and key–value indirection; the other exploits regular time-series structure and low anomaly rate to store a complement rather than a positive relation. In both cases, “native” means that the physical representation is derived from workload invariants rather than inherited from a general-purpose storage engine.

5. NewDB in knot theory

In a mathematically distinct usage, NewDB is a computational database of integer knot invariants. It is constructed from existing tabulated data, primarily KnotInfo, and then tightened by iterating a system of inequalities and parity constraints for all knots with at most 13 crossings (Jablonowski, 21 May 2026). The resulting database stores values or bounds for 33 integer-valued invariants spanning crossing-type and diagrammatic invariants, four-dimensional invariants, homological concordance invariants, and polynomial-derived invariants.

Its organizing structure is a directed graph with 33 vertices and 47 edges, where each edge corresponds to a proved inequality of the form

$S$2

for all nontrivial knots $S$3 (Jablonowski, 21 May 2026). The computational procedure seeds the database from KnotInfo for 19 invariants, adds six more from the literature, treats the remaining eight as unknown integer variables, and then performs iterative constraint propagation in SageMath until a fixed point is reached. Parity constraints sharpen intervals further, so the database stores either exact values or intervals $S$4 for each invariant and knot (Jablonowski, 21 May 2026).

This NewDB produced substantial concrete results. The paper reports 232 updates to non-empty KnotInfo cells for the unknotting number $S$5 and doubly slice genus $S$6, including 139 new exact values: 36 new exact unknotting numbers and 103 new exact doubly slice genera (Jablonowski, 21 May 2026). It also uses NewDB as a search engine for structural relations among invariants, identifying a set $S$7 of 50 conjectural inequalities and a subset $S$8 of 18 basic conjectures that are not transitive consequences of the others (Jablonowski, 21 May 2026).

Here NewDB is not a database system architecture at all. It is a mathematically curated and propagated knowledge base. The relevant design move is still recognizably “database-like,” however: disparate partial information is normalized into a common invariant space and then saturated under a constraint system until no further improvement is possible.

6. Common themes, distinctions, and limitations

Across these literatures, NewDB repeatedly denotes an attempt to dissolve a legacy systems boundary by moving more semantics into the core representation. In NewSQL and Odysseus/DFS, the boundary is between full relational functionality and scale-out infrastructure. In AnyDB, it is between architecture choice and execution. In NHtapDB and NeurDB, it is between DBMS execution and machine learning. In SonicDB, it is between authenticated state and generic key–value storage. In the negative database, it is between raw tuple storage and a structural complement representation. In knot theory, it is between hand-maintained tables and automated inequality propagation (Moniruzzaman, 2014, Bang et al., 2020, Kang et al., 2023, Jordan et al., 4 Dec 2025, Shi et al., 2017, Jablonowski, 21 May 2026).

This suggests that “NewDB” functions less as a fixed taxonomy than as a marker for architectural replacement. The term often signals that a prior baseline—dual-format HTAP, copy-on-write StateDB on LevelDB, static shared-nothing execution, row-per-frame storage, or manually tabulated invariants—is being treated as structurally mismatched to the workload.

Several limitations recur. NHtapDB is explicitly a vision paper and does not provide full experiments or a complete concurrency-control design (Kang et al., 2023). NeurDB is under active development and outlines system components more fully than it evaluates them end to end (Ooi et al., 2024). The intensional RDB manifesto is formal and architectural rather than empirical (Majkic, 2014). AnyDB demonstrates the promise of per-query architecture morphing but leaves full optimization, fault tolerance, and general transaction semantics as open problems (Bang et al., 2020). Even the more concrete systems impose domain assumptions: the forkless database depends on fast-finality consensus (Jordan et al., 4 Dec 2025), the negative database relies on regular time-series generation with low frame-loss ratio (Shi et al., 2017), and the knot-theoretic NewDB is constrained by the existing inequality graph and the available seed data (Jablonowski, 21 May 2026).

The principal misconception to avoid, therefore, is that NewDB names a single post-relational doctrine. In the current literature it names a set of redesign strategies. Some retain SQL and ACID while changing storage and execution. Some embed AI or hybrid analytics into the core. Some are highly specialized native engines. One is not a DBMS at all, but a computational mathematical database. What they share is a commitment to re-specifying the internal representation so that the dominant workload, proof system, or execution path is no longer forced through an inherited abstraction barrier.