The Database vs Your App

There's one last picture to fix, and it trips up almost everyone building their first real app. People imagine the database as a file their program opens, or as something that lives inside their app. For the databases you'll actually use at work, that's not how it works. The database is a separate program, often on a separate machine, that your app talks to. Once you see that clearly, a lot of confusing things - connection strings, "the database is on another server," passwords for the database - suddenly make sense.

The database is a server you talk to

A database like PostgreSQL or MySQL runs as its own long-lived program - a server - sitting and waiting for requests. Your application is a client: it opens a connection to that server, sends requests over it, and gets answers back. They are two separate programs having a conversation, even when they happen to run on the same computer.

The two are often on different machines, talking over the network.

📝 Terminology. Client–server = one program (the server) provides a service and waits for requests; other programs (clients) connect to it and make requests. Your web app is a client of the database server, exactly like your browser is a client of a web server.

Why people get this wrong. The simplest database you can meet - SQLite - really is just a file your program opens, with no separate server. SQLite is great and widely used, but it's the exception. The databases that power most websites and apps are servers, and assuming they behave like a local file leads straight to confusion the first time the database lives "somewhere else."

Because it's a separate server, the database has its own address (a host and a port), its own login (a username and password), and its own life independent of your app. You can restart your app without touching the data. You can have ten copies of your app, all talking to one database. This separation is the reason all that exists.

⚠️ Gotcha - "the database is on another server" is normal, not a misconfiguration. New developers often expect the data to live inside their app. In real systems the database almost always runs as its own process, frequently on its own machine, precisely so it can be shared, secured, and scaled on its own terms. The connection details (host, port, user, password - usually bundled into a connection string) are how your app finds and logs in.

SQL - the language you talk in

So your app sends requests to the server. In what language? For relational databases, the answer is SQL.

SQL (Structured Query Language) is the standard language for talking to relational databases. You write a statement that describes what you want, send it to the server, and the server figures out how to do it and sends back the result. You describe the goal; the DBMS does the work.

📝 Terminology. SQL is usually pronounced "sequel" or spelled out "S-Q-L" - both are common and both are fine. It's the language; PostgreSQL, MySQL, and friends are the databases that speak it (each with small dialect differences).

Here's the flavor of it - one of the most common requests, asking the server for matching rows:

SELECT name, city
FROM customers
WHERE city = 'London';

 name         | city
--------------+--------
 Ada Lovelace | London
(1 row)

What just happened: You described what you wanted - the name and city columns, from the customers table, but only the rows where the city is London - and sent that to the server. The server found the matching rows and handed back the answer: one row, Ada. You never told it how to search or where the rows physically live; the DBMS planned and ran it. That describe-the-goal style is the heart of SQL.

Here's the same shape you can run right now, against a tiny built-in authors table:

SELECT name, country
FROM authors
WHERE country = 'UK';

What just happened: Same move - name and country from authors, only the rows where the country is the UK - and back come the two matching authors.

You don't need to write SQL yet - that's a guide of its own. The point here is only that SQL is the conversation, and that conversation goes over a connection to a server.

Learning to actually read and write these statements - SELECT, WHERE, and the everyday queries you'll reach for - is the very next step: /guides/querying-basics-select-where.

A quick map of the landscape

You'll hear a lot of database names thrown around. Here's just enough of a map to place them, without going down the rabbit hole.

• Relational databases (SQL). Data in tables, connected by keys, queried with SQL. This is the default and the one to learn first. Common ones:

  • PostgreSQL - powerful, standards-respecting, hugely popular for new applications.
  • MySQL (and its cousin MariaDB) - long-established, everywhere on the web.
  • SQLite - the file-based one with no separate server; great for small apps, phones, and getting started.
  • SQL Server, Oracle - enterprise heavyweights you'll meet in larger companies.

  These differ in details and dialect, but the mental model from this guide - tables, rows, columns, keys, schema, SQL over a connection - applies to all of them.

• Everything else (often called "NoSQL"). A family of databases that organize data differently - as documents, key–value pairs, graphs, and more - for needs that the table model doesn't fit as neatly. They're not "newer and better" or "older and worse"; they're different tools for different shapes of problem.

⚠️ Gotcha - "NoSQL" is not one thing, and it's not the opposite of relational. It's an umbrella over several very different database types whose main shared trait is "not the classic relational table model." Treating it as a single alternative to SQL is the most common beginner misconception about the landscape.

When (and whether) to reach past relational gets a fair, two-sided treatment in its own guide: /guides/sql-vs-nosql. Start relational; learn the rest when a real problem pushes you there.

Recap

1. A database is a separate server program (a DBMS like PostgreSQL); your app is a client that opens a connection and talks to it - often across machines.
2. SQLite is the exception - a file with no server - which is why it can mislead your mental model of "real" databases.
3. You talk to relational databases in SQL: you describe what you want, the DBMS figures out how and returns the rows.
4. Relational (SQL) is the family to learn first; "NoSQL" is a broad umbrella of different models for different problems, covered elsewhere.

That's the whole "A" of databases: what one is (data plus a managing DBMS), how its data is shaped (tables, rows, columns, keys, schema), and how you reach it (a server you talk to in SQL). From here, the natural next move is to actually ask it questions.

← Guide overview · Next up: Querying Basics - SELECT & WHERE →