OSS Projects
An analysis of how database requirements change across the MVP, PMF, growth, and scale stages, comparing the trade-offs of SQLite, Postgres, managed databases, and dedicated vector stores — and where Alopex DB's 'erase the migration cliff' approach fits.
Building a distributed system means building node discovery, liveness detection, messaging, and agreement before getting to the actual work. Alopex Chirps takes on exactly those four. This covers what it handles and what it does not, why QUIC was chosen, and how openraft came to be the consensus layer.
In a network where neither the identity nor the number of participants is known, one node one vote does not hold. Probabilistic finality in PoW, the structure by which PoS relies on economic penalties rather than impossibility, Solana and Avalanche, and the option of avoiding agreement — with the criteria for choosing among them. Part 4 of a 4-part series.
The world in which nodes send signed, contradictory information. The meaning of the constant n=3f+1, PBFT's three-phase voting, Tendermint's locking rules, HotStuff's quorum certificates, and what the DAG-BFT designs since Narwhal separated and what they removed. Part 3 of a 4-part series.
The family of algorithms for the crash failure model, where nodes stop but do not lie. From the single tool Paxos relies on — quorum intersection — through Raft's decomposition, EPaxos, Multi-Raft, and the parts outside the papers: persistence ordering and linearizable reads, with minimal code. Part 2 of a 4-part series.
A node that stops responding may have crashed, or it may merely be slow; the two cannot be told apart. This part separates leader election, ordering, and commitment into three distinct problems, and covers the practical meaning of FLP impossibility, split brain and fencing tokens, and the boundary between the replicated log and the applied state. Part 1 of a 4-part series.
SQLite, DuckDB, PostgreSQL, distributed DBs, vector DBs, graph DBs — there is no shortage of great products. I'm building a new database anyway because every time the project moves forward, I re-pick the DB and rebuild the data itself. Alopex DB aims to be a foundation that keeps data's volume, conversion time, regeneration cost, and provenance intact as you scale from local to cloud, from single node to distributed.
Neither LLMs nor image generators learn from training data that humans have labeled item by item. The key is self-supervised learning: mechanically constructing inputs and answers from raw data. Part 1 clarifies the difference between raw data and training data, and shows how an LLM turns text itself into a next-token prediction problem, with minimal code. Part 1 of a 5-part series.
Coding agents are strong at logic and tests. But they can't tell what a piece of data means, who owns it, how fresh it flows, or which copy is authoritative. It follows from the fact that today's AI has no embodiment: the people who rise in value are those who can design the meaning, quality, lineage, and responsibility of data. A look at the trend with the latest data-engineering discussion.
An analysis of how database requirements change across the MVP, PMF, growth, and scale stages, comparing the trade-offs of SQLite, Postgres, managed databases, and dedicated vector stores — and where Alopex DB's 'erase the migration cliff' approach fits.
Building a distributed system means building node discovery, liveness detection, messaging, and agreement before getting to the actual work. Alopex Chirps takes on exactly those four. This covers what it handles and what it does not, why QUIC was chosen, and how openraft came to be the consensus layer.
In a network where neither the identity nor the number of participants is known, one node one vote does not hold. Probabilistic finality in PoW, the structure by which PoS relies on economic penalties rather than impossibility, Solana and Avalanche, and the option of avoiding agreement — with the criteria for choosing among them. Part 4 of a 4-part series.
The world in which nodes send signed, contradictory information. The meaning of the constant n=3f+1, PBFT's three-phase voting, Tendermint's locking rules, HotStuff's quorum certificates, and what the DAG-BFT designs since Narwhal separated and what they removed. Part 3 of a 4-part series.
The family of algorithms for the crash failure model, where nodes stop but do not lie. From the single tool Paxos relies on — quorum intersection — through Raft's decomposition, EPaxos, Multi-Raft, and the parts outside the papers: persistence ordering and linearizable reads, with minimal code. Part 2 of a 4-part series.
A node that stops responding may have crashed, or it may merely be slow; the two cannot be told apart. This part separates leader election, ordering, and commitment into three distinct problems, and covers the practical meaning of FLP impossibility, split brain and fencing tokens, and the boundary between the replicated log and the applied state. Part 1 of a 4-part series.
SQLite, DuckDB, PostgreSQL, distributed DBs, vector DBs, graph DBs — there is no shortage of great products. I'm building a new database anyway because every time the project moves forward, I re-pick the DB and rebuild the data itself. Alopex DB aims to be a foundation that keeps data's volume, conversion time, regeneration cost, and provenance intact as you scale from local to cloud, from single node to distributed.
Neither LLMs nor image generators learn from training data that humans have labeled item by item. The key is self-supervised learning: mechanically constructing inputs and answers from raw data. Part 1 clarifies the difference between raw data and training data, and shows how an LLM turns text itself into a next-token prediction problem, with minimal code. Part 1 of a 5-part series.
Coding agents are strong at logic and tests. But they can't tell what a piece of data means, who owns it, how fresh it flows, or which copy is authoritative. It follows from the fact that today's AI has no embodiment: the people who rise in value are those who can design the meaning, quality, lineage, and responsibility of data. A look at the trend with the latest data-engineering discussion.
