How to design a storage backend for a cloud spreadsheet?

Question

As a personal project to learn key technologies, I am trying to build a spreadsheet on the cloud (something like Google Sheets).

How would you design the storage backend to power something like this? Does it make more sense to use a relational DB, something like a No-SQL-DB or a different kind of storage technology? And how would you map the different spreadsheet elements and operations to database elements / operations in an efficient manner?

Spreadsheets are very flexible in nature. One can add pretty much any kind of table to a spreadsheet. Imagine having a spreadsheet with thousands of rows and hundreds of columns, what kind of a database would be best suited to operations like:

• adding multiple rows at once (kind of like inserts in a RDBMS)
• add arbitrary columns (kind of like an add column operation on a column oriented database)
• edit any cell value in the table
• quickly perform operations on cell ranges (like sums, averages etc.) - perhaps this can be done on the client side (in the browser?)

If you ignore the front end challenges and think about the fact that the data needs to be stored somewhere, where would be a good place to store it? It goes without saying that when a user interacts with the spreadsheet from the browser, the interactions themselves need to be snappy.

Answer 1

Instead of trying to figure out what technology to use, focus on the data itself.

Maybe you can try to model how you would efficiently communicate the user changes to the backend, and propagate them to other users.

Try to depend on as little technology as possible, and solve the interesting problems first.

For example: I think a list of populated cells would suffice, to start with. Store just their row number, column number and the cell contents. All your operations can than be implemented as updates to one or more cells.