The Bytes Moved, the Compute Didn't: Ten Years of Path Dependence in Decentralized Databases

In one line: the field’s unsolved problem is not that consensus is too weak, it is that compute never followed the bytes. A database is not one thing — it is four: write order, byte location, execution location, read permission. Six routes, and each one bought exactly one of them.

1. The problem, as a scene#

In 2016 “blockchain database” was a term of art. BigchainDB gave the plainest answer on offer: MongoDB stores, Tendermint orders, every node keeps a full copy, a write is final the moment it lands. It collected 4,030 stars and a place in every survey’s comparison table.

The GitHub record says the last push was 2024-07-04 and the last release, v2.2.2, was September 2020; the successor work went to Planetmint under the IPDB Foundation. It is still the sample a reviewer reaches for when asked what a decentralized database looks like.

It is not alone. Kwil sold its decentralized stack to TRUF.NETWORK in April 2025, which open-sourced it; Tableland raised an $8M Series A led by CoinFund in April 2023 and has $10.4M in total; Space and Time went to mainnet in May 2025 betting the whole story on zero-knowledge proofs of query results; OrbitDB spent a decade reaching v3 and shipped a v4 release candidate in April 2026.

The field’s obituary list is about as long as its product list, and the deaths share one shape: each project decentralized exactly one of four layers and then claimed the whole database was decentralized.

2. The four-layer bill: who actually bought which layer#

A database is not one object. It is four: write order, byte location, execution location, read permission. Split them apart and every argument in this field collapses into the same multiple-choice question — which layer are you paying to decentralize?

None of those six rows is wrong: the ledger puts write order on a chain, P2P turns replica sync into a protocol, Tableland puts table names and permits on-chain, Space and Time turns “is the answer right” into a proof, IPFS only knows where the bytes are, and the academic prototype moves both permission and master election. None of them stands alone either.

Back in the whole picture, the stack you start from roughly sets your ceiling: projects out of the IPFS ecosystem solve “where are the bytes” and “who goes first”, and push complex queries to the back; out of the blockchain ecosystem you get a ledger, so ordering comes first; out of Postgres (Kwil) you get SQL traded for consensus; out of a research group you get Spark and Hive. Nobody designed the four layers together — every project’s boundary is written into the layer it started from.

3. One specimen that wrote all four layers down#

In April 2025 a group at Notre Dame and Georgia put a systems paper on arXiv (it later went to IEEE GBC). It did the rare thing in this field: it wrote down all four layers and priced them.

What the paper chose — which consensus, which storage — matters less than what it did to the word “decentralization”. It turned a boolean into a per-layer dial.

Four requirements:

1. Keep the relational model and SQL. Compatibility: the legacy systems, the BI tools and the people who know SQL all live there.
2. Permissions must be verifiable, revocable and row-level. The smallest enforceable unit of data sovereignty is one row of one table.
3. Multi-tenancy. One table serves several data owners, and each sees only its own rows.
4. Decentralized execution. No permanent master, no node that always knows everything.

Two principles carry those requirements, and the second matters more than it looks:

• P1, pluggable layers. Any single layer can be decentralized independently. The paper’s words: “selectively decentralize any layer/component of their choice”, so different use cases can buy different trade-offs.
• P2, a stateless master. The master is drawn by lot, holds nothing but a private key, and is thrown away after one query.

P1 is worth quoting because it admits something the field usually avoids: the four layers can be bought separately. Every tragedy in section 2 is a project that sold the boolean instead.

4. Taking the specimen apart: six hops for one query#

Layers are easy to draw. Connecting them is the hard part, and one query crosses six hops to do it.

Entry. A JavaScript front end talks to MetaMask so the user’s key never leaves the wallet; a C# API sits behind it. This is the one layer still centralized, which the paper admits in its future work.

Control. Hyperledger Fabric and smart contracts. The ACL holds three things per user: the public key, hashes of the data they own, and hashes of the data they may read. A query sends the user’s public key and the target tables on-chain; the contract checks the ACL and returns the data hash to the execution layer.

There is a detail the paper does not develop: identity lives on Ethereum, permissions live on Fabric. Two trust roots, two chains, two consensus mechanisms, and no specification of the bridge between them. In a prototype that is a footnote. In production it is the first thing anyone attacks.

Engine. Spark and Hive on a gossip network (Boost.ASIO). A query is broadcast, each node runs a VRF sortition — Algorand’s Algorithm 1/2 with the weights changed and the role parameter removed — and the number of sub-slots a node wins is read off where its hash falls in a binomial distribution. The outputs go back on-chain, the chain waits a fixed interval to collect them, and BA⋆ converges on who is master for this round. The master then encrypts the result back, sets every worker’s weight to 1, sets its own weight to 0, and clears its cache through Spark:

// engine: after the query, the master unpersists the RDDs it cached
rdd.unpersist(blocking = true)

Storage. Public IPFS. Every engine node also runs an IPFS daemon; a table update is written back to IPFS and the new hash returns to the ACL.

5. What it costs#

None of those rows belongs to one project. The whole field pays for the same thing under different names: the expensive part is materialization.

Section VI says it plainly: transfer between the engine and IPFS significantly lengthens execution, because queries cannot run directly on IPFS’s CAR format — an open problem.

In plain terms: content-addressed storage sells a database the location of bytes, but a database needs compute moved next to the bytes. Web3 spent ten years on the first half and none on the second.

6. What eighteen machines bought#

Run the specimen on TPC-H at scale factor 10 (about 10 GB), 22 queries, EC2 instances across eight regions:

Every row is computed from the 22 raw rows of Table III: mean latency is the arithmetic mean, speedup is the 1-node mean over the N-node mean, efficiency is speedup divided by node count.

Three things to check:

• The prose claims a 20% improvement at three nodes, but Table III has columns for 1, 2, 5, 10 and 18 only. That number has no row.
• “Improvement” here means reduced latency, not speedup. 64% less time is the same measurement as 2.85x, and readers remember the better-sounding one.
• The 22 queries ran sequentially. This measures single-query latency, not throughput — the paper does not say so, but the shape of Table III does.

Three consequences the paper leaves implicit:

1. Two nodes buys 1.06x. The first increment is almost entirely eaten by coordination.
2. Eighteen nodes buys 2.85x, with 15.8% parallel efficiency.
3. Marginal return per added node: 0.14x going 5 to 10, then 0.065x going 10 to 18 — it halves once.

This is not a “just add machines” curve. It is already bending. The paper is also unusually honest elsewhere: at 20 nodes “the network was crashing every time on AWS”, it does not survive a partition, and it has to assume engines never go offline.

The more informative signal is outside the paper. The project’s homepage now leads with TEEs and ZKP and no longer mentions the on-chain ACL, and its LF Decentralized Trust lab page is marked archived. The direction moved: from consensus enforcing permissions to hardware enforcing them.

7. Three ways the field survives#

Follow the six routes to 2026 and most of them are not dead. They changed business.

• Bought. Kwil’s decentralized stack went to TRUF.NETWORK in April 2025 and was open-sourced; the repository was renamed and restarted from near zero.
• Stalled. Tableland has not announced a milestone since its $8M Series A. The SQLite-on-rails design still exists; the narrative moved on.
• Sold something else. Space and Time went to mainnet in May 2025 selling proofs — ZK evidence that a query was not tampered with — rather than storage.
• Held one side. OrbitDB reached “feature complete” v3 in 2025 and a v4 release candidate in April 2026, explicitly local-first and explicitly just the data layer.
• Renamed. Golem DB became Arkiv in 2026: an L2 on Ethereum with L3 “database chains” under it, billed by retention, calling itself a data availability layer.

Whoever moved their pitch from “replace MySQL” to “add a verifiable sidecar to your database” is still around.

8. What this buys you: four questions#

If you are deciding whether to put a project on a Web3 database, this four-question flow is worth more than any feature matrix:

One check you can run today: measure the materialization share of your target query on CAR. If fetching and deserializing blocks is more than 30% of wall time, your bottleneck is I/O, and no consensus algorithm will fix it.

Keep the counter-example. Three cases make the cost worth paying:

• append-only, rarely point-queried data — audit logs, compliance archives;
• data shared across parties where no single party should hold the full plaintext — health, credit, supply chain;
• authorization records that must be non-repudiable — who let whom read which row, verifiable by a third party.

The medical scenario lands in the last two, which is why this route attracted NSF money. It also shows the bill: to make “who may read this” verifiable, you pay with “how fast can it be read”.

9. Two questions nobody can answer yet#

• If the execution node must see plaintext, whose trust root is higher — the TEE’s or the chain’s? The pivot to TEE says the team picked hardware. But “prove with hardware that the software behaved” and “prove with consensus that nobody can rewrite the record” are different kinds of trust, and selling them as one thing will eventually break.
• Can content-addressed storage carry a verifiable index? No index means no pushdown; no pushdown means no database. Whoever makes an index that is verifiable, incrementally maintainable, and addressable alongside its blocks will actually have solved this field’s problem — instead of shipping another decentralized database.

References#

• Paper: Web3DB: Web 3.0 RDBMS for Individual Data Ownership (arXiv 2504.02713v1, 2025-04-03; IEEE GBC 2025)
• Prototype: web3db.org · lf-decentralized-trust-labs/web3db
• BigchainDB (v2.2.2, 2020-09) · OrbitDB · GunDB
• TRUF.NETWORK acquires Kwil’s decentralized technology (2025-04)
• Space and Time mainnet (2025-05-09) · Proof of SQL
• Tableland Series A (2023-04)
• Arkiv (formerly Golem DB): L2 plus L3 DB-chains
• IceFireDB docs: NoSQL / SQL middleware over IPFS
• Data: paper Tables II and III; GitHub API reads taken 2026-11-07 for stars and last push.