Well, most of this thoughts about not needing a database assume a basic thing: You never shut down your application.

If this is a fact and you can guarantee that it will never shutdown, then leave DBs completely.

But since you can’t guarantee zero downtime, you have to persist your data somehow.

To persist your data and getting it back into your live system, you have a couple of options:

• Put them into a databse of any kind (SQL or not doesn’t matter) and reload it when necessary
• Log changes of the system into a file. On restart load that file and “replay”
• Combine both ways.
• probably others

One of the most important things to remember to understand that mantra is, that it means “you don’t need the database as primary source of truth, but it may be a valid backup strategy”.

DB, no DB. Uncle Bob has much to say about that:

And:

I wonder, perhaps, if you are misinterpreting something that I perceive as a main theme of Phoenix 1.3.

I gather that in Ruby on Rails, there is a tendency for the persistence mechanism (ActiveRecord) to pervade an application in a way that the logic of the domain model that the application operates on becomes entangled with the persistence code. As a result, I have been lead to believe that it is common when writing an Rails App to begin solving any problem by figuring out how you are going to squeeze that problem into the database. (as with most things, probably true in some cases and untrue in many)

I gather from the 1.3 presentation, that for various reasons (one of which was the generated code that Phoenix produced) some Phoenix 1.2 apps started to show this unhealthy trait of the persistence driving the domain model of a problem. As I understand it, one of the main aims of Phoenix 1.3 is to help developers keep a healthy separation between their domain modeling code and the code used to persist elements of that model.

In that case the warning is “Don’t start solving your problem by designing your database”. Start by creating code that models your domain and solves the problem. Then, if you need to persist data, find a way to do that. A database might be one good choice among many.