The cheapest database on day one can be the most expensive in year three - a practical research synthesis: near-identical RDS pricing, the MySQL vs PostgreSQL 2026 benchmark, three real migration case studies and a 4-stage lifecycle framework.
One of the most frequent questions Thai dev teams ask is "which database should we start the project with?" The better answer is the database that fits today, with a cheap exit when tomorrow changes - because research and case studies agree the real cost of a wrong choice is not the monthly hosting bill but the migration friction that compounds as the system grows.
This article synthesizes real Amazon RDS pricing, Supabase and Neon, the 2026 MySQL 8.4 vs PostgreSQL 17 benchmark and three real migration case studies into a 4-stage lifecycle decision framework: MVP, Production, Enterprise and SaaS.
The 4-stage frame: needs change, costs change
Treating database choice as "pick once, done" is the root of the problem. At each product stage, the dominant factors differ:
| Stage | What matters most | Usually correct choice |
|---|---|---|
| MVP | Iteration speed, near-zero cost | SQLite, free-tier PostgreSQL/MySQL |
| Production | Uptime, backups, durable data, observability | Managed MySQL/PostgreSQL (RDS, Supabase) |
| Enterprise | HA, compliance, long-lived data, complex reporting | PostgreSQL + Multi-AZ + Reserved |
| SaaS | Multi-tenancy, elastic scaling, cost per tenant | PostgreSQL + shared-table/sharding |
The point is not that you must migrate at every stage - it is never pick a database that makes a future move more expensive than it needs to be.
Know the four options you will actually use
SQLite: the serverless MVP champion
SQLite is an embedded engine storing everything in one file - no separate process, no network latency, near-zero cost. That is why Ruby on Rails shipped it as the default forever. The limits are equally clear: file-level locking means concurrent multi-user writes break easily, and platforms like Heroku do not support it at all. Many Rails teams start on SQLite and move to PostgreSQL at deploy - a pattern where tools like pgloader compress the move into hours.
MySQL: the solid OLTP workhorse
MySQL remains the default of the LAMP world and early SaaS. Its strength is very fast simple queries - the 2026 benchmark finds MySQL 8.4 delivers roughly 20-30% higher throughput than PostgreSQL 17 on simple SELECTs and about 30% on write-heavy workloads. For ordinary CRUD systems that translates directly into one smaller instance.
MariaDB: the MySQL drop-in
MariaDB was forked from MySQL by the original team, is nearly fully interchangeable, and on Amazon RDS costs exactly the same as MySQL. Organizations move for licensing, features like parallel replication, or governance direction - not price.
PostgreSQL: the enterprise and SaaS workhorse
PostgreSQL wins decisively on two fronts: complex analytical queries up to 2x faster than MySQL (TPC-H) and JSON document queries 5-10x faster thanks to JSONB + GIN indexes. Additionally, PostgreSQL 17 cuts VACUUM memory usage by 20x, fixing its most-complained-about weakness and enabling smaller instances or more predictable maintenance.
The pricing truth: MySQL and PostgreSQL cost nearly the same
Amazon RDS pricing (us-east-1, 2026) reveals a fact many teams still miss:
| Instance | MySQL/hr | PostgreSQL/hr | Monthly (730h) |
|---|---|---|---|
| db.t4g.micro | $0.016 | $0.016 | ~$11.68 |
| db.r8g.large | $0.240 | $0.241 | ~$175 |
| db.r8g.xlarge | $0.478 | $0.480 | ~$350 |
Bottom line: base prices are nearly identical. Decisions should follow workload, not price. What actually differs is cost reduction: 1-year Reserved Instances save ~29%, 3-year all-upfront over 50%, while extended support for old versions (MySQL 5.7, PostgreSQL 11) runs ~$0.200/vCPU-hr - delaying upgrades can eat the entire discount.
Beyond RDS, two models change the game for small teams: Supabase Pro at $25/month including 8GB disk + 250GB egress + 100K MAU and Neon serverless Postgres billed on usage ($0.106/CU-hr + $0.35/GB) with no minimum - ideal for spiky traffic or MVPs without users yet.
Three case studies teaching "when to move, and what it costs"
1. E-commerce migrating MySQL 8.0 to PostgreSQL 15
A platform with ever-heavier JSON queries and multi-table joins outgrew MySQL. The team moved 120GB in about 3.5 hours with a process worth copying: schema checks on both sides via information_schema, row-count reconciliation per table, and checksums on every table (MD5 over columns ordered by id) before cutover. The result: noticeably faster JSON-heavy queries on the same instance class - free performance, since RDS pricing is identical.
2. A 2,800-customer SaaS moving MySQL 5.7 to MariaDB 10.11 with zero downtime
The team used three phases: compatibility analysis with pt-upgrade (catching queries using features MariaDB dropped, like the query cache), parallel replication from the binlog keeping data in sync, then gradually shifting traffic via DNS-weighted routing. The migration completed without a single customer noticing - the lesson: moving within the same lineage (MySQL to MariaDB) is very cheap with a well-designed process.
3. A Rails team moving SQLite to PostgreSQL for Heroku
The classic pattern: add the pg gem, adjust database.yml, run db:drop db:create db:migrate - and if real data exists, point pgloader at the database name. Done. This is why SQLite is not a trap - with an exit planned, an easy start is not automatically expensive.
The big SaaS exam: which multi-tenancy model
Once a product becomes a SaaS with thousands of customers, the multi-tenancy design determines long-term cost more than the engine. Microsoft’s Citus guide summarizes three models:
- Database per tenant - strongest isolation, easy per-tenant backup/GDPR deletion, but at thousands of tenants you herd tiny databases that together cost more and are harder to operate
- Schema per tenant - shared instance, logically separated: the middle path, suited to tens-to-hundreds of tenants
- Shared table + tenant_id - everyone in one table separated by a tenant_id column plus sharding: the most resource-efficient per tenant, with cross-tenant analytics for free, in exchange for query discipline (always filter by tenant)
For SaaS planning beyond 100 tenants, shared table + sharding on PostgreSQL (via the Citus extension or by design) is where the research consistently points.
Summary: a stage-based decision checklist
- Genuinely prototyping today - use SQLite, with discipline: avoid SQLite-only features and always keep schema in migrations
- Deploying for real users - no shortcut past free-tier PostgreSQL (RDS/Supabase/Neon): $0 cost while eliminating concurrency problems early
- Simple queries, heavy writes - MySQL genuinely excels here; use it comfortably, but keep an exit via an ORM and standard SQL
- Analytics, JSON, many tenants - PostgreSQL is the no-debate answer: JSONB, the extension ecosystem and the most mature multi-tenancy patterns
- Already on MySQL, want more features - MariaDB migrates easily at identical cost; but if the need is analytics/JSON, go straight to PostgreSQL
- In every case - plan version upgrades so you never fall into extended support, whose penalty can erase the entire reserved discount
The last line: the true cost of a database is not the instance bill but team time and migration risk. Choose one that is cheap enough for today + easy enough to leave for tomorrow, and you will regret nothing either way.
Sources
- real Amazon RDS pricing aws.amazon.com
- Supabase supabase.com
- Neon selfhost.dev
- 2026 MySQL 8.4 vs PostgreSQL 17 benchmark tech-insider.org
- pgloader compress the move into hours dev.to
- 1-year Reserved Instances save ~29%, 3-year all-upfront over 50% securityboulevard.com
- A platform with ever-heavier JSON queries and multi-table joins outgrew MySQL dzone.com
- The team used three phases: compatibility analysis with pt-upgrade www.freedomdev.com
- Microsoft’s Citus guide learn.microsoft.com
