**Decision being made:** Which database to use for a new product with low write rate and modest user count, built by a solo developer. **Options under consideration:** - **Postgres**: the default-good choice for relational data. - **SQLite**: the embedded-database choice; runs in-process, no separate server. - **DynamoDB**: the AWS-managed NoSQL choice; scales transparently but locks you in. **Criteria that matter (and why):** - **Operational overhead**: with a solo developer, every operational task is a tax on building the product. - **Cost at the target scale (10K users)**: budget is small; the database shouldn't dominate. - **Local development experience**: solo developers iterate fast locally; databases that run there cleanly save real time. - **Long-term flexibility**: switching databases later is expensive. The decision needs to support reasonable future growth without forcing a rewrite at 100K users. - **Schema and query expressiveness**: the workload is described as relational-shaped; query needs matter. **The matrix:** | Criterion | Postgres | SQLite | DynamoDB | |---|---|---|---| | Operational overhead | Moderate. Needs a managed service ($10-25/mo on Supabase, Neon, or Fly) or self-hosting. | Lowest. No server. File in your app's filesystem. | Lowest if you accept the SDK; AWS handles infra. | | Cost at 10K users | $10-25/mo on a managed service tier. | $0; runs in-process. | Free tier covers low traffic; cost climbs with read volume. Predictable but not negligible. | | Local dev experience | Good with Docker; slight friction. | Excellent. Nothing to start. | Awkward. Either use DynamoDB Local (Java) or write code that's hard to test locally. | | Long-term flexibility | High. Postgres scales well; many products use it past 100M users. | Limited. SQLite handles modest concurrency; not built for high write throughput. | Schema rigidity (single-table design) shapes the codebase early; hard to evolve. | | Schema and query expressiveness | High. SQL, joins, full-text search, JSON, etc. | High for read; SQL is full-featured. Concurrency limits matter for writes. | Limited. Designed around key-value patterns; complex queries are awkward. | **Key tradeoffs:** - **Postgres vs. SQLite**: Postgres gives you headroom and a managed service if you scale, at the cost of operational complexity now. SQLite is simpler now and you might never need more, but if you do, you're migrating. - **Postgres vs. DynamoDB**: Postgres gives you a familiar relational model and portability. DynamoDB gives you no-ops scale but locks your data model and your cloud. - **SQLite vs. DynamoDB**: Almost no overlap. SQLite is for "simplest possible thing now," DynamoDB is for "outsource the scale problem entirely." They don't usually compete in the same decision. **The dominant option, if any:** There is no dominant option. Postgres wins on flexibility and expressiveness; SQLite wins on simplicity and cost; DynamoDB wins on hands-off scale. **The values question:** - If "simplest path to launch, accept future migration" is the priority → SQLite. - If "good default that scales reasonably, willing to pay $20/mo" is the priority → Postgres on Supabase or Neon. - If "want zero ops, willing to bend the data model" is the priority → DynamoDB. **Reversal cost:** Asymmetric. Migrating off SQLite is moderate work (SQL syntax mostly transfers; concurrency assumptions don't). Migrating off DynamoDB is high work (data model usually has to be rebuilt). Postgres has the lowest reversal cost because most other databases support similar SQL. **My recommendation, calibrated:** For a solo developer at this scale, Postgres on a managed service (Supabase or Neon) is the default. You get familiar SQL, low ops, and the ability to scale past 100K users without rewriting. If $20/mo is a real constraint, SQLite is the answer — accept that you'll migrate later if the product takes off. DynamoDB is the wrong fit unless you have a specific reason (very spiky traffic, AWS-native infrastructure already in place).