I recently launched an open source database called Lux. Originally it was meant to be a faster version of Redis but it's quickly become much more.
We've been using a lot of Redis at Pompeii recently and have been doing a lot with realtime data. I had a random thought to myself, does Rust bring any benefits that could make Redis better? It's an old project... surely someone has thought of this right?
So I got to work and quickly realized that there were opportunities. Redis is single-threaded by design to protect the order of operations in which commands are run and data is written. But if you need a bigger Redis instance you have all those other cores sitting there unused.
I spun up a prototype of Lux and started seeing meaningful wins on common Redis-style workloads. As the architecture tightened, the published benchmark suite began showing multi-million ops/sec results on pipelined single-key commands, with the advantage growing as pipeline depth increased.
As Lux grew and became faster and tighter, I started to think about where else we could go from there. We've also been doing a lot of work recently with embeddings, and I still haven't found a vector db that I am "loyal" to... so I had the idea to bake it into Lux.
So I did. Native vector storage and cosine similarity search. Four commands: VSET, VGET, VSEARCH, VCARD. No extensions, no sidecars, no separate process.
Then I added time series. TSADD, TSRANGE, TSMRANGE with aggregation, retention policies, and label-based filtering. Because standing up InfluxDB for application metrics felt like overkill.
Then I added KSUB. Realtime key subscriptions. Subscribe to a key pattern, get events when matching keys are mutated. We built this because the realtime solutions we'd tried weren't cutting it for us. KSUB fires events from inside the storage engine with zero overhead when nobody's listening. No separate service, no WAL polling, no global config flags.
And that's when it clicked.
Lux is not just a faster Redis. It's a data runtime. What I think is missing from the modern stack, especially with the caliber of AI applications that are being built right now, is a unification of what I call second-tier data.
Every application has two data layers. The first layer is your primary database. Postgres, MySQL, whatever. Your tables, your relationships, your source of truth. Supabase has done an incredible job owning this layer: managed Postgres with auth, storage, edge functions, a dashboard that makes it all accessible.
The second layer is everything else. Your cache. Your vectors. Your time series. Your queues. Your realtime subscriptions. Your session store. Your rate limiter. Your leaderboard.
Nobody owns that layer. Today it's scattered across five or six services: Redis for cache, Pinecone for vectors, InfluxDB for metrics, BullMQ for queues, a custom WebSocket service for realtime. Each one is another connection string, another SDK, another dashboard, another bill, another thing that can go down at 3am.
Lux unifies that layer. One binary. One connection string. Every second-tier data primitive built into the core.
The way I see it, the ideal modern stack is Supabase + Lux. Supabase for your primary data: tables, auth, storage, edge functions. Lux for everything else: cache, vectors, time series, queues, realtime, embeddings.
This isn't theoretical. It's what we run at Pompeii. Supabase handles our relational data and auth. Lux handles our agent memory, our metrics pipeline, our job queues, and our realtime event system. One Postgres. One Lux. That's the whole data layer.
All of this in a 2MB Docker image that starts in milliseconds. MIT licensed. Written in Rust. No license rug-pulls.
The second layer of your stack deserves better than duct tape. That's what Lux is for.