Ask HN: What database should I use, and how should I choose? | Hacker News Reader

Ask HN: What database should I use, and how should I choose?

12 pointsiN7h33nD16 comments

First off I am working on a web application and eventually a mobile application with the following requirements:

* I need something that will support offline storage at some point.

* There will be a lot of reading from the database

* There will be a lot of small writes to the database, but not many big writes

* I don't really want to lose data

* I would like to support real time interactions

* I would like it to be easily scalable and maintainable (possibly hosted/maintained by a third party) as I am working solo

I have experience with Mongodb (although possible loss of data is alarming) and a lot of experience with MySQL/Postgres.

I am looking into Couchdb/Pouchdb as that seems to fit my requirements, but I am concerned about speed.

View on HN

The first decision is SQL or NoSQL. There is one right answer, almost regardless of requirements: SQL. (My personal choice would be Postgres over MySQL.)

If you are lucky enough to get to the point of having scalability problems, and vertical scaling won't cut it, pick something else.

You didn't list what framework, language, or environment. It absolutely is relevant as some databases more naturally "slot into" certain environments (e.g. MySQL and PHP, MS SQL and .Net).

I'd personally forget the database and instead look for a decent ORM. One you can develop against and then connect to different database solutions (e.g. offline and online databases). That way your choice (no matter how good or bad) can be changed later.

Check this out,

https://blog.cloudboost.io/which-database-should-you-use-for...

IMO, it depends on the type of data as well. But given your read and write description basically any of the databases you listed is capable if configured properly. If you have a lot of experience in the SQL side, you may want to stick there to minimize time to develop your MVP.

I use MongoDB for our core database, but we also have data in elasticsearch for text based queries and some reporting. I am right now contemplating introducing Postgres for the accounting side of our SaaS and to possibly serve some of our reporting requirements that we have found are truly highly relational.

So I don't think in today's environment that you need to say one database is the end all. However, I agree that picking one is the right choice for a new project and then adding/changing as you find the requirements that don't fit. We are micro-serviced based too so in some ways it makes it easier because we isolate which services interact with which databases, but I won't say it isn't without its own complications too.

I would agree withdavismwfl "So I don't think in today's environment that you need to say one database is the end all".

If your data is relational, that is what relational DBs are for - if you hdata is text search, that is what elastic search tools are for.

The key is to identify how the data will be used.

Good luck on the project.

> I have experience with Mongodb (although possible loss of data is alarming) and a lot of experience with MySQL/Postgres.

Use PostgreSQL then, because experience is key. Also: more time to work on the hard stuff.

> I would like to support real time interactions

What do you mean by that?

> I would like it to be easily scalable and maintainable (possibly hosted/maintained by a third party) as I am working solo

Nothing is easy to scale (across a network) if you do not want to lose data safety. So either pay someone to maintain such a beast (costly) or maintain it yourself (time-consuming, error-prone unless you are experienced).

I know there are ways to scale across a network using PostgreSQL but I suggest thinking about the scaling problem when it actually occurs. Or has it already?

I'm the founder at CloudBoost.io and we've built a NoSQL database service that does everything which you've listed (except for Offline Sync which we're building now).

The idea is as a developer - You don't really have to care about about "Which database you should actually store your data in?" and this is why we have machine learning service that actually learns how you store and how you query your data and figures out the database where your data should naturally belong.

As a developer, You only care about storing your data and getting your data back, and that's what we enable you to do.

Let me know if this helps, and feel free to reach out to nawaz@cloudboost.io if you need any more information / help.

OT, but there's a spelling error on your page here: https://cloudboost.io/quickstart

s/CloudBost/CloudBoost/

Without knowing the order of magnitude of the size of your data, its "shape" (is it a fixed layout, is it different per write?), as well as the perf requirements you mention (how many simultaneous reads and how much is being read each time, and what does "real time" mean to you) it's really hard to make a recommendation.

On "how should I choose?", have you considered a decision matrix?

If .NET, Entity Framework with any supported provider.

Any supported provider, as long as its MS SQL Server. The rest wasn't up to snuff last time I checked.

MySQL of course!

(I work on the MySQL team, happy to answer any questions)

"Please to provide solution"

Postgres for your website, SQLite for the mobile.

Right. And for a lot of reads consider running your server off of SSD based drives.

Reply on news.ycombinator.com