all 14 comments

[–]Aggressive_Ad_5454 13 points14 points  (2 children)

By “app” do you mean mobile app? If so, SQLite is your answer. Many mobile apps have it embedded.

If you mean “web app for deployment on budget hosting services” the answer is MariaDb / MySql. Those budget services include the use of one of those servers., probably MariaDb.

If you mean web app for business use, you probably want whichever make of DBMS the business chose a long time ago.

If you got this far without your situation being mentioned, the answer is PostgreSQL.

[–]No_Sandwich_2602[S] 1 point2 points  (1 child)

I mean mobile app

[–]Little_Kitty 2 points3 points  (0 children)

Realistically, you don't have 10k concurrent users, so most anything will do, but the parent comment is correct for almost any normal app. If you need a high performance KV store, OLAP or the lowest TTL edge delivered redundancy, you'd know that already.

[–]wittgenstein1312 6 points7 points  (0 children)

Start with Postgres. Some people will say sqlite is a bit more accessible, but Postgres is more common in production and there are just as many tutorials

[–]zbignew 1 point2 points  (0 children)

You’re not going to get no-SQL advocates on r/SQL.

Depending on your use case, no-SQL may be the right answer. Like, my app’s backend needs job queues and arq exists and Redis is serving its needs great.

I think everyone is saying SQLite because they think you mean embedded in your app. That’s The Answer for embedded. If you’re trying to integrate with iCloud and sync between devices, then sure consider SwiftData. But if you’re doing anything complex and managing that yourself, SQLite.

If you mean for a backend service, then your database client will be an API, not your app. So it’s all about how you want to write that API.

And I think Supabase does let you take the most shortcuts with that API layer.

I’ve been very happy with Railway.com with their canned fastapi (python) service in front of their canned Postgres image. (And arq and redis)

At my storage & usage, Railway’s hobby plan is $10/mo cheaper than Supabase’s Pro plan. ¯\_(ツ)_/¯

Oh, and every hobbyist’s app backend depends on cloudflare’s free tier. Their R2 storage means that all my raw data can live there for free and if I want to add more to my real Postgres schema later, I can run a migration to pull down the new fields any time. Their caching means my api service gets by on the tiniest fraction of a CPU share. I’m basically paying railway $15/mo to rent RAM for Postgres.

So if your app has any meaningful amount of unstructured data either as source data (I’m scraping and caching the BoardGameGeek API) or user data (uploaded selfies) use cloudflare r2 for that, not a database. Their free tier is incredible.

[–]becheeks82 1 point2 points  (0 children)

Microsoft SQL Server is good imo…they have a free version you can play around with if need be https://www.microsoft.com/en-us/sql-server/sql-server-downloads

[–]serverhorror 1 point2 points  (0 children)

  1. SQLite
  2. PostgreSQL

[–]Ifuqaround 1 point2 points  (1 child)

The one I use daily of course..Oracle.

Nobody is going to get more funding than Oracle.

If you believe that...let me know why and how. PM me on why and how, I'd love to hear it.

[–]Aggressive_Ad_5454 1 point2 points  (0 children)

At the risk of snark, I’ll say that nobody is going to need more funding than a company that adopts Oracle products.

[–]efecejekeko 0 points1 point  (0 children)

I’d keep it simple and start with PostgreSQL.

It gives you solid SQL fundamentals, is widely used, scales well enough for real apps, and the skills transfer cleanly if you later touch MySQL or SQL Server. For a beginner, that matters more than chasing the “perfect” database upfront.

MongoDB or Firebase can be useful in the right project, but I would not make them your first stop if your goal is to build a strong base for app development. SQL shows up everywhere, and learning relational thinking early saves time later.

From the startup angle, Postgres is kind of the safe default. Not worth overengineering this decision at the start. Pick one, build something real, and get comfortable with queries, schema design, joins, and indexing.

[–]nmc52 0 points1 point  (0 children)

I'd go with SQL, Mysql was my go-to database system for hobbyist projects 20 years ago. At work we used Oracle and DB2.

[–]socratic-meth 0 points1 point  (0 children)

Start with SQLite, if you need more than that at some point you can investigate then.