AvailableIncluded in beta access

Micro-course · Beginner

SQL, PostgreSQL, MySQL and SQL Server: what is the difference?

Understand the language, systems and dialects so you can choose the right documentation and write portable SQL with judgement.

45 to 60 minCommon SQL · PostgreSQL · MySQL · SQL Server5 lessons · 6 activities available

Start the course

Free 30-day beta access · no payment · progress saved

The business problem

A learner thinks they are learning PostgreSQL while learning SQL syntax, then discovers differences in another tool.

What you will be able to do

Distinguish language, database, DBMS, server and dialect, then recognise the differences that matter.

Name the four concepts without confusing them
Identify a dialect difference
Choose a resource suited to the system

Scope of this micro-course

This micro-course targets one focused skill. It does not replace a complete path or server administration training.

Prerequisites

Know what a table is

Project and practice

6 verified exercises are available. Validation is based on the programme exercises.

Interactive course · 5 micro-lessons · 6 checks

Understand database systems and dialects without mixing them up

Start with a real problem, compare syntax, then validate each decision against official documentation.

Progress0 / 6

0/6

Separate the language, data and software7–9 min · Explain SQL, database, DBMS, server and dialect clearly.

Business situation

A colleague says that “the SQL database is down”. This does not reveal whether the data, server, connection or a query is failing.

Question to solve

What exactly do we mean when we simply say SQL?

SQL is a language used to express an intention: read, join, add or control data.

A database is the organised set of data and its rules.

PostgreSQL, MySQL and SQL Server are DBMS products that store, protect and process data.

A server or instance runs the DBMS. A dialect is how a product implements and extends SQL.

Verified example

Language and softwareCommon SQL · PostgreSQL

SELECT expresses a read request; PostgreSQL checks permissions, selects a plan and returns the result.

Common mistake Calling PostgreSQL a version of SQL. It is a DBMS that uses SQL and adds its own capabilities.

Key point SQL states the intention; the DBMS interprets it and manages the data.

Which sentence correctly distinguishes SQL and PostgreSQL?SQL is a server; PostgreSQL is a querySQL is a language; PostgreSQL is a DBMSThey are two names for the same product

Official sources

Start with the common core7–9 min · Recognise a simple read query that is broadly portable.

Business situation

A team must produce the same simple report on PostgreSQL, MySQL and SQL Server.

Question to solve

Must it write three completely different queries?

SELECT, FROM, WHERE, GROUP BY, HAVING and ORDER BY form a widely shared core.

Portability also depends on types, functions, conversions, collations and NULL behaviour.

No engine guarantees row order without ORDER BY.

A portable query is a tested assumption for the target engines and versions.

Verified example

Basic reportCommon SQL

SELECT city, COUNT(*) AS orders
FROM orders
WHERE status = 'paid'
GROUP BY city
ORDER BY orders DESC, city;

The form is common, but data, types and sorting rules still need to be comparable.

Common mistake Assuming that accepted syntax automatically produces the same result in three configurations.

Key point Begin with the common core, then test the differences that matter.

Which statement is the safest?Every query containing SELECT is portableThe core may be shared, but the result must be tested on each targetEvery collation sorts text in the same way

Official sources

Recognise a dialect difference9–11 min · Adapt a row limit without changing the business intention.

Business situation

A copied query contains TOP (3) and fails in PostgreSQL.

Question to solve

Is the intention wrong, or only its expression?

Limiting a result is common, but historical syntax differs.

PostgreSQL and MySQL accept LIMIT. SQL Server offers TOP and OFFSET … FETCH.

PostgreSQL delimits identifiers with double quotes; MySQL often uses backticks; SQL Server notably accepts brackets.

Simple, non-reserved identifiers reduce migration work.

Verified example

Three rowsPostgreSQL · MySQL

SELECT id, amount
FROM orders
ORDER BY amount DESC, id
LIMIT 3;

LIMIT follows ORDER BY.

Three rowsSQL Server

SELECT TOP (3) id, amount
FROM orders
ORDER BY amount DESC, id;

TOP belongs to T-SQL; ORDER BY makes the choice reproducible.

Common mistake Removing ORDER BY to hide the error: the three rows would no longer follow the business rule.

Key point Preserve the intention and result, not just the words.

Which syntax commonly limits PostgreSQL to three rows?TOP (3)LIMIT 3FIRST 3 ROWS

Why keep ORDER BY?To select rows through a reproducible ruleTo speed up every query automaticallyTo convert TOP into LIMIT

Official sources

Choose the right documentation7–9 min · Find a reference suited to the product, version and context.

Business situation

A solution works on MySQL 8.4 while the project uses SQL Server. The word SQL hid the difference.

Question to solve

What should you check before copying syntax?

Identify the real DBMS and version before searching.

Prefer official documentation and check applicability.

Distinguish the standard, a vendor extension and configuration-dependent behaviour.

Reproduce the example with ties, NULL and boundary cases.

Verified example

Precise searchPostgreSQL

“PostgreSQL 18 SELECT LIMIT documentation” is safer than “SQL error”.

Common mistake Treating an article’s recent date as proof that it matches your engine.

Key point Good documentation starts with the right context.

Which search provides the strongest context?SQL errormodern queryPostgreSQL 18 SELECT LIMIT documentation

Official sources

Port a query without guessing9–11 min · Adapt a query while preserving its business contract.

Business situation

A report must move from SQL Server to PostgreSQL without changing rows or amounts.

Question to solve

What must remain stable before syntax changes?

Write the result contract: columns, grain, filters, order, NULL handling and expected values.

List sensitive areas: dates, strings, conversions, JSON, identities, functions and procedures.

Adapt one difference at a time and replay the same test.

Compare useful values and types, not only the absence of errors.

Verified example

ContractCommon SQL

Return exactly three orders, sorted by descending amount then ascending identifier.

AdaptationPostgreSQL

SELECT id, amount
FROM orders
ORDER BY amount DESC, id
LIMIT 3;

The test checks both rows and order.

Common mistake Rewriting everything at once and losing track of which change altered the result.

Key point A successful port preserves the business contract on a control dataset.

Which check best proves that a port is correct?The query raises no errorThe SQL text is shorterExpected columns, rows, values and ordering are preserved

Official sources

← Back to the full catalogue