SQL Databases

These pages cover the database engines that speak SQL. They share most of the language but differ in setup, scale, and where they fit best. If you are weighing them against each other, the comparisons put them head to head.

Where Each Engine Actually Fits

MySQL became the default database for the LAMP stack years, the well-known pairing of Linux, Apache, MySQL, and PHP that ran a huge share of the early web on a single rented server. That history left it with an enormous ecosystem: managed hosting nearly everywhere you look, and drivers for every programming language still in common use. Oracle now owns the trademark and steers development, offering MySQL under a dual license, open source under the GPL alongside a separate commercial license for vendors who need one. It still handles ordinary web traffic well, and the old gap with PostgreSQL on complex queries has narrowed considerably over the years.

PostgreSQL grew out of an academic project at Berkeley aimed at extending SQL with richer data types and stronger constraints, and that lineage still shows in how seriously it takes standards compliance. It handles complex queries and unusual data types better than most alternatives, and extensions add real capabilities on top of that, things like geographic data or full text search. Its reputation for being harder to set up than MySQL is mostly outdated at this point, and its replication and backup tooling has matured into something teams run in production with real confidence.

SQLite works nothing like a typical server-based database. The entire engine is a library that your application links against directly, and the whole database lives in a single file on disk, with no separate server process or network protocol to manage. That simplicity makes it reliable for local tools, desktop apps, mobile apps, and embedded devices, and it's tested well enough that it quietly runs inside an enormous number of everyday products. It struggles the moment a busy multi-user web backend needs several processes writing to the same database at once, because SQLite still assumes one writer at a time.

MariaDB exists because MySQL's original developers forked the project after Oracle acquired the company that owned it, worried about who would control its future direction. The fork kept the same wire protocol and most of the same SQL syntax, so it still works as a close drop-in replacement for a large share of MySQL workloads. It remains fully community-governed rather than steered by a single vendor, which is the reason some teams pick it over MySQL even though the two behave almost identically day to day.

Picking Among Them

Start with PostgreSQL for a new server-side application unless you already have a specific reason not to. Its standards compliance and query flexibility give you more room to grow into complex reporting or analytics later without hitting a wall. Stick with MySQL or MariaDB when your team or hosting setup already has deep experience with one of them, since familiarity and existing tooling usually beat a marginal technical edge on paper. Reach for SQLite the moment the job is local rather than networked: a desktop app, a mobile app, a command-line tool, or a prototype you want to keep in one portable file. Choose MariaDB specifically over MySQL when open governance matters to your organization or when you're moving away from MySQL over licensing concerns, since it gives you nearly the same behavior without a single company controlling the roadmap.

Databases

• MySQL: the long-time default for web apps, widely hosted and documented.
• PostgreSQL: the feature-rich, standards-leaning choice for serious data work.
• SQLite: a whole database in a single file, perfect for local and embedded use.
• MariaDB: the community fork of MySQL, drop-in for most projects.

What to Read Next

• SQL Comparisons: which engine to pick, and SQL vs NoSQL.
• SQL Guides: the concepts that apply across all of them.

Frequently Asked Questions

Do MySQL and MariaDB read each other's data?

Largely yes for ordinary tables, since MariaDB forked from MySQL and kept close file and protocol compatibility. Features added to either since the fork are not guaranteed to carry across, so treat compatibility as historical rather than ongoing.

Is PostgreSQL slower than MySQL for simple lookups?

Not meaningfully, for ordinary indexed queries on either. The differences that mattered years ago have narrowed, and a real performance question is answered by measuring the actual query rather than by an engine's reputation.

Does SQLite need a server process?

No, which is what separates it from the others. SQLite is a library the application links against, with the whole database in one file, no network protocol, and nothing to start or administer.

Can one application use several database engines at once?

Yes, at a real cost: separate connections, separate migration tooling, and no transactions spanning them. It is a deliberate architectural choice, such as SQLite for local caching alongside a networked primary.