
Ask HN: How do you use a database when prototyping a web application? - networked
I wonder how other HN users approach data storage when iterating on a web application product early in its development. Please share your approach here.<p>To elaborate on the question in the title:<p>* Do you use a &quot;traditional&quot; SQL database like Postgres or MySQL and deal with schema migrations from the start? Do you keep your data denormalized (e.g., as JSON in Postgres) until a certain point in the development process?<p>* Do you use a NoSQL database like Mongo? If so, do you then keep it or do you migrate to SQL?<p>* Do you go with a BaaS?<p>* Do you avoid a database altogether and store your data as flat files?
======
hardwaresofton
tldr; I use a nosql db because you don't need to worry about schema which
should give you an initial iteration speed boost, but the database type should
be decided based on the data. In the SQL case, you should decide on a
migration technology sooner rather than later. Either way, keep good schema
documentation (if it's not already in code).

DISCLAIMER: I'm highly partial to rethinkdb
([http://rethinkdb.com/](http://rethinkdb.com/)), though I think I have good
reasons

\- Since I find document stores a little easier to setup/work with (especially
when they have nice convenient web UIs built in) I've often started with
those. The obvious benefit is letting your schema change while you prototype
the application. You could easily do this also with JSON in Postgres
obviously, but I find the web interface/ease of use that databases like
rethinkdb ([http://rethinkdb.com/](http://rethinkdb.com/)) offer to be
refreshing.

\- When you decide what database you should use in production, it should be
based on the data. Note that most document stores are not actually "schema-
less", it's just up to you to properly interact with the tens of schemas that
are true at any one point in time. A sane set up will often have the schema
documented somewhere.

I find myself writing documentation in files like SCHEMA.md (sometimes in it's
own folder with a file for each actual model/collection), if I use a NoSQL
database.

If you find that a relational model fits your data best (if your data is
highly relational, and very inter-connected -- a lot can be said about when
you should use a relational db vs a non-relational one), then I would still
suggest documenting your schema, and picking a migration strategy BEFORE you
start. Find what technology you're going to use to migrate your database, and
start using it from day 1.

\- If you you are rapidly prototyping, it might slow you down to add a BaaS.
At least I've found that it's really easy for me to download the binary for a
database I want to use, run the binary, connect to it in code.

\- Many frameworks start you out with using an on-disk SQLite database
(django, rails). If you mean like an actual flat text file, it really depends
on the guarantees you want out of your database. If you are writing a highly
functionally-minded app, and know that you are going to essentially keep a
append-only log of what's happening, a flat file might be all you need (and of
course, you'll need some locking if you want to do more than one thing at a
time to the file)

