sqlite: The File That Ate the World

One Trillion Databases

This is episode six of What Did I Just Install.

There is a database running on your phone right now. Not one database. Hundreds. Your text messages sit in a SQLite database. Your photos, your contacts, your browser history, your music library, your health data. Every app you have ever installed almost certainly created at least one. If you are listening to this on an iPhone, the podcast app itself is using SQLite to track your subscriptions, your play position, your download queue. If you are on Android, it is the same story, just a different operating system doing the same thing.

Now multiply that by every smartphone on the planet. Four billion active smartphones, each carrying hundreds of SQLite database files. Then add every laptop, every desktop, every smart television, every set-top box. Every copy of Chrome, Safari, Firefox, and Edge. Every Python installation ships with it built in. Every Mac has it. Every Windows machine since Windows ten. Every copy of Skype, iTunes, iMessage, WhatsApp, and Dropbox. The current best estimate is that there are more than one trillion active SQLite instances on Earth right now. Not one trillion rows. One trillion separate deployments, humming away on devices across the planet, and almost nobody knows they are there.

All of them trace back to a single person. A man in Charlotte, North Carolina, who thought databases should be files. His name is Dwayne Richard Hipp, he goes by Richard, and he has been quietly maintaining the most deployed piece of software in the world for over twenty-five years. He has never taken venture capital. He has never been acquired. He has never burned out. In a series about underfunded maintainers and open source sustainability crises, SQLite is the one that worked. And the story of how it got here starts, of all places, on a Navy destroyer.

A Dialog Box on a Battleship

In the late nineteen nineties, Richard Hipp was a contractor working for General Dynamics through their subsidiary Bath Iron Works, the shipbuilder in Bath, Maine. His team was building software for the USS Oscar Austin, a guided missile destroyer designated DDG-79 in the United States Navy. The software dealt with damage control, specifically the problem of routing around pipe ruptures. When a pipe bursts on a warship in combat, you need to know instantly which valves to close and which alternative routes exist for the fluid. The mathematics behind this is an NP-complete problem, which means it is genuinely hard, the kind of thing where brute force will not get you there and clever algorithms matter.

The team's software used Informix as its database backend. Informix was a perfectly capable enterprise database, but it was a server. It needed to be running. It needed to be configured. And sometimes, unpredictably, the server would go down. When it did, the application would pop up a dialog box that said something to the effect of "cannot connect to database server." The sailors did not care whose fault this was. They saw the dialog box, they blamed the application, and the application was what Hipp's team had built. Every time Informix hiccupped, his team took the heat.

Hipp looked at this situation and asked what now seems like an obvious question but at the time was borderline heretical in database circles.

Why do we even need a server? Why can't I pull this directly off the disk drive?

He looked around for an existing SQL database engine that could run without a server, that could just read and write directly to a file on disk. There was nothing. Every SQL database in existence at the time assumed a client-server architecture. You had the database running as a process, and your application talked to it over a network connection or a local socket. The idea of a database that was just a library you linked into your application, with the data living in a single ordinary file, did not exist in the SQL world.

A colleague made a suggestion that would change the history of software.

Richard, why don't you just write one?

And he said yes. Not "I will propose a research project." Not "let me file a request for funding." Just, as he later recalled, "I will give it a try." The year was two thousand, and a temporary shutdown of government contracts left Hipp with a few months of unexpected free time. He spent that time writing the first version of SQLite. The initial code check-in was May twenty-ninth, two thousand. But some of the components were much older. The parser generator, a tool called Lemon that he had written as an alternative to the standard Unix tools Yacc and Bison, dated back to the late nineteen eighties. His custom printf implementation was similarly ancient. These were pieces he had been carrying around for over a decade, tools built by a man who does not like depending on other people's code.

The Man Who Writes Everything Himself

To understand SQLite, you have to understand Richard Hipp, because SQLite is, more than almost any other widely-used piece of software, an expression of one person's philosophy.

Hipp was born in Charlotte, North Carolina, on April ninth, nineteen sixty-one, but grew up in the suburbs of Atlanta, Georgia. His first encounter with computing came when he saw a Teletype connected to a mainframe through an acoustic coupler modem running at a hundred and ten baud.

I saw a Teletype connected with an acoustic coupler, a hundred and ten baud modem, to a mainframe computer. I said, I have got to learn to program that.

He graduated from Stone Mountain High School in nineteen seventy-nine and went to Georgia Tech, earning a Master of Science in Electrical Engineering in nineteen eighty-four. After three years at AT and T, he went back to school at Duke University, studying under Alan Biermann in the Department of Computer Science, and earned his PhD in nineteen ninety-two. Then he did what a lot of deeply independent technical people do. He started his own company.

The company was originally just his consultancy, but when he married Ginger Wyrick on April sixteenth, nineteen ninety-four, it became Hipp, Wyrick and Company, Incorporated, abbreviated to Hwaci. This is not a Silicon Valley startup story. Hwaci is a small company in Charlotte that provides consulting and engineering services. Richard is the head of research. Ginger, who is a musician and author, is the president. When they married, Richard gave Ginger all the stock in the company. Years later, a client required that Richard be a significant shareholder, so Ginger had to sell half her shares back to him. The price was fifty dollars.

When you ask Hipp about his greatest accomplishment, he does not say SQLite.

Convincing Ginger to marry me was the biggest thing I ever accomplished. Way harder than writing the most widely used database engine in the world.

What makes Hipp unusual in the open source world is not just his technical ability, though that is considerable. It is his pathological self-reliance. He wrote his own text editor. He wrote his own parser generator. He wrote his own version control system. He wrote his own mail server because he did not want to depend on Gmail. He once implemented a major database optimization, covering indexes, while sitting on a Delta Airlines flight over the Atlantic. Not planned. He just had the idea and started coding.

I do not like dependencies. I really like to statically link things, because with dynamic linking you just never know what version of a library you are going to link at runtime.

He keeps an old PowerPC iBook around not because he is nostalgic but because he needs a big-endian machine for testing. He has described himself as "eclectic," and when asked about impostor syndrome in the database world, he said he does not experience it, because he does not really belong to any particular group. He is a self-described weird person who happened to build something a trillion devices depend on.

His relationship with expertise is revealing. When he first conceived of SQLite, the conventional wisdom in the database community was that what he wanted to do was impossible. A real database needed a server. A real database needed a DBA. A real database did not live in a single file.

Fortunately, I did not know any experts, and so I did it anyway.

A Mineral, Not a Sequel

The name is simpler than you might think, but it has launched a pronunciation war that has lasted twenty-five years. SQL stands for Structured Query Language. The "lite" means lightweight, a lighter version that does not need the infrastructure of a full database server. Put them together and you get SQLite. But how do you say it?

There are two camps and no middle ground. The first camp says "sequel-ite," treating SQL as the word "sequel," which is how many people pronounce SQL itself, dating back to IBM's original System R project in the nineteen seventies where the query language was indeed called SEQUEL before a trademark conflict forced the name change. The second camp says "S-Q-L-ite," spelling out each letter and then adding "lite," which is how you would say it if you follow the ISO standard that the language is properly called S-Q-L, not sequel.

Hipp himself falls in the second camp.

I say S-Q-L-ite, like a mineral.

Like a mineral. That is the detail that sticks. Not like a product name, not like an acronym, but like something you would find in the ground. Selenite, malachite, graphite, SQLite. A naturally occurring thing, part of the geological substrate. And in a way, that is exactly what it has become. SQLite is not a product you choose. It is bedrock you discover was already there.

But Hipp is characteristically relaxed about the whole thing. "Whatever comes off of your tongue easily is fine with me," he has said. The official SQLite website uses the phrasing "an SQLite database" rather than "a SQLite database," which implies the S-Q-L pronunciation since "an" precedes a vowel sound. But it is not enforced. It is not litigated. It just is.

From a Destroyer to Your Pocket

The first version of SQLite was modest. Hipp posted about it on netnews, the precursor to modern web forums, and figured it would get maybe five downloads a year.

I figured it would be just another one of those things, five downloads per year. But it really resonated with people.

The resonance was immediate because Hipp had identified something real. Thousands of applications needed structured data storage but did not need, and could not justify, the overhead of running a database server. Embedded systems, mobile applications, desktop software, configuration storage, testing environments, data analysis scripts. The entire world of programs that needed more than a flat file but less than PostgreSQL. Before SQLite, the options were bad. You could use a full client-server database and deal with the installation and administration overhead, or you could write your own file format with your own query logic and deal with bugs that real database engines had solved decades ago. SQLite eliminated the choice by giving you a real SQL database that was also just a file.

The first big contract came in two thousand and one when Motorola needed enhancements for a phone project. Hipp quoted eighty thousand dollars, the work was done, and suddenly SQLite was in mobile phones. Not smartphones, this was years before the iPhone. Feature phones, the ones with number pads and tiny screens. But it was the beginning of a pattern.

Then came Symbian. In the mid two thousands, Symbian was the dominant smartphone operating system, powering most Nokia phones. They invited Hipp to London, flying him out on Thanksgiving Day, which meant missing his wife's family dinner. There was a competitive evaluation, a bake-off against nine other embedded database solutions. SQLite won. The contract meant SQLite would ship on every Nokia smartphone in the world.

In two thousand and five, something even bigger happened. Hipp was invited to meet with a secretive team at Google. They were working on an operating system for mobile phones, something that would eventually be called Android. They wanted SQLite as the native database layer. Hipp saw working phones running the early Android software and immediately recognized the potential.

When the iPhone launched in two thousand and seven, Apple chose SQLite too. Not because Apple and Google coordinated, but because both teams independently reached the same conclusion. If you needed a database on a phone, SQLite was the only serious option. It was small, it was fast, it was public domain so there were no licensing complications, and it did not need a server.

By the early twenty-tens, SQLite was everywhere. Chrome used it for browser storage. Firefox used it. Safari used it. Adobe used it. Skype used it. iTunes used it. The Python standard library shipped with a sqlite3 module. PHP bundled it. Every Mac had it pre-installed as a command-line tool. The United States Library of Congress recommended it as a storage format for digital archiving. It was, quietly and without fanfare, becoming the most widely deployed software component in history.

The Anti-Oracle

Here is the line that explains everything about what SQLite is and what it is not.

We do not compete against Oracle. We compete against fopen.

Fopen is the C standard library function for opening a file. That is the competition. Not PostgreSQL, not MySQL, not MongoDB. The alternative to SQLite is not another database. The alternative is writing your own file format, your own parsing logic, your own data integrity checks. Think of SQLite not as a lightweight database server but as a better way to save structured data to disk.

This positioning is deliberately chosen and fiercely maintained. Hipp has always been clear about what SQLite is not good at. High concurrency with many simultaneous writers, that is where it breaks down. If you have a hundred users hitting the same database at the same time, you want PostgreSQL or MySQL. But for the vast majority of applications, where you have one writer at a time or a handful of readers, SQLite is not just adequate, it is faster than a client-server database because there is no network overhead, no inter-process communication, no context switching between your application and a separate database process. Your application and your data are in the same process, talking through function calls, not sockets.

This is why the trillion-database number is real. Most of those databases are not serving web applications with thousands of concurrent users. They are your browser storing cookies. They are your phone recording which episodes of a podcast you have listened to. They are configuration files, caches, application state, message stores, photo metadata. Small databases, personal databases, databases where "just use a file" is the natural instinct and SQLite makes that instinct actually work.

The Six-Hundred-to-One Ratio

If the origin story makes SQLite sound like a casual side project that got lucky, the testing regime will disabuse you of that notion. SQLite is tested to a standard that most commercial software, including software people pay millions of dollars for, does not come close to matching.

The core SQLite library is approximately one hundred and fifty-five thousand lines of C code. The test suite, across four independent test harnesses, is approximately ninety-two million lines of test code and test scripts. That is a ratio of roughly five hundred and ninety lines of test code for every single line of production code. Most software projects consider a one-to-one ratio aspirational. SQLite has nearly six hundred to one.

The testing achieves one hundred percent branch coverage, meaning every single branch in the code, every if-else, every switch case, every conditional expression, has been exercised by a test. But SQLite goes further. It achieves one hundred percent MC/DC coverage, which stands for Modified Condition Decision Coverage. This is the testing standard required by DO-178B, the certification standard for avionics software. The code that runs your text messages is tested to the same standard as the code that runs commercial aircraft autopilot systems.

There are four separate test harnesses. The TCL test suite has over fifty-one thousand distinct test cases. TH3, the proprietary test harness, has over fifty thousand test cases that expand to approximately two point four million test instances. The SQL Logic Test compares SQLite's output against PostgreSQL, MySQL, SQL Server, and Oracle on seven point two million queries. And the fuzzer, dbsqlfuzz, evaluates roughly five hundred million cases every single day.

For a typical release, billions of individual tests are run across multiple architectures, including Intel, ARM, and PowerPC, both thirty-two and sixty-four bit, big-endian and little-endian. Hipp keeps that old PowerPC iBook specifically because he needs a big-endian test platform. There are over six thousand seven hundred assert statements embedded in the production code, each one a tripwire that fires if an internal assumption is violated.

Reaching this level of testing was not a weekend project. Hipp has described spending a full year working sixty-hour weeks to achieve one hundred percent MC/DC coverage. The motivation came from Android. In the early days, SQLite had occasional bugs that did not surface in normal testing. But Android's scale, running on millions of devices with wildly varying hardware, storage speeds, and usage patterns, exposed edge cases that had hidden for years.

We stopped getting bug reports from Android.

That single sentence represents what might be the most effective quality engineering effort in the history of open source software. The bug reports did not decrease. They stopped. On a platform with billions of active devices.

A Blessing Instead of a License

Every episode of this series has touched on licensing. MIT, BSD, GPL, the alphabet soup of permissions and restrictions that govern how open source software can be used. SQLite takes a different approach entirely. It is public domain. Not MIT, which still requires attribution. Not BSD, which still carries a copyright notice. Not even the permissive ISC license. Public domain means no license at all. No copyright. No restrictions of any kind. You can copy it, modify it, sell it, claim you wrote it, embed it in proprietary software, do anything you want with it. There are no strings.

The original version of SQLite was actually released under the GNU General Public License, the GPL. But when Hipp rewrote the storage engine for version two, replacing the dependency on GDBM with his own B-tree implementation, he had complete ownership of every line of code. And he decided to release it into the public domain.

What is the point?

That was his reasoning. What is the point of restricting it? If the software is useful, let people use it. This decision is inseparable from who Hipp is. He converted from atheism to Christianity as a college freshman at Georgia Tech, and his faith has shaped his approach to software ever since. When you look at the SQLite source code, where most projects have a copyright notice and a license, you find instead a blessing. "May you do good and not evil. May you find forgiveness for yourself and forgive others. May you share freely, never taking more than you give."

Everything that I am is by Grace alone. The longer I live and the more I see, the more obvious this fact becomes.

This is not a common posture in the software world. Most open source developers, even the most generous ones, retain copyright. The public domain dedication caused unexpected complications. It turns out that many legal jurisdictions, particularly in parts of Europe and Japan, do not recognize the concept of voluntarily placing work into the public domain. Copyright in those systems is considered an inalienable right that cannot be waived. So Hipp had to create a separate legal instrument, essentially a maximally permissive license that mimics public domain in jurisdictions where public domain does not legally exist. Companies that need this legal certainty can buy it from Hwaci.

This is, paradoxically, part of the business model. The code is free. The legal assurance that the code is free costs money.

The Patron and the Consortium

In two thousand and seven, Symbian approached Hipp with a concern. They were betting their entire platform on SQLite, and the bus factor was essentially one. If Richard Hipp got hit by a bus, the project would be in serious trouble. They proposed creating a consortium, a formal organization where companies that depended on SQLite would pay annual membership fees in exchange for dedicated support, priority bug fixes, and the assurance that the project would continue.

The SQLite Consortium launched in December two thousand and seven with Symbian and Mozilla as charter members. Adobe joined shortly after. The annual membership fee is one hundred and twenty thousand dollars per year. That sounds like a lot until you realize it is roughly the cost of half an engineer at a large technology company. For that price, a company gets guaranteed access to the people who actually write SQLite, priority attention for bugs that affect their products, and a vote in the project's direction.

Today the consortium includes Bloomberg, Mozilla, Bentley, and others. But here is what makes the model work, and why it is so different from every other open source sustainability story this series has covered. The consortium is not the only revenue stream. Hwaci also sells those public domain dedications for jurisdictions that need them. They sell extensions and proprietary enhancements. They do custom consulting work. The entire company is structured around engineering, not sales.

We are a one hundred percent engineering shop. There is no sales talk. When you talk to somebody at our company, you are getting direct no-nonsense talk with an engineer. You are not talking to salespeople.

Compare this to every other maintainer we have covered in this series. Azer Koculu unpublished his packages in a fight over a namespace. Kenneth Reitz raised thirty thousand dollars for requests development and the money vanished into controversy. Doug Wilson did eighty percent of Express's work for free while IBM sat on the trademark. Dominic Tarr handed event-stream to a stranger because maintaining it felt like being a dishwasher promoted to cook with no raise.

Hipp took a fundamentally different path. He never gave away control. He never took venture capital. He never let a corporation acquire his project. He built a small, independent company around the software, kept it small, kept it engineering-focused, and built a business model where the people who benefit most from SQLite pay to keep it alive. And when you ask him about getting rich, his answer is characteristically understated.

I probably could have made a lot of money if I had any business sense. But you know what, we make enough.

The Man Who Said No to Git

Most software projects use Git for version control. SQLite does not. Richard Hipp built his own version control system called Fossil, which he started developing in two thousand and six, and he has maintained it ever since. Fossil uses SQLite as its storage backend, which is the ultimate act of dogfooding. The version control system for the world's most widely deployed database stores its data in the world's most widely deployed database.

Hipp's criticisms of Git are specific and technical, not vague complaints. He objects to Git's five-layer mental model, where you have to think about the working directory, the staging area, the local HEAD, the remote tracking copy, and the actual remote. Fossil requires you to think about two locations. He objects to Git losing branch history, because Git branch tags are local information that is not synced and disappears once a branch is merged. Fossil preserves every branch permanently. He objects to Git's poor situational awareness, the difficulty of seeing what is happening across an entire project at a glance. Fossil has a built-in timeline that works in a web browser, including on mobile devices.

When he visited GitHub's offices, Hipp was surrounded by people who had built their careers and their company on Git.

I was the only Git skeptic present.

He did not convert. Fossil continues to be the version control system for SQLite, and it remains the most visible example of a serious software project that actively chose not to use Git. Every byte of SQLite's source code is tracked in a Fossil repository, which itself is a SQLite database. The recursion is complete.

There is a deeper principle here, the same one that drives everything about Hipp. He does not like depending on tools he did not write and cannot fully control. His text editor, his parser generator, his version control system, his mail server. Each one is a declaration of independence. Where most developers optimize for convenience, adopting the tools the community uses because integration is easier, Hipp optimizes for self-sufficiency.

Freedom means taking care of yourself. By doing things yourself, you control your own destiny. You have more freedom.

He has described keeping a lawnmower in his garage despite hiring a lawn service, just in case. That is the metaphor for his entire approach to software engineering.

The Code of Conduct That Quoted Saint Benedict

In October twenty eighteen, SQLite briefly became the center of a culture war that had nothing to do with databases. Hipp published a Code of Ethics for SQLite contributors that was adapted from the Rule of Saint Benedict, a sixth-century monastic code that governs how Benedictine monks live. The document included instructions like "do not kill," "do not commit adultery," "love your enemies," and "pray for your enemies in the love of Christ."

The reaction was immediate and fierce. Some developers were outraged that a major open source project was imposing religious rules on contributors. Others pointed out that the Rule of Saint Benedict had nothing to do with writing software. The story was covered by technology outlets, mainstream publications, even Christianity Today. Within a week, Hipp replaced the Code of Ethics with Mozilla's Community Participation Guidelines as the external-facing document, while noting that the Benedictine rule would remain the internal code for the SQLite developers themselves.

The episode revealed something important about the tension between personal conviction and public infrastructure. Hipp had been a practicing Christian for decades, and his faith was already embedded in the project. The blessing in the source code, "may you do good and not evil," is derived from the Lord's Prayer. The public domain dedication reflects a philosophy of giving freely. None of this had ever caused controversy because it was quiet, woven into the fabric of the software rather than stated as policy. The moment it became explicit, the same values that had always been there became contentious.

What Depends on Nothing

Here is what is remarkable about SQLite's dependency tree. There is almost nothing in it. SQLite has no external dependencies. It does not link against any third-party libraries. It does not require a package manager. It does not need a build system beyond a C compiler. The entire library compiles from a single C source file, known as the amalgamation, which is the concatenation of all SQLite source files into one enormous file of roughly two hundred and fifty thousand lines. You can drop that single file into any C or C++ project, add one header file, and you have a complete SQL database engine. No configuration, no installation, no downloads.

This is by design. Hipp has been explicit about it.

Every byte of source code is an original work that we control. It came from us.

The legal purity matters as much as the technical simplicity. When companies embed SQLite in their products, from smartphones to aircraft avionics to automobile infotainment systems, they need to know that every line of code has a clear, uncontaminated provenance. No copyleft surprises. No license conflicts. No unknown third-party code that might carry obligations. SQLite's zero-dependency, public-domain nature makes it the legally safest piece of software you can embed.

Now flip the dependency tree upside down. What depends on SQLite? The answer is: effectively everything. Python ships with a sqlite3 module in the standard library. PHP bundles it. Ruby's ActiveRecord supports it natively. Every web browser uses it for internal storage. Every smartphone operating system uses it for system services. Almost every desktop operating system includes it. It is in medical devices, in airplanes, in automobiles, in smart appliances. The Library of Congress recommends it as an archival format.

By some estimates, SQLite is the second most widely deployed software component in the world, behind only zlib, the compression library. Hipp has said it might be more widely deployed than all other database engines combined. Not more popular. Not more downloaded. More deployed, meaning more instances of it actually running on actual devices at this actual moment.

The Quiet Future

Richard Hipp was born in nineteen sixty-one, which makes him sixty-four years old as of this recording. He has been maintaining SQLite for over twenty-five years. The question that hangs over every long-running open source project, what happens when the creator stops, applies here too. But it applies differently.

The consortium exists specifically to address the bus factor. Dan Kennedy, who has contributed roughly forty percent of the core code, is the other major developer. There is a small team at Hwaci with deep knowledge of the codebase. The testing regime means that any future maintainer inherits not just the code but the most comprehensive safety net in open source. You cannot make a change to SQLite without knowing exactly what it breaks, because the test suite will tell you, immediately and comprehensively.

There is no succession drama brewing. No venture capital board that might force a sale. No corporate parent that might lose interest. Hwaci is a family company in Charlotte, North Carolina, and it will remain one for as long as the Hipps want it to be one. The code is public domain, so even in the worst case, anyone can fork it and continue. But the test suite, the TH3 harness that provides the aviation-grade coverage, that is proprietary. A post-Hipp SQLite would need to rebuild or replace that testing infrastructure, and that is not a trivial task.

The current trajectory, though, shows no signs of slowing. Recent versions have added JSON support, window functions, full-text search, and generated columns. There is active work on improving write-ahead logging performance and expanding the analytical capabilities that make SQLite useful for data science. The WAL mode, introduced in version three point seven, was a quiet revolution that dramatically improved concurrent read performance and made SQLite viable for workloads that would have previously required a server database. New projects like DuckDB, an analytical database engine that shares SQLite's embedded philosophy, show that the idea Hipp pioneered, the database as a file, is still generating new thinking twenty-five years later.

And Hipp keeps working. Not because he has to, not because investors are demanding growth metrics, not because users are filing angry issues. Because he finds it interesting. Because he has a lawnmower in the garage just in case, and a text editor he wrote himself, and a version control system that uses his own database, and a wife who is the president of his company, and a blessing in his source code instead of a license.

I had never intended to make any money off of SQLite. I wrote SQLite because it was useful to me, and I released it into the public domain with the hope that it would be useful to others as well.

That hope turned out to be the understatement of the century.

Where It Connects

In most Python projects, SQLite is already there, no install needed. It ships with the standard library, has since Python two point five. Web browsers use it. Mobile apps use it. Data science tools like DuckDB and LanceDB took direct inspiration from the SQLite philosophy of the database as an embedded file. Every iPhone and every Mac that listens to this podcast has hundreds of SQLite databases running silently in the background.

But here is what makes the SQLite story different from every other episode in this series. When you run pip install on a package that depends on requests, you are pulling in code maintained by volunteers who may or may not be funded, whose bus factor is uncertain, whose future is unclear. When you use SQLite, you are using code maintained by a financially stable, independent company, tested to aviation standards, with a clear succession plan and a business model that actually works. In a world of open source sustainability crises, SQLite is the proof that another way is possible. Not the only way, and perhaps not a way that scales to every project, but a way that has produced the most deployed software in the world, maintained by a man in Charlotte who thinks databases should be files and freedom means taking care of yourself.

That was episode six.

SQLite is already on your machine. Open a terminal and type sqlite3. You are now inside a database. Type dot tables and you will see nothing, because this is a fresh in-memory database. Type create table notes, give it an id integer primary key and a text column, then semicolon. Type insert into notes values one comma and a string of your choice. Type select star from notes and there it is. Now quit with dot quit and try sqlite3 colon memory colon for a disposable database that vanishes when you close it. If you want to see where SQLite already lives on your system, look inside your browser profile directory. Those dot sqlite files are real databases, and you can open every one of them.