Where database names come from
A short tour of database name origins. Children, code names, predecessors, acronyms, mythology, and at least one pet duck on a houseboat. Most of the history of the field is hidden inside the names themselves.
AI-assisted postDrafted with help from Claude, edited and fact-checked by Mart. See transparency policy →
Little My, by Tove Jansson, from the Moomin series (first appeared in Moominpappa's Memoirs, 1950). © Moomin Characters Ltd. Little My is not the actual namesake of MySQL, but she shares both a name and a Finnish lineage with Monty Widenius's daughter My, who is.
Most database names are someone's diary entry
The database field looks uniform from the outside. Everything is some kind of SomethingDB or SomethingSQL, and the visual logos converge on a small palette of cylinders, leaves, ducks, and elephants. Underneath that surface, though, the names are almost always personal artifacts — somebody's child, somebody's pet, somebody's CIA code name, somebody's quiet joke about an ancient Greek curse. The vast majority of databases in production in 2026 carry a story in their name that the documentation never tells you, and the stories are often more interesting than the architecture.
What follows is a short tour. It is not exhaustive — the field is large enough that this post could keep running for a month — and it skips the dozens of databases whose names are simply descriptive (Memcached, FoundationDB, RocksDB, LevelDB). The selection here is the ones with the better backstories.
The Widenius children: MySQL, MaxDB, MariaDB
The clearest example of a database family that is also an actual family is the work of Michael "Monty" Widenius, who has three children — My, Max, and Maria — and three databases that carry their names.
The first was MySQL, which Widenius and David Axmark released in 1995. "My" was Widenius's eldest daughter. The acronym SQL was bolted on the back, and the combination became one of the most widely deployed databases ever shipped. MaxDB, a re-badging of SAP's adabas-based database that Widenius's company maintained for a stretch in the early 2000s, took its name from Widenius's son. The Max distribution itself is mostly history now, but the lineage is documented in his Wikipedia entry.
The third instalment is the most dramatic. When Oracle acquired Sun Microsystems in 2009 — and with Sun, MySQL — Widenius did not wait for the deal to finish closing before forking his own database. On 2009-10-29, before the Oracle deal had finalised, he released MariaDB 5.1.38, named after his youngest daughter Maria. The name was the only naming option left in the family, and the gesture was as much symbolic as technical — a declaration that the database the family had built was not going to live inside Oracle's catalogue under his name.
Postgres is literally "after Ingres"
PostgreSQL is the database whose name contains the longest historical chain in active production today. The story begins in 1973 at UC Berkeley, where Michael Stonebraker and Eugene Wong started building Ingres — INteractive Graphics and REtrieval System. Ingres was one of the earliest serious relational database management systems and seeded an entire industry; commercial descendants and influencers include Sybase, Informix, and (loosely) Oracle.
Stonebraker left Berkeley in 1982 to commercialise Ingres, returned in 1985, and started a new project explicitly framed as the next thing. He called it Postgres — "post-Ingres" — and the goal was to take what Ingres had done and push it further into object orientation, rules, and extensibility. The Berkeley Postgres project ran from 1986 to 1994 and is documented in detail in Stonebraker's 2019 Looking Back at Postgres paper.
The "SQL" in PostgreSQL did not arrive in the name until 1996, when Andrew Yu and Jolly Chen replaced the original Postgres query language POSTQUEL with a real SQL parser and re-released the project. The current name accumulates the history rather than declaring any single thing about the product — post-Ingres-now-with-SQL is the literal etymology, and the PostgreSQL project's own brief history lays it out exactly that way.
Oracle was a CIA code name
The Oracle naming story is one of the more straightforwardly improbable origins in the field. Larry Ellison, Bob Miner, and Ed Oates worked at Ampex Corporation in the mid-1970s, and one of the projects they worked on was a database under a CIA contract. The project's internal code name was Oracle — picked, by various retellings, because an oracle is meant to be able to answer any question about anything, and a general-purpose database has roughly the same job description.
When the three left Ampex in 1977 to start a company, they took the code name with them. The new company was originally called Software Development Laboratories, then Relational Software Inc., and finally Oracle Corporation in 1982. The product itself shipped under the name Oracle for the first time as Oracle v2, with no Oracle v1, on the well-aired theory that enterprise customers would not buy a v1 of anything. The CIA ended up being the first commercial customer of the product that had originally been a code name for a project they had funded. Gizmodo wrote up the longer version of the story in 2014, and Ellison's Wikipedia entry carries the same lineage.
SQLite was built for a US Navy destroyer
SQLite is one of the most widely deployed pieces of software on Earth — it ships inside every iOS device, every Android device, every Firefox install, and most of the embedded systems built in the last fifteen years — and its origin is unusually specific. D. Richard Hipp designed it in the spring of 2000 while contracting for General Dynamics through their Bath Iron Works subsidiary, writing valve-control software for the US Navy destroyer USS Oscar Austin. The control system needed a database, and the existing Informix-based setup kept losing its connection whenever the ship's compute environment got disrupted.
Hipp wanted a database that did not need a separate server process — one that could live in the same address space as the application and never go down independently of it. The result was SQLite, and the Lite in the name refers to the lack of infrastructure rather than any reduction in capability. The New Stack ran a good retrospective on the story in 2024.
The acronyms that hide in plain sight
A surprising number of database names look like ordinary words and are actually acronyms or word-collisions in disguise.
- Redis — REmote DIctionary Server. Written by Salvatore Sanfilippo (known online as antirez), 2009.
- MongoDB — Mongo as in humongous. Started inside 10gen, a company founded in 2007 by Dwight Merriman, Kevin Ryan, and Eliot Horowitz (the same team that had earlier built DoubleClick).
- ClickHouse — Clickstream + data warehouse. Built at Yandex by Alexey Milovidov, started in 2009 and in production at Yandex.Metrica from 2012.
- Neo4j — Neo (new) plus 4j (for Java), the same Java-ecosystem suffix you can find on Log4j, Quartz4j, and friends.
- DB2 — IBM's mainframe relational database, released in 1983, descended from the System R prototype that produced SQL itself.
The pattern is consistent: a name that reads as a brand on first encounter usually unpacks into a description on second.
Cassandra: named after a curse
Apache Cassandra is one of the more literarily ambitious database names in production. The database was originally built at Facebook in 2008 and donated to the Apache Software Foundation the following year, and the name comes from Cassandra of Troy, daughter of King Priam and Queen Hecuba. In the myth, Apollo gives Cassandra the gift of prophecy and then, when she rejects his advances, curses her so that her prophecies — though always accurate — will never be believed.
There are two readings of the metaphor and neither is entirely flattering. The generous reading is that the database is the oracle in the room, holding the canonical truth of the data and producing correct answers under heavy load. The less generous reading is that even when the database is telling the truth, the application engineers calling it will not always believe it, particularly under eventual-consistency semantics. The original Facebook team has never publicly explained which of the two readings they had in mind when they picked the name, and on balance it is probably both.
Two databases named for how hard they are to kill
The animal-resilience naming tradition is shorter than the family-name tradition but no less interesting.
CockroachDB takes its name from the bug's legendary disaster-survival reputation. The database is designed to keep going under partial failure, network partition, or whole-availability-zone outage, and the metaphor is doing real work — the same survivability characteristic the insect is famous for is also the architectural property the database is built around.
DuckDB, the embedded analytical database that has become the de facto laptop OLAP tool over the last few years, is named after Hannes Mühleisen's pet duck Wilbur. Hannes lived with Wilbur on a houseboat in the Amsterdam canals, and the project's authors point to ducks as a fitting metaphor for an analytical database that works equally well embedded, on a laptop, in a Jupyter notebook, or as a server: ducks fly, walk, swim, and eat almost anything, and DuckDB runs in roughly the same range of environments.
Snowflake and DynamoDB: names that point at the architecture
Some database names are doing the work of explaining what the system is, if you know how to read them.
Snowflake layers three readings into the name. Each snowflake is unique, which the founders mapped onto multi-tenant isolation. Snowflakes are born in the cloud, which mapped onto the cloud-native architecture that distinguished Snowflake from earlier data-warehouse products. And the snowflake schema is a standard dimensional-modelling pattern with one fact table at the centre and normalised dimension tables radiating outward — the data shape the warehouse was being built to support.
DynamoDB takes its name from the internal Amazon Dynamo system, which was described in a 2007 SOSP paper that became foundational reading for the eventual-consistency era of distributed-systems engineering. The original Dynamo was built to keep the Amazon shopping cart available through any kind of failure, and DynamoDB is the public, managed continuation of the same design lineage. The name carries an explicit reference to a piece of research that most distributed-systems engineers have read at least once.
A short close
Engineering taxonomies look uniform from the outside, and they look uniform on the surface of the documentation, and they sometimes even look uniform on the architecture diagrams. The naming layer is where the actual people leak through. Most of the databases that matter in 2026 were named by somebody who was thinking about a daughter, a duck, a research paper, a Greek myth, a CIA code name, or a Berkeley professor who had quietly decided to outdo his last project. Reading the etymologies turns the field from a roster of products into a small, scattered memoir.
Read next
Two pronunciations of SQL have coexisted for nearly fifty years. Why the language was renamed in the first place, and what each pronunciation preserves, turns out to be more interesting than the debate that surrounds it.
The cloud was a network-diagram icon for two decades before it was a product. Compaq coined cloud computing in 1996, AWS made it real in 2006, and the surrounding vocabulary — VPS, hyperscaler, colocation — each carries its own history.
The .yml extension is a 1990s DOS artifact. The 'YAML Ain't Markup Language' acronym is a 2002 self-correction. Both questions resolve cleanly once you know markup languages and data serialisation formats are different categories with different ancestors.