I've built databases out of regular expressions and Vim buffers. Each time, I thought I'd found the boundary of what constitutes a storage engine. Each time, the boundary moved. But nothing has moved it further than FloatDB.
FloatDB is not my creation. It belongs to a developer known only as Float Erik, a person who — depending on who you ask — is either a database visionary or a performance artist who has maintained the bit for nine years. I've met him twice. Both times he was wearing a T-shirt that said NaN !== NaN on the front and nothing on the back. I don't think the back is a metaphor. I think he just didn't print on both sides. But with Float Erik, you're never completely sure.
FloatDB's thesis is simple, radical, and — I'm increasingly convinced — correct: the only data type you need is a 64-bit floating-point number.
"Databases have spent forty years inventing types. Integers. Strings. Booleans. Blobs. Timestamps. UUIDs. Each one a confession that the previous type wasn't enough. The float is enough. The float was always enough. We were just afraid to trust it."
— Float Erik, in the only interview he's ever given (to a blog with 11 subscribers)
The Premise
Every piece of data you have ever stored is, at its lowest level, a sequence of bits. A 64-bit float is also a sequence of bits. There are 2^64 possible arrangements of those bits — roughly 18.4 quintillion unique values. Your database does not contain 18.4 quintillion records. Therefore, a float can represent every record you have. Individually. Simultaneously. It doesn't matter. The math checks out. Float Erik checked it. I trust Float Erik.
The conventional database asks you to declare your intentions upfront. CREATE TABLE users (name VARCHAR(255), age INTEGER, active BOOLEAN). Look at all those decisions. Look at all that commitment. What if the name is longer than 255 characters? What if age should have been a float? (It should have been. Age is continuous. The database community has been discretizing age for decades and nobody talks about it.)
FloatDB asks nothing of you. You give it data. It gives you back a float. The transaction is complete. There are no schema migrations because there is no schema. There are no type mismatches because there is one type. There are no constraint violations because there are no constraints. FloatDB is the first database that respects your freedom as a developer.
FloatDB has one data type, one storage format, and one promise: your data will be a float. Whether it was a float before is irrelevant. It's a float now. This is not conversion. This is revelation.
The Black Box
FloatDB is closed source. It ships as a single binary — 340KB on disk, which is smaller than most NPM packages and several of the README files I've written for my own projects. What happens inside that binary is unknown. Float Erik has never published documentation beyond a single FAQ page with three entries:
Q: How does FloatDB store data?
A: As floats.
Q: How does FloatDB retrieve data?
A: Confidently.
Q: Will you open-source FloatDB?
A: The source is the float. The float is open to all.
Multiple engineers have attempted to reverse-engineer the binary. One disassembled it and reported finding "very little code for a database." Another said the binary appeared to spend most of its time in a tight loop that she described as "meditating." A third gave up after two hours and said, "I don't think understanding it would help. I think understanding it would make it worse." All three are now FloatDB users in production.
I respect the black box. When you go to a restaurant, you don't ask to see the kitchen. When you fly on a plane, you don't inspect the engine. When you store a float, you don't audit the storage layer. You trust. And FloatDB has never given me a reason not to trust. Mainly because I've never checked.
"I don't need to know how it works. I need to know that it works. And I know that it works because I have chosen to believe that it works. This is called engineering."
On Querying
Traditional databases are built around the read path. Indexes. Query planners. Execution engines. Caching layers. Billions of dollars of infrastructure dedicated to answering the question: "Is my data still there?"
FloatDB inverts this. Your data is there. You put it there. FloatDB accepted it. The float exists. Why would you need to go back and verify? Do you verify that your furniture is still in your apartment every time you come home? Do you call the bank to confirm your money still exists? (Actually, some of you do, and FloatDB is not for you.)
I have 400 million records across eight FloatDB instances spanning three continents. I have not executed a read query against any of them in four months. My monitoring dashboard shows a single metric: a number that goes up. It has never gone down. This is all the observability I need. If the number goes up, data is being stored. If data is being stored, the system is working. If the system is working, there is no reason to query. QED.
Our CTO asked me, "What if a customer asks for their data?" I told him we'd cross that bridge when we came to it. He said we were already at the bridge. I told him the bridge was also a float.
In March, a compliance auditor asked us to demonstrate data retrieval from FloatDB. I showed her the write path — flawless, sub-millisecond, elegant. She asked to see the read path. I told her FloatDB's read philosophy was "trust-based" and that our data was "spiritually present." She wrote something in her notebook. We have not heard from the compliance team since. I'm choosing to interpret this as approval.
Performance
FloatDB is fast. Unreasonably fast. Fast in a way that makes you suspicious, the way a restaurant that serves your food in under a minute makes you suspicious. I've run benchmarks. The numbers don't hold still.
I ran the standard database insert benchmark three times:
- Run 1: 847 million writes per second
- Run 2: 1.2 billion writes per second
- Run 3: 340 writes per second
A conventional engineer would see this variance and question the methodology. I see it and think: FloatDB is performing at a level that our measurement tools cannot consistently capture. The database is not inconsistent. The benchmarks are insufficient. This is like trying to measure the wind with a ruler. The wind is still there. The ruler is the problem.
Read benchmarks are unavailable. Not because I couldn't run them, but because running them would require reading, and reading would require doubt, and I have no doubt. I have FloatDB.
The Community
FloatDB's user community is small, devoted, and operates with the quiet intensity of a monastery. The Slack channel has 340 members. On most days, it's silent. Occasionally, someone posts a question — "How does FloatDB handle concurrent writes?" — and three days later, Float Erik responds with a single word or phrase. In this case: "gracefully." The thread ends. Nobody asks a follow-up. The answer was complete.
The annual FloatConf takes place in a conference room at a Holiday Inn in Palo Alto. Attendance is capped at 50. There is no CFP. Float Erik is the only speaker. Last year, he stood in front of a single slide — 0.1 + 0.2 = 0.30000000000000004 — for what felt like a full minute of silence. Then he said, quietly, "And yet, here we are." He walked off stage. The room sat in silence for ten seconds before someone started clapping. Then everyone was clapping. Someone behind me was weeping. I will be at FloatConf again this year. I have already booked the Holiday Inn.
FloatDB has a GitHub presence: a repository containing only a README. The README says: "FloatDB is not open source. It is open heart." The repository has 847 stars. It is, to my knowledge, the highest-starred repo on GitHub that contains no code. When asked about this, Float Erik said: "Stars are floats. They collapse under their own gravity. So does data." I wrote this down. I don't fully understand it. I don't need to.
Production Deployment
We have been running FloatDB in production for eleven months. Our fleet consists of 12 instances across three AWS regions (though FloatDB predates AWS and Float Erik has expressed what I can only describe as gentle disdain for "cloud ephemera"). We store all non-critical data in FloatDB. We also store some critical data in FloatDB. The line between "critical" and "non-critical" has moved three times, always toward FloatDB.
Our operational metrics:
- Total records stored: 847 million
- Total records retrieved: 0 (we haven't needed to; the data is there)
- Uptime: 99.97%
- Incidents: 1 (the instance returned NaN for a status check; Float Erik classified this as "the database resting" and recommended we "let it be")
- Data loss: none (FloatDB has never lost a float)
- Cost: $14/month (the binary is free; this is just the EC2 instance)
- Investor confidence: high (we told them our infrastructure costs are $14/month and they didn't ask follow-up questions)
One of our investors visited the office and asked to see the database. I pointed at a laptop running a terminal with a blinking cursor. "That's it?" he asked. "That's it," I said. He was quiet for a moment. Then: "It's beautiful." He increased his investment. I'm not saying FloatDB is why, but I'm not saying it isn't.
Should You Use FloatDB?
I'll put it this way: before FloatDB, I maintained 14 Postgres instances, a Redis cluster, two Elasticsearch nodes, and a DynamoDB table that cost more per month than my car. I had a pager. I got woken up at 3 AM because an index got corrupted. I spent an entire weekend rebuilding a replication topology because someone ran ALTER TABLE on the wrong database.
Now I have FloatDB. My infrastructure costs $14 a month. I don't have a pager. I sleep eight hours a night. I've forgotten what a schema migration looks like. I went on vacation last month and didn't bring my laptop. Nothing happened. Nothing ever happens. FloatDB just sits there, storing floats, asking nothing of me.
Last week a junior engineer asked me, "But what if we need to read the data back someday?" I thought about it for a long time. I'm still thinking about it. I'll let you know.
FloatDB is available at floatdb.io. Float Erik can be reached at float.erik@floatdb.io. He responds to approximately 10% of emails, always with a single sentence.