> I thought my customers needed one thing (a fancy database), when they actually needed something entirely different (importing and exporting from Excel sheets)

> I thought my customers needed one thing (a fancy database), when they actually needed something entirely different (importing and exporting from Excel sheets). I made a rough prototype of the software as a first pass, with no backend data system, showed it to teachers, and got some feedback. This saved me hours and hours of work on a product feature that nobody but me actually wanted. It may be worth noting that SQL and Excel are not necessarily mutually exclusive choices as the backend database: 1. The customer's requirement of being able to import/export from/to a spreadsheet document is a problem of interopability, rather than the choice of storage medium. Thus, you could as well just make use of your go-to database solution and implement synchronization separately—either by using RDBMS as the primary source or using it only for indexing/durability purposes—and the customer would still be happy. 2. Some spreadsheet softwares like Excel and Google Sheets allows you to query spreadsheet data in SQL (e.g. Microsoft ODBC) or some SQL-like language (e.g. Query Function). That said I haven't actually used them in practice, so I cannot guarantee how well it goes with actual pre-formatted or semi-structured data found in many spreadsheets. Interopability allows a system to be complemented by the environment composed of other existing systems. The system might not need to interop, but only if it could satisfy every need originally served by pre-existing systems for the user. In general it's best not to assume which database backend should be used as the source of truth (cache or indexing is okay) if you are not the one in control of the data.