
Ask HN: What database should I use, and how should I choose? - iN7h33nD
First off I am working on a web application and eventually a mobile application with the following requirements:<p>* I need something that will support offline storage at some point.<p>* There will be a lot of reading from the database<p>* There will be a lot of small writes to the database, but not many big writes<p>* I don&#x27;t really want to lose data<p>* I would like to support real time interactions<p>* I would like it to be easily scalable and maintainable (possibly hosted&#x2F;maintained by a third party) as I am working solo<p>I have experience with Mongodb (although possible loss of data is alarming) and a lot of experience with MySQL&#x2F;Postgres.<p>I am looking into Couchdb&#x2F;Pouchdb as that seems to fit my requirements, but I am concerned about speed.
======
geophile
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.

------
Someone1234
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.

------
srkiranraj
Check this out,

[https://blog.cloudboost.io/which-database-should-you-use-
for...](https://blog.cloudboost.io/which-database-should-you-use-for-your-
app-2/)

------
davismwfl
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.

~~~
c4n4rd
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.

------
kluck
> 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?

------
nawazdhandala
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.

~~~
breakingcups
OT, but there's a spelling error on your page here:
[https://cloudboost.io/quickstart](https://cloudboost.io/quickstart)

s/CloudBost/CloudBoost/

------
tedyoung
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.

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

------
miguelrochefort
If .NET, Entity Framework with any supported provider.

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

------
morgo
MySQL of course!

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

~~~
LGBT_2000
"Please to provide solution"

------
segmondy
Postgres for your website, SQLite for the mobile.

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

