
Ask HN: Database guide for app developers? - md365
A seasonal writer here. I’m trying to find out what developers look for while selecting a database for a native app? By database, I meant local as well as server-side.<p>What are the challenges, or features that you look for. For instance:
Offline sync feature
Read&#x2F;write speed
Data types
Security<p>And so on.<p>I couldn’t find any relevant guide for developers, so I’m researching to write one.
======
oblib
I decided years ago (2001) to not use a SQL database for a web based document
creation/management app I was making.

My reasons had to do with document integrity and database complexity. The
short of it is I found SQL to be an awful approach to store and manage
documents. Instead I used a simple flat file database for each user.

Another important reason I didn't use SQL after reviewing it is that I felt
that designing, implementing, and securing a SQL database that could handle
the aspects of document creation and management and user management required a
dedicated professional who's made that a career choice and I couldn't learn
all that was necessary and create the app too. It would take years to become
that proficient with SQL alone.

Two years ago I finally moved over to a NoSQL database, specifically
CouchDB/PouchDB, because those offer Offline data storage, sync features,
Read/write speed, and Security.

CouchDB is designed specifically for Documents and addresses all the issues I
found with using SQL databases for document management, and it's built
specifically for use with web apps. From the CouchDB docs:

"it embraces the natural idea of evolving, self-contained documents as the
very core of its data model"
([http://docs.couchdb.org/en/2.1.1/intro/why.html#a-better-
fit...](http://docs.couchdb.org/en/2.1.1/intro/why.html#a-better-fit-for-
common-applications))

For your paper, I would start by looking into available database options to
see what they say their products are best at doing.

My experience is that SQL users tend to avoid NoSQL because it requires a very
different way of doing things that they feel they can do just fine with SQL.
They're probably right, but for those just starting to learn about databases
NoSQL may be the best choice.

Since I never got in the SQL boat my first look at CouchDB left me feeling
like they designed and built exactly what I needed and moving over to it was
incredibly easy for me.

------
jmnicolas
I'm not sure I understand your question, I'll try to answer it anyway ;-)

I'm a desktop developer. Either the DB comes from one of our supplier (we have
Oracle, Sql Server and MySQL) or I'm building an application from scratch and
I'll choose Postgres.

I standardized on Postgres more than 10 years ago because it was free and at
the time it felt better built than MySQL.

I never encountered a use case where NoSQL would have been a rational choice
(take this with a grain of salt since I don't have to scale).

