alama@world: ~/
./toggle-theme
You Should Reinvent The Wheel thumbnail

# You Should Reinvent The Wheel

by Thiery Laverdure
Published on August 8, 2025
Software Development Best Practices Innovation Databases

Description

A thought-provoking talk about when and why developers should consider reinventing existing solutions, challenging the conventional wisdom of 'don't reinvent the wheel'. Terry unveils Lightbase, a distributed SQLite database, and walks through the multi-year journey of building it.

Venue

Laracon US 2025

cat notes.md

My Notes

Key Takeaways

The Case for Reinventing the Wheel

Conventional wisdom says don't reinvent the wheel. Terry argues the opposite: reinvention is how technology evolves and how developers grow.

  • Most of what we do as developers boils down to storing and retrieving text from a database — even LLMs are just doing this with synthesized text
  • Progress happens through repetition, refinement, and reinvention
  • Great tools in the Laravel ecosystem (by Taylor, Adam Wathan, Caleb Porzio, Nuno Maduro) all reinvented existing solutions
  • Chick-fil-A's cookie analogy: something familiar done really, really well can beat "revolutionary"

From Self-Doubt to Self-Development

The missing step between "I don't think I can do it" and "I can do it" is "I'm learning how to do it."

  • The jazz parallel: you don't invent your own style first — you transcribe solos from Miles Davis, Cannonball Adderley, Wes Montgomery, internalize their phrasing, then play in your own way
  • "Get in the shed" — seclude yourself and master the technique
  • Ego says discover it alone; reality is mimicking others fills your bag so you can eventually improvise

Building Lightbase: A Distributed SQLite Database

The talk pivots into the story of Lightbase, an open source distributed database built on SQLite, backed by distributed file systems and object storage.

The problem: SQLite expects the database file on local disk. Making it work reliably across multiple app servers and queue workers is non-trivial.

First attempt (2019, Laravel Vapor + AWS Lambda + EFS):

  • Reading from the database over EFS was easy; writing was complex
  • SQLite coordinates access via file locking — painfully slow over the network
  • Network file systems don't support memory-mapped files, which SQLite relies on for concurrent read/write coordination

Lightbase Server architecture:

  • Embed SQLite on local disk in a single Go binary
  • HTTP communication layer with a connection manager
  • Virtual File System hook into SQLite to manage all IO in heap memory (works around the mmap gap on NFS)
  • Adds authentication, authorization, clustering, primary election via lease mechanism

The corruption incident:

  • By default each SQLite connection has an isolated page cache — broken cache invalidation causes corruption on replicas and primary
  • Single-instance SQLite offers serializable isolation; distributed replicas cannot guarantee it
  • Reading a page out of order, writing to the wrong place, or returning wrong database size → corruption

Lightbase DFS: The Structured Log

To fix consistency, Terry rewrote storage from scratch as a "structured log" — inspired by log-structured merge trees.

  • Versioned Write-Ahead Logs — instead of one journal, multiple immutable timestamped WALs created on checkpoint, reducing contention
  • Page logs — indexed groups of database changes with immutable timestamps, holding data flushed from WALs
  • Dynamic Data Ranges — the foundational layer; subsets of the database split across many files so a single logical database can scatter across object storage and scale to terabytes
  • Result: a multi-version log-structured merge tree allowing transactions on a consistent snapshot at a point relative to their start
  • Features unlocked: intelligent data tiering, non-blocking backups, point-in-time restore, database branching, compression, encryption

Laravel Integration and LQTP

Lightbase Server exposes a JSON API with parameterized queries.

  • Custom Laravel database connection class reusing the existing SQLite processor and grammar
  • Custom PDO class that sends queries over HTTP instead of calling the local SQLite library
  • Just add driver config — drop-in

Benchmark (100 migrations, ~200 queries):

Driver Time
MySQL 700ms
Postgres 750ms
SQLite (local) 230ms
Lightbase (JSON/HTTP) 450ms
Lightbase (LQTP) 300ms

LQTP — Lightbase Query Transfer Protocol:

  • Custom binary protocol on top of HTTP, ditching per-request headers and JSON marshalling overhead
  • Asynchronous bidirectional streaming, interactive transactions, data framing, implicit batching
  • PHP client uses stream_socket_client + PHP fibers for async control flow — no third-party libs, no FFI, no extensions
  • 33% efficiency gain over JSON, closing the gap on local SQLite

Notable Quotes

Every sunrise brings new possibilities. Repetition, refinement, reinvention. It's not a waste of time. It's how we evolve technology.

Nadia Boulanger, Quincy Jones' French music teacher:

Quincy, there are only 12 notes until God gives us 13. I want you to know what everybody did with those 12.

How I'll Apply This

The core lesson isn't "always reinvent" — it's that the learning deposited from the attempt is never wasted, even if the project never ships. Two things I'm taking away:

  1. When considering whether to build vs. adopt, weigh the knowledge deposit alongside the shipped-feature outcome. "Fill your bag" is a legitimate reason to build something that already exists.
  2. The self-doubt → self-development → confidence progression is a debugging tool for stalled projects. If I'm stuck at "I don't think I can," the fix is transcription: read the docs, read other people's code, mimic before improvising.

Lightbase itself is worth watching — an SQLite-based distributed database with a custom binary protocol is directly relevant to any project weighing SQLite for production at scale (lightbase.com).

Additional coverage: blog.laravel.com