How does that work?

If you need to preserve data between the application versions then you still get all the headaches with MongoDb (either migrating the data or supporting multiple schema versions when you read the data, oh the fun!).

If you don't need to preserve data between the versions then you don't need to write migrations scripts in SQL, just scrape everything and pretend it's the first version of application.

I guess this is a question of how usefuly, deployable the prototype shoukd be. Why not just have an in memory object cache, literally a hashmap, for your dal? If you're composing app level code, you don't need to know what the backend does to your data. You could even create a simple method to populate the data at app boot in your in the dev profile. When you figure out the storage requirements and finalized model, build your db.

This would save you time on picking the db, schema changes or even migration changes in Mongo. You don't have to worry about bad documents from an earlier app revision.

> You could even create a simple method to populate the data at app boot in your in the dev profile

I have ~40M documents, and it’s still a subset of what I’ll manage in production. It takes a few hours to load them in the database.

In that case you can start with postgres and stuff your documents in a single json column, accessing it just as you would have in mongo while you're prototyping and don't care about speed and indexing, and when you're done, you can just change that table to a more proper structure without changing databases.

I have never managed to build a prototype that didn't end up being used in a production setting.

I am trying to remember if I ever built a prototype that got rewritten. Probably not.

It probably won’t get rewritten but the DB-specific code is in one module so it’s easy(-ish) to swap the underlying DB.

Use SQLite and let the tool drop and recreate all the tables during prototyping. No migrations required.

SQLite can’t handle a large number of documents; I have ~40M of them.

Exactly. Use the right tool for the right job. Start prototyping and development with MongoDB and then migrate to Postgres, or Cassandra or whatever suits your user-case better.

Oops.. did I say something wrong?