There are several ways we go about it depending on the needs of the data to be stored in SQL. All of our data in SQL and Mongo has a uuid as the primary key and

There are several ways we go about it depending on the needs of the data to be stored in SQL. All of our data in SQL and Mongo has a uuid as the primary key and effectively lets us use merge-style replication techniques, and support temporary offline use of our application. If the Mongo data is flat, its very easy to go from Mongo->SQL, only a type mapper is needed. The lumpy data case gets more complicated, as its dependent on the data. The complex data generally ends up translating into master/detail tables or similar ideas. Various pieces of data that is nice to have, but changes with the UI/customer needs, gets stuffed into several key/value tables (one for each type). For the completely dynamic Mongo data we store in SQL, we alter the SQL table programmatically to meet the new schema (in part of our application, customers must be able to drive the schema). This way works in our specific application, but it requires a lot of work to make sure your users cant paint themselves into corners with their schema. So far we haven't experienced any issues with the front-end people changing data structures, as the changes they generally make only impact fields that are not stored in SQL. Completely new features generally require the addition of new columns/tables to SQL, but every application has that issue. During startup of the server it double checks the schema of all of the tables used and updates as needed.