Which database should I use? Postgres, MySQL, SQL Server

For a new application with no constraints, use PostgreSQL. It is free at any size, standards-compliant, handles relational data and JSON documents equally well, and has the deepest set of extensions of any open-source database. Use MySQL when the software you are running expects it - WordPress, most PHP applications, a lot of game-server plugins. Use SQL Server when you are building on .NET with a team that already knows it, or you are inheriting a database that is already there, and know that the free Express edition stops at 10 GB per database. Use MongoDB when your data is genuinely document-shaped and your application was built around it. And use Valkey next to any of them, not instead of them: it is a fast in-memory store for caches, sessions, queues and rate limits, not a primary database.

That paragraph is the answer for most people. The rest of this guide explains the reasoning, so that you can tell when your situation is the exception.

The short version, by job#

The most important column is the third. Databases are rarely chosen on benchmarks; they are chosen by what your software, your framework and your team already assume. Fighting that costs more than any performance difference between them.

PostgreSQL: the default for new work#

PostgreSQL is an open-source relational database with thirty years of development, a permissive licence and no paid edition. Its strengths are breadth and correctness: transactional DDL (a failed migration rolls back cleanly), rich types (arrays, ranges, jsonb, network addresses), proper CHECK constraints, window functions, common table expressions, partial and expression indexes, and an extension system that adds whole capabilities - PostGIS for geography, pg_trgm for fuzzy text search, pgvector for embeddings, TimescaleDB for time series.

jsonb deserves particular mention, because it removes the most common reason people reach for MongoDB. You can store a document in a column, index inside it with a GIN index, query it with operators, and still join it to ordinary tables in the same transaction.

The costs are known and manageable. Each connection is a separate operating-system process, so hundreds of idle connections cost real memory and an application with many workers wants a connection pooler - connection pools and limits covers this. Its multi-version design leaves dead rows behind that autovacuum has to clean, which needs a little attention on heavily updated tables. Neither is a reason to choose something else; both are things to understand in your first month.

If you are deciding between PostgreSQL and its two nearest rivals specifically, MySQL vs PostgreSQL and Postgres or MongoDB go into more depth.

MySQL: when the software expects it#

MySQL is the most widely deployed open-source database on the web, largely because PHP grew up with it. WordPress, Drupal, Joomla, Magento, phpBB, and the great majority of PHP applications are written against MySQL first. In the game-server world, permission plugins, economy plugins and frameworks such as FiveM's oxmysql all expect MySQL. Running that software on anything else ranges from unsupported to impossible.

Modern MySQL is a capable database. InnoDB has been the default engine for over a decade, with transactions, foreign keys and crash safety. MySQL 8 added window functions, common table expressions, a proper data dictionary and much better JSON support. MySQL 8.4 is a long-term support release, which matters for a database you do not want to upgrade every quarter; it also disabled the old mysql_native_password authentication plugin by default, which is the main thing that breaks old clients connecting to it. MySQL 8.4 LTS: what changed has the details.

Where MySQL is weaker than PostgreSQL is in the corners: fewer index types, weaker CHECK constraint history, DDL that is not transactional, and a long tail of historical defaults - the three-byte utf8 character set being the classic - that new projects have to know to avoid. Use utf8mb4 everywhere. For software that expects MySQL, none of this matters; you use MySQL. For a new application with a free choice, it is the reason PostgreSQL tends to win.

SQL Server: .NET, existing estates, and the Express ceiling#

SQL Server is Microsoft's relational database, and since 2017 it runs on Linux as well as Windows. Its strengths are tooling and integration. SQL Server Management Studio is still the best free database GUI, the query optimiser is excellent, execution plans and Query Store make performance work unusually visible, and the whole .NET stack - Microsoft.Data.SqlClient, Entity Framework Core, ASP.NET Core Identity - treats it as the home database. T-SQL is a capable procedural language, and a team that knows it is productive in it. T-SQL basics for app developers covers what differs from the open-source engines.

The free edition is Express, and its limits are the whole decision:

For a great many applications - an internal tool, a line-of-business app, a small SaaS, a game community's website - 10 GB is years of data, and Express is a fine production database. The risk is what happens when you outgrow it. The next step is Standard edition, which is licensed per core and costs real money, unlike every other database in this list. Choose SQL Server for its tooling and your team, not by default, and estimate your data growth honestly before you commit. SQL Server Express hosting works through where the ceiling bites.

If you are on .NET without an existing SQL Server, PostgreSQL through Npgsql is an equally first-class choice with no ceiling. .NET with PostgreSQL, MySQL or SQL Server compares the providers.

MongoDB: when the data is really documents#

MongoDB stores JSON-like documents (BSON) in collections, without a fixed schema. It suits data that is naturally nested and read as a whole - a product with variable attributes, a user profile with embedded preferences, an event payload - and applications that change shape quickly. Its aggregation pipeline is powerful, its drivers are pleasant, and horizontal scaling through sharding is built in, though few small projects ever need it.

The cost shows up when the data turns out to be relational after all. Joins exist ($lookup) but are not what MongoDB is good at, so data that many entities share tends to be duplicated into each document and then has to be kept in sync. Multi-document transactions exist since MongoDB 4.0, but only on a replica set or sharded cluster: a single standalone mongod does not support them, which matters if you are counting on them. And "schemaless" in practice means the schema lives in your application code, where it is harder to see and enforce - validation rules on collections help.

A useful test: sketch the five queries your application runs most often. If most of them fetch one document by key and display it, MongoDB fits well. If most of them join or aggregate across several kinds of thing, use PostgreSQL, and put the genuinely variable parts in jsonb. MongoDB indexes and schema design covers designing for the first case.

Valkey: the second database, not the first#

Valkey is an in-memory key-value store, forked from Redis in 2024 after Redis changed its licence, and compatible with the Redis protocol, commands and client libraries. Everything lives in memory, which makes reads and writes take microseconds, and it offers data structures - hashes, lists, sets, sorted sets, streams - that map directly onto common problems:

• Caching query results or rendered fragments with a TTL.
• Sessions for web applications, shared between several app processes.
• Queues for background jobs, through libraries such as BullMQ, Celery and Sidekiq.
• Rate limiting with atomic counters that expire.
• Leaderboards with sorted sets.
• Pub/sub for pushing events between processes.

It can save to disk with snapshots and an append-only file, so it survives a restart, but its dataset is limited by memory, it has no query language, and it is designed around losing nothing important if the cache disappears. Treat it as the place for data you can rebuild or can afford to lose, alongside a relational database that holds the truth. Redis: when you need it makes the case for and against adding one, and Valkey vs Redis explained covers the fork.

What actually decides it#

When the table above does not settle it, these questions do, roughly in order:

1. What does the software expect? If you are installing someone else's application, use the database it documents. Running WordPress on anything but MySQL, or a SQL Server application on PostgreSQL, is a project in itself.
2. What does your team know? A team fluent in T-SQL and SSMS will build and operate SQL Server better than a PostgreSQL it learned last week, and the reverse. Operating a database well - backups, restores, slow queries, upgrades - matters more than its feature list.
3. What does your framework treat as first-class? Django and Rails lean towards PostgreSQL; Laravel works equally well with MySQL and PostgreSQL; EF Core is excellent with SQL Server and PostgreSQL.
4. How big will it get? If you can foresee more than 10 GB of data, Express is the wrong long-term home unless you are prepared to pay for a licence later. The open-source engines have no such ceiling.
5. How relational is the data? Highly relational data favours the SQL engines; independent documents read whole favour MongoDB.

What should not decide it: benchmark charts, the database a large company uses for a problem you do not have, or a wish to avoid designing a schema. Every one of these databases handles a small application's load on modest hardware, and every one rewards a schema designed on purpose.

Switching later is possible but rarely cheap. Moving between the SQL engines means converting types, rewriting queries that used engine-specific features, and re-testing everything; moving between MongoDB and a relational database means redesigning the data model. Choosing well once is worth an afternoon of thought.

Running them on RE:NODE#

RE:NODE sells each of these as its own server: PostgreSQL, MongoDB, MySQL 8.4 LTS, Microsoft SQL Server 2022 Express on Linux, and Valkey. Each is reached on the host and port shown on its plan, with credentials generated per server, and there is no proxy slot on database plans. Some specifics:

• MySQL comes with a root password, an application database and an application user, all generated.
• SQL Server is the Express edition, with an sa password and a database created for you and set as sa's default; SSMS connects with the server name host,port, a comma, and each database is capped at 10 GB by the edition.
• Valkey is password-protected and saves to disk with both AOF and snapshots.

Backup slots vary by line: two to six on PostgreSQL and MongoDB, one to four on SQL Server and MySQL, and zero or one on Valkey, where the data is usually a cache you can rebuild. Prices start from about $2 a month for the smallest Valkey plan and from $4 to $7 for the relational and document databases; the database hosting page has the current figures. Whichever you choose, take your own logical backups as well - database backups and restores explains why the host's copy should never be the only one.

FAQ#

Is PostgreSQL better than MySQL?

For a new application with a free choice, PostgreSQL is usually the better default: stricter, more featureful, and with transactional schema changes. MySQL is the better choice when your software is written for it, which covers most of the PHP world. Both are mature and fast enough for almost any small or medium application.

Is SQL Server Express good enough for production?

Yes, within its limits: 10 GB of data per database, four cores and about 1.4 GB of buffer pool memory. Many business applications live comfortably inside that for years. Plan for growth honestly, because the step beyond Express is a paid licence.

Should I use MongoDB to avoid designing a schema?

No. The schema still exists; it just moves into your application code, where it is harder to enforce and change. Choose MongoDB when your data is genuinely document-shaped. If you only need a few flexible fields, a jsonb column in PostgreSQL gives you that without giving up joins and transactions.

Can Valkey be my only database?

For a cache, a queue or a leaderboard on its own, yes. For an application's core data, no: it is limited by memory, has no query language or joins, and is designed around data you can afford to rebuild. Pair it with a relational database that holds the authoritative copy.

Can I switch databases later?

Yes, but it is a project, not a setting. Data types, queries, migrations and tests all change, and engine-specific features have to be replaced. Using an ORM reduces the work but never removes it. It is cheaper to choose deliberately at the start.

Do I need two databases for a small app?

Usually not at first. One relational database handles a small app's sessions, jobs and caching perfectly well. Add Valkey when a measurable problem appears - slow repeated queries, a busy job queue, sessions shared across several processes - rather than up front.