Databases for Beginners: Why Everyone Says Postgres

Think about what happens when you build a to-do app without a database. You write some JavaScript, you render tasks on the page, the user adds a few items. Then they close the browser. Everything is gone. When they come back, the list is empty. That is because the data lived only in the browser's memory, and memory gets wiped the moment you close the tab.

A database solves this. It is a piece of software that stores data on disk so it survives browser closures, server restarts, and power outages. When your user comes back tomorrow, their to-do items are still there because the database saved them.

Every real application you use has a database behind it. When you log into Twitter and see your timeline, that content is being pulled from a database. When you send money via M-Pesa, the transaction gets recorded in a database. When you sign up for a website and your account still exists next week, that is a database doing its job. If code is the brain of your application, the database is the memory.

As a beginner, you will typically not interact with the database directly in production. You will write code that talks to the database through your backend (Node.js, Python, or whatever you are using). But understanding what the database does and how to write basic queries is fundamental. You cannot build anything meaningful without it.

Databases fall into two broad categories, and beginners often get stuck trying to decide between them before they even understand what either one does. Here is the simple version.

SQL databases (also called relational databases) store data in tables. Think of them like spreadsheets. You have columns (name, email, age) and rows (one row per user). Every row follows the same structure. If your users table has a "name" column, every user must have a name. This strictness is a feature, not a limitation. It prevents messy data and makes it easy to query exactly what you need. The most popular SQL databases are PostgreSQL, MySQL, and SQLite.

NoSQL databases store data in more flexible formats, usually as "documents" that look like JSON objects. Each document can have different fields. One user document might have a phone number, another might not. This flexibility is useful when your data structure changes frequently or when you are dealing with large amounts of unstructured data. The most popular NoSQL databases are MongoDB, Firebase (Firestore), and Redis.

The honest reality: for most web applications, especially the ones you will build as a beginner, SQL databases are the better choice. They force you to think about your data structure upfront, which is a good habit. They have been around for decades, so the tooling, documentation, and community support are excellent. And the vast majority of job listings expect you to know SQL.

NoSQL has its place. If you are building a real-time chat app, a content management system with wildly different content types, or an application that needs to scale horizontally across multiple servers, NoSQL can make sense. But those are problems you will encounter later. For your first project, SQL is the right call.

If you ask ten experienced developers which database a beginner should learn, at least seven will say PostgreSQL (often called Postgres). There are good reasons for this.

It is genuinely free. Not "free with a catch" or "free until you need feature X." PostgreSQL is open source. You can use it for personal projects, commercial products, or anything else without paying a cent. Ever.

It works with everything. Every major web framework has first-class PostgreSQL support. Node.js, Django, Rails, Laravel, Spring. Every hosting platform supports it. Vercel, Railway, Render, AWS, Supabase (which is built entirely on top of Postgres). You will never find yourself in a situation where your database choice limits your framework options.

It scales from side project to production. Postgres is not a "learning database" that you outgrow. Companies like Apple, Instagram, and Spotify use PostgreSQL in production. When you learn Postgres as a beginner, you are learning the same tool you will use professionally.

The job market expects it. Look at backend developer job listings in Kenya or anywhere else. PostgreSQL appears far more often than MongoDB or MySQL. Knowing Postgres means knowing what employers are already using.

Supabase makes it beginner-friendly. If setting up a local Postgres installation sounds intimidating, Supabase gives you a hosted PostgreSQL database with a visual dashboard, authentication, and an API layer, all for free on the starter plan. You get a real Postgres database without the setup headaches.

MySQL is also a solid SQL database, and you will see it in plenty of older applications (especially anything built with PHP or WordPress). The SQL you learn with Postgres transfers directly to MySQL. The differences are minor and mostly matter at scale.

SQL (Structured Query Language) is how you talk to a SQL database. It reads almost like English, which makes it one of the more approachable languages to learn. Here are the four commands you will use constantly.

SELECT: Reading data

SELECT name, email FROM users;
SELECT * FROM users WHERE age > 25;
SELECT * FROM products WHERE price < 1000 ORDER BY price;

SELECT pulls data out of the database. The first example gets the name and email of every user. The second gets all columns for users older than 25. The third gets products under 1000, sorted by price. You will write SELECT queries more than any other type.

INSERT: Adding data

INSERT INTO users (name, email, age) VALUES ('Kiptoo', 'kiptoo@email.com', 26);

INSERT adds a new row to a table. When someone signs up for your app, your backend runs an INSERT to save their information to the database.

UPDATE: Changing existing data

UPDATE users SET email = 'new@email.com' WHERE id = 42;

UPDATE modifies rows that already exist. The WHERE clause is critical here. Without it, you would update every single row in the table. Always include a WHERE clause with UPDATE unless you genuinely want to change every row.

DELETE: Removing data

DELETE FROM users WHERE id = 42;

DELETE removes rows. Same warning as UPDATE: always use a WHERE clause. Running DELETE FROM users without a WHERE clause will delete every user in your table. In production, many developers use "soft deletes" instead, where you set a deleted_at timestamp rather than actually removing the row.

These four commands, combined with WHERE clauses to filter results, will handle the vast majority of what you need for your first several projects. There is more to SQL (JOINs, subqueries, GROUP BY, indexes), but you can learn those as your projects demand them.

The WHERE clause deserves its own section because it is what turns SQL from "get everything" into "get exactly what I need." Without WHERE, every query returns every row in the table. With it, you can be precise.

Basic comparisons:

SELECT * FROM users WHERE age = 30;
SELECT * FROM users WHERE age > 25;
SELECT * FROM users WHERE age >= 18 AND age <= 30;
SELECT * FROM products WHERE price < 500;

Text matching:

SELECT * FROM users WHERE name = 'Amara';
SELECT * FROM users WHERE email LIKE '%@gmail.com';

The LIKE keyword with % is a wildcard. The example above finds every user whose email ends with @gmail.com.

Combining conditions:

SELECT * FROM products WHERE category = 'electronics' AND price < 5000;
SELECT * FROM users WHERE country = 'Kenya' OR country = 'Nigeria';

AND means both conditions must be true. OR means at least one must be true. You can combine as many conditions as you need. These patterns cover most of the filtering you will do in real applications. When a user searches for products in a specific price range and category on your site, your backend is building a SELECT query with WHERE clauses behind the scenes.

One common beginner mistake: forgetting that SQL uses a single = for comparison, not == like JavaScript. In SQL, WHERE age = 30 is a comparison, not an assignment. Small difference, but it trips people up when they are switching between JavaScript and SQL in the same project.

In a real application, your data is not one big table. It is multiple tables that relate to each other. Understanding this is the key concept that separates "I can write a query" from "I can design a database."

Take a simple e-commerce app. You might have:

• A users table (id, name, email)
• A products table (id, name, price, description)
• An orders table (id, user_id, created_at)
• An order_items table (id, order_id, product_id, quantity)

The user_id in the orders table links each order to a specific user. The order_id and product_id in order_items link each item to an order and a product. These links are called "foreign keys," and they are what make relational databases relational.

When you want to find all orders for a specific user, you use a JOIN:

SELECT orders.id, orders.created_at, users.name
FROM orders
JOIN users ON orders.user_id = users.id
WHERE users.email = 'kiptoo@email.com';

JOINs are where SQL starts feeling powerful. Instead of making multiple separate queries ("first get the user, then get their orders, then get the items in each order"), you can pull all that data in a single query. You do not need to master JOINs before building your first project, but knowing they exist and roughly how they work will help you understand the database designs you see in tutorials and codebases.

The key principle: each table should represent one "thing" (users, products, orders). Relationships between things get expressed through foreign keys. This keeps your data organised, reduces duplication, and makes queries predictable.

You have the theory. Here is how to get hands-on without drowning in setup.

Option 1: Supabase (recommended for beginners). Create a free account at supabase.com. You get a hosted PostgreSQL database with a visual table editor, which means you can create tables by clicking buttons instead of writing SQL. But the SQL editor is also right there when you want to practice queries. Supabase also gives you an API automatically, so you can connect it to your React or Node.js project with minimal setup.

Option 2: SQLite for local projects. SQLite is a database that stores everything in a single file on your computer. No server to install, no configuration. It is built into most programming languages. For learning SQL syntax and building small projects, SQLite is the fastest way to get started. Just know that it is not what you would use for a production web application.

Option 3: Install PostgreSQL locally. Download it from postgresql.org and install it on your machine. This gives you the full experience of running a real database server. It is more setup than the other options, but you learn the most from it. On macOS, Postgres.app makes installation trivial.

Option 4: Railway or Render. Both platforms let you spin up a free PostgreSQL database in the cloud. You get a connection string that you paste into your application code. Simple and production-like.

Whichever option you choose, the SQL you write is the same. The commands you learned in this article work identically on Supabase, local Postgres, Railway, or anywhere else. That is the beauty of learning SQL rather than a database-specific tool. The skill is portable.

If you are following a structured learning path, databases typically come after you have built a basic frontend and learned some backend fundamentals. You do not need to learn databases on day one. But when your project needs to save data permanently, come back to this guide and pick an option. Start with Supabase if you want the easiest path, or local Postgres if you want the deepest understanding.