IceFireDB: a database engine that spans Web2 and Web3
@IceFireLabs -> IceFireDB is a database built for web3.0 It strives to fill the gap between web2 and web3.0 with a friendly database experience, making web3 application data storage more convenient, and making it easier for web2 applications to achieve decentralization and data immutability.
At a glance
- What is it?
- IceFireDB is a Go database engine that combines Raft for consistency inside a site with a P2P CRDT for synchronisation across sites, and it exposes both a MySQL protocol and a Redis protocol so that ordinary applications can be decentralised gradually. The README is unusually candid about maturity, marking most of the web3-specific features as beta, in progress or planned.
- Who is it for?
- Adopt IceFireDB for research and prototyping if you are evaluating a hybrid consensus model, or as a decentralisation front end for an existing MySQL or Redis estate, in which case the SQLProxy and Redis-Proxy components are the parts to start with.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 25, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Two worlds, one engine, two wire protocols
IceFireDB is described as advanced decentralized database infrastructure that bridges traditional Web2 applications with the emerging Web3 ecosystem, built on distributed systems research, with a foundation for building decentralised applications with enterprise-grade performance and reliability. The framing in the repository description is slightly blunter: a database built for web3.0 that strives to fill the gap between web2 and web3.0, making web3 application data storage more convenient and making it easier for web2 applications to achieve decentralisation and data immutability.
The practical expression of that is protocol compatibility. The engine supports both SQL, over the MySQL protocol, and NoSQL, over the Redis RESP protocol. That is the part that matters for adoption, because an application does not have to be rewritten to be decentralised. It connects the way it always did, and the storage and replication layer underneath is where the difference lies.
The four claims in the core innovations list are worth separating, because they are at very different levels of completion. Hybrid consensus combines Raft for intra-site consistency with a P2P CRDT for cross-site synchronisation. Multi-storage support integrates disk storage, object storage and IPFS for persistence. Protocol compatibility covers the two wire formats. Decentralized networking enables automatic P2P networking for distributed data synchronisation.
The architectural diagram the README points at is the clearest summary of the intended shape, and the repository carries several images under imgs/ plus a dedicated IceFireDB_Architecture.png and icefiredb-bridge.png at the root, so a reader can see the topology rather than infer it.
Raft inside a site, CRDT across sites
The consensus design is the most interesting part of the project, and it is where the project departs from a conventional database.
Raft gives you a strong, ordered log and a single writer group, which is what you want for consistency within one administrative domain. It is also what makes a database hard to federate, because nodes that do not share a Raft group cannot easily serve the same dataset.
A CRDT is the other approach. Data is represented so that concurrent modifications merge without coordination, which means two sites that cannot talk to each other can both accept writes and reconcile later. The cost is that the merge semantics constrain what you can store, and a CRDT is a different thing from a transaction log.
Putting the two together, Raft inside a site and a CRDT across sites, gives a system with strong consistency where the operator can guarantee it and eventual consistency where it cannot. That is the design that lets a traditional application be decentralised gradually, which is the migration story the README repeats: Web2 migration, Web3 native, data immutability for integrity and auditability, and protocol flexibility.
The consensus modes are listed in the feature table as Raft, P2P-CRDT and IPFS-LOG, and the dependency list shows the pieces: IceFireDB's own icefiredb-crdt-kv and icefiredb-ipfs-log packages, plus libp2p for the networking, with go-libp2p, the Kademlia DHT and the pubsub implementation, and IPFS Kubo v0.40.1 for the IPFS side.
Five components, and you pick the one you need
The project is a monorepo of specialised components, and the README describes each in a way that says which one is the entry point for your situation.
IceFireDB-SQLite is a decentralised SQLite database, with MySQL protocol support for writing data, P2P synchronisation across nodes, SQLite for local persistence, and the aim of building global distributed database systems. IceFireDB-SQLProxy is the migration component, a decentralised SQL database networking system for traditional Web2 databases, with automatic command replication across network nodes and MySQL integration.
IceFireDB-Redis-Proxy adds decentralisation to traditional Redis databases, with full Redis RESP protocol compatibility, a decentralised middleware role, support for Redis clusters and single instances, and automatic instruction synchronisation across nodes. IceFireDB-PubSub is a high-performance decentralised publish-subscribe system with Redis pub/sub compatibility, built-in redundancy and failover, and a P2P subscription network. IceFireDB-NoSQL is the native key-value component.
The split is a deliberate product decision. The proxies are for teams with an existing database, and they are the lower-risk way in, because the application keeps talking the protocol it already speaks. The native components are for teams building something new.
The Go dependency list corroborates the scope. The Redis side is built on tidwall/redcon, a Redis server implementation, with go-redis and redigo for the client side, a redis-go-cluster fork, and ledisdb and goleveldb for storage. The SQL side uses mattn/go-sqlite3. Prometheus client_golang and logrus are there for observability, and the AWS SDK is for the object storage driver.
The feature table is really a maturity map
The key features table has a status column, and reading it is the fastest way to understand what this project is today.
Implemented are multi-storage support, with LSM disk, object storage, IPFS and hybrid storage drivers, distributed consistency across the three consensus modes, and hot/cold storage through the hybriddb driver. Marked beta are IPFS integration as a persistent decentralised storage layer, P2P auto-networking for automatic decentralised network formation, and the key-value storage engine in its CRDT-based and IPFS-LOG based forms. High performance is listed as ongoing optimisation rather than done.
Still in progress are the AI vector database, with vector storage and similarity search, and NATS integration for decentralised messaging. Still planned are the tamper-resistant logs, described as auditable and scalable logging with QED integration, and the Web2-Web3 bridge, described as an immutable data witness layer.
That last pair is the most interesting to watch, because the whole premise of the project is a bridge between the two worlds, and the table says the bridge itself is planned rather than implemented. The parts that are implemented are the mechanisms, the storage and the consensus; the pieces that would turn them into a product for ordinary applications are on the roadmap.
The repository root backs the operational reading of the project, with OPERATIONS.md, COMPATIBILITY.md, a SECURITY.md, a CHANGELOG.md, an AGENTS.md and a CODE_OF_CONDUCT.md, plus a driver/ directory and a scripts/ directory, and a vendor/ directory that means the build is reproducible without a network fetch.
Where IceFireDB is the wrong choice
The first wrong-tool case is a production database with an availability requirement. The only published release is v1.0.0-alpha, the alpha marker is in the version string itself, and the feature table marks the interesting parts of the web3 story as beta or planned. A team that needs a database to be up on Monday is looking at a different class of software, whatever the benchmarks say.
The second is an application that needs transactions across sites. The hybrid design gives strong consistency within a site and eventual consistency across sites, and an application whose invariants span two sites has to be written for that model. That is a rewrite of the consistency assumptions in the application, not a configuration change, and it is a bigger project than adopting a database.
The third is a team that wants one database rather than a platform. This repository is a monorepo with five components, three consensus modes, several storage drivers, a P2P stack and a set of protocol front ends. That is a lot of surface to evaluate, and the SQLProxy and Redis-Proxy pieces are the narrowest way in if the goal is to see the decentralisation model work on an existing workload.
There is also the IPFS question to settle. A storage layer where the data is addressed by content and distributed across peers has different durability, availability and cost properties from a disk, and an application that needs the data to be there at a predictable time has to think about that explicitly.
Two different licences in two different places
There is a genuine discrepancy in the licensing information, and a team that is doing this properly will hit it. The project metadata records the licence as MIT, while the badge at the top of the README says Apache 2.0 and links to the Apache licence text. There is a LICENSE file at the root of the repository, and that is the file that governs, but the two other sources disagree, and a reader who trusts the metadata gets a different answer from a reader who trusts the badge.
Neither of those licences is onerous for a company that wants to use the software, and both are permissive, so this is unlikely to be a blocker in practice. It is a documentation defect worth reporting, and it is a good reminder to read the LICENSE file rather than a badge.
On versions and activity, the picture is clearer. The single listed release is v1.0.0-alpha from 2025-05-11, so the project has been shipping as an alpha for a while, and the last push was on 2026-10-19, which means the work is current even though the release tag is old. The Go version required is 1.25.0, and the module path is github.com/IceFireDB/IceFireDB.
The project is also structured for contributors, with an AGENTS.md in the root, a Makefile, per-component test files at the top level such as compat_test.go, conn_test.go, hashes_test.go and partition_test.go, and the data type implementations sitting as root files like lists.go, set.go, strings.go, sorted_sets.go, hashes.go and scan.go, which are the Redis data type names and tell you the native engine is a Redis-compatible store.
Editorial conclusion
Adopt IceFireDB for research and prototyping if you are evaluating a hybrid consensus model, or as a decentralisation front end for an existing MySQL or Redis estate, in which case the SQLProxy and Redis-Proxy components are the parts to start with. Do not adopt it as a production database today, since the feature table marks IPFS integration, P2P auto-networking and the key-value engine as beta, the AI vector database and NATS integration as in progress, and the tamper-resistant logs and Web2-Web3 bridge as planned, and the only release is v1.0.0-alpha. Before you invest, resolve the licence question, since the repository metadata says MIT while the README badge says Apache 2.0, and read the OPERATIONS.md and COMPATIBILITY.md files at the root, which the repository layout suggests are where the practical limits are written down.
Frequently asked questions
What is IceFireDB and how does it combine Raft and CRDT?
It is a Go database engine that bridges Web2 and Web3 applications, using Raft for intra-site consistency and a P2P CRDT for cross-site synchronisation, with consensus modes listed as Raft, P2P-CRDT and IPFS-LOG. It exposes both a MySQL protocol and a Redis RESP protocol.
What are the components of IceFireDB?
IceFireDB-SQLite, a decentralised SQLite with MySQL protocol support, IceFireDB-SQLProxy, a networking and command replication layer for existing MySQL databases, IceFireDB-Redis-Proxy for existing Redis deployments, IceFireDB-PubSub, a decentralised publish-subscribe system, and IceFireDB-NoSQL, the native key-value component.
Which IceFireDB features are ready and which are not?
The README's feature table marks multi-storage support, distributed consistency and hot/cold storage as implemented, IPFS integration, P2P auto-networking and the key-value engine as beta, the AI vector database and NATS integration as in progress, and tamper-resistant logs and the Web2-Web3 bridge as planned.
What licence does IceFireDB use?
MIT is recorded in the project metadata while the README badge shows Apache 2.0, and the LICENSE file at the repository root is the governing text. The only published release is v1.0.0-alpha, dated 2025-05-11, and the last push was on 2026-10-19.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/icefiredb-icefiredb)Was this useful?