Every example in this course runs on standard SQL that works the same across SQLite, PostgreSQL, and MySQL, the three most common databases you'll run into. Where a specific example needs a database-specific feature, that will be called out directly. This lesson is just about getting a database running so you can actually type the queries yourself.
Learning Objectives
- Compare SQLite, PostgreSQL, and MySQL on setup effort and typical use.
- Get a working database running with no server to install.
- Know when you'd reach for PostgreSQL or MySQL instead.
| Database | Setup | Good for |
|---|---|---|
| SQLite | Nothing to install, it's a single file | Learning, small apps, local tools |
| PostgreSQL | Install a server, or use a free hosted tier | Most production web apps |
| MySQL | Install a server, or use a free hosted tier | Production web apps, especially WordPress-style stacks |
Start With SQLite
For this course, use SQLite. There's no server to install or configure, a SQLite database is just a single file on your computer, and every query you'll learn here runs on it exactly the same way it would on PostgreSQL or MySQL. You can always move to a server-based database later once the concepts are second nature.
- DB Browser for SQLite, a free visual tool, is the easiest way to start: create a database, run queries, and see results in a table, all in one window.
- Most code editors also have a SQLite extension if you'd rather stay in your editor.
- Python, Node.js, and most other languages can also open a SQLite file directly with no extra setup, useful once you start connecting SQL to actual code.
Install
DB Browser for SQLite
Create a DB
One new .db file
Run a Query
Type SQL, click Execute
See Results
Rows appear in a table
When You'd Reach for PostgreSQL or MySQL
SQLite is intentionally simple: it doesn't handle many users writing to it at the same time well, which is fine for learning or a small local tool, but not for a real web application with multiple users. PostgreSQL and MySQL are full database servers built for exactly that, many connections, concurrent writes, and large amounts of data. Most production web applications use one of the two.
Don't worry about picking the "right" one yet. The SQL you learn here transfers directly, switching databases later is mostly a matter of connection details, not relearning the language.
Frequently Asked Questions
Can I just use an online SQL playground instead of installing anything?
Yes, several free browser-based SQL sandboxes exist and work fine for following along with the basics. Installing DB Browser for SQLite is still worth doing early on though, since it's how you'd actually work with a real local project.
Will the queries in this course work if I use PostgreSQL instead of SQLite?
For the lessons in this course, yes, they all use standard SQL. Later topics like auto-incrementing IDs, specific data types, or advanced functions do differ between databases, and this course will call those differences out explicitly when they come up.
Do I need to know a programming language to learn SQL?
No. SQL is independent of any programming language, you can write and run SQL queries directly in a tool like DB Browser for SQLite with no code at all. Knowing a language like Python or JavaScript becomes useful later, when you want an application to run SQL queries for you automatically.
Common Beginner Mistakes
Installing a full PostgreSQL or MySQL server before writing a single query
This adds setup friction, accounts, ports, services, before you've even confirmed you like writing SQL. SQLite gets you running your first real query in under a minute, with nothing to install beyond one free tool.
Assuming switching databases later means relearning SQL
It doesn't. The SQL you write in SQLite runs on PostgreSQL and MySQL almost unchanged for everything covered in this course. Switching is mostly a matter of connection details, not relearning the language.
Trying to learn on a live, production-grade hosted database
Real credentials, connection strings, and shared data add risk and friction that have nothing to do with learning SQL itself. Get comfortable with syntax locally first, on a database only you can touch.
Dismissing SQLite as "not a real database" because it's just a file
SQLite is used in production inside countless real applications, mobile apps, browsers, and embedded systems among them. It's simple by design, not incomplete, it's just not built for many simultaneous writers.
Best Practices
- Start with SQLite for the fastest path to running your first query, with zero setup friction.
- Use a visual tool like DB Browser for SQLite rather than only the command line while you're still learning.
- Move to PostgreSQL or MySQL once you actually need multiple simultaneous users or connections, not before.
- When you do pick a production database, default to PostgreSQL unless you have a specific reason to prefer MySQL, such as existing WordPress-style hosting.
Interview Questions
What's the practical difference between SQLite and a server-based database like PostgreSQL?
SQLite has no separate server process, the calling application reads and writes the database file directly, which makes it simple but limits how well it handles many writers at once. PostgreSQL and MySQL run as a standalone server process that many client connections talk to over a network, built specifically to handle concurrency.
When would you choose SQLite in a real production application, not just for learning?
When the data is local to one device or process and doesn't need many concurrent writers, mobile apps, desktop tools, browsers, and embedded devices all commonly ship SQLite as their storage layer.
If a query runs fine in SQLite, is it guaranteed to work unchanged in PostgreSQL or MySQL?
Not always, auto-incrementing primary keys are a common example that differs by database: SQLite uses INTEGER PRIMARY KEY AUTOINCREMENT, PostgreSQL uses SERIAL PRIMARY KEY, MySQL uses INT AUTO_INCREMENT PRIMARY KEY, and SQL Server uses INT IDENTITY(1,1) PRIMARY KEY. Same intent, four different keywords, shown in full in the code example below.
What does it actually mean that SQLite "doesn't handle concurrent writes well"?
SQLite locks the entire database file for the duration of a write. A second writer arriving at the same moment has to wait for the first to finish rather than writing in parallel, fine for a single user, a real bottleneck once many users write at the same time.
Auto-Increment Syntax Differs by Database
Same intent, four different keywords. This is exactly the kind of thing that works fine while learning on one database and then breaks the moment the same CREATE TABLE statement runs against a different one, covered in full in the Creating Tables lesson later in this course.
CREATE TABLE employees ( id INTEGER PRIMARY KEY AUTOINCREMENT, first_name TEXT );
CREATE TABLE employees ( id SERIAL PRIMARY KEY, first_name TEXT );
CREATE TABLE employees ( id INT AUTO_INCREMENT PRIMARY KEY, first_name VARCHAR(255) );
CREATE TABLE employees ( id INT IDENTITY(1,1) PRIMARY KEY, first_name VARCHAR(255) );
Summary
This lesson compared SQLite, PostgreSQL, and MySQL on setup effort and typical use, got a SQLite database running with nothing to install, and covered when you'd actually reach for a server-based database like PostgreSQL or MySQL instead. The SQL you write against SQLite here transfers directly once you do.
What's Next?
With a database running, the next lesson writes your first real queries: SELECT, picking specific columns, selecting everything, and renaming a column in the result with AS.