What Is a Database and Do I Need One?
Every application that stores data needs somewhere to put it. A database is that somewhere. It is software specifically designed to store, organize, and retrieve data efficiently and reliably.
You might be thinking: I already store data in spreadsheets. Why do I need a database? The answer is that spreadsheets are adequate for data you manage manually and that grows slowly. Databases are necessary when your data is being created and read by an application — when you want a website to display user information, when you want to store customer orders, when you want to search through thousands of records instantly. Spreadsheets break under this kind of workload. Databases are designed for it.
Understanding databases is fundamental to building any real application — and understanding which data you own and control is fundamental to sovereignty.
The Two Types You Need to Know
There are many database systems, but for most builders, two cover the vast majority of use cases:
Relational databases (SQL): Organize data in tables — like spreadsheets — with defined relationships between tables. You interact with them using SQL (Structured Query Language), a standardized language that has not changed fundamentally in 50 years. The major relational databases are PostgreSQL, MySQL, and SQLite.
Document databases (NoSQL): Store data as flexible JSON documents rather than rigid tables. MongoDB is the most popular. They are easier to start with for unstructured data but can make complex queries more difficult.
For new builders, learn relational databases first. SQL skills are transferable across PostgreSQL, MySQL, SQLite, and every major cloud database service. Document databases have a smaller learning curve initially but a steeper one as your data relationships become complex.
SQLite: The Starting Point for Every Builder
SQLite is the most widely deployed database in the world. Every Android phone, every iPhone, every Mac, every Firefox and Chrome installation has SQLite databases running inside it. It is embedded in countless applications.
What makes SQLite uniquely valuable for builders:
Zero setup: SQLite is a single file. There is no server to install, no configuration, no credentials to manage. You point your application at a file path, and that is your database.
Full SQL support: Despite being serverless, SQLite supports nearly the full SQL standard — tables, indexes, transactions, complex queries, joins.
Portability: Your entire database is a single file. Copy the file to back it up. Email it to a colleague. Open it with any SQLite browser.
Performance: For applications with under a few thousand simultaneous users, SQLite is fast. Many production applications — including Notion’s file sync system — run SQLite in contexts most people assume require a heavy server.
When to use SQLite:
- Personal projects and tools
- Desktop applications
- Small web applications with low concurrency
- Scripts that need persistent storage
- Prototyping before moving to a larger database
In Python:
import sqlite3
# Create or open a database
conn = sqlite3.connect("my_business.db")
cursor = conn.cursor()
# Create a table
cursor.execute("""
CREATE TABLE IF NOT EXISTS customers (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL,
email TEXT UNIQUE,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
)
""")
# Insert data
cursor.execute("INSERT INTO customers (name, email) VALUES (?, ?)",
("Amara Osei", "amara@example.com"))
conn.commit()
conn.close()This is the complete workflow for creating and writing to a SQLite database. No server, no credentials, no configuration.
PostgreSQL: When Your Application Grows
PostgreSQL (Postgres) is the production-grade open source database that powers some of the largest applications on the internet. Instagram, Reddit, and Spotify have all used or use PostgreSQL. It is free, open source, and actively maintained by a community rather than a single company.
Move from SQLite to PostgreSQL when:
- Multiple users or processes need to write to the database simultaneously
- Your data grows beyond tens of thousands of rows
- You need advanced features: full-text search, JSON operations, geospatial queries, replication
PostgreSQL runs as a server process, requires installation and configuration, and uses credentials for access. This adds operational complexity but gives you a database that scales to billions of rows.
Self-hosting PostgreSQL is straightforward on any Linux server. Managed PostgreSQL services (Supabase, Neon, Railway) provide PostgreSQL with automatic backups, scaling, and monitoring — at a monthly cost but without the operational burden.
Key principle: Use a managed service if the operational simplicity is worth the cost. Run your own Postgres server if you want full control and lower ongoing cost. Both options give you your data — no lock-in.
What About MySQL?
MySQL is another popular open source relational database. It is functionally similar to PostgreSQL for most use cases. MySQL is owned by Oracle, which creates minor sovereignty concerns — Oracle has historically been aggressive about commercial licensing. The community edition is free, but the trajectory is less predictable than PostgreSQL, which is controlled by a nonprofit community.
For new projects, choose PostgreSQL over MySQL. The technical differences are minor; the ownership structure matters.
Your Data, Your Sovereignty
Every database you choose should be one you can export from. PostgreSQL and SQLite both support standard SQL dumps — plain text files containing your entire database. You can take that dump and import it into any other SQL-compatible database.
When you store data in proprietary cloud databases — Firebase, Airtable at scale, DynamoDB — you are renting storage. Migration is difficult, export formats are sometimes proprietary, and you are dependent on the provider’s continued service and pricing.
The sovereign choice is always the open standard. PostgreSQL data is your data. SQLite data is your data. A file on a drive you control, in a format that any database can read.
Own your data. It is the most basic form of digital sovereignty.