Excel to SQL: Turning a Spreadsheet into a Real Database Table

A lot of real business data starts life in a spreadsheet, not a database — a customer list someone built in Excel, a pricing sheet maintained by hand, an inventory export from another system. Turning that into an actual SQL table mostly comes down to cleaning up a few things Excel does differently from a database.

Header row = column names, so clean it up first

The first row becomes your column list, and SQL identifiers have rules spreadsheet headers don't: an unquoted identifier can't contain spaces or start with a digit, and dialect-specific reserved words (order, group, user) need quoting or renaming. The Excel to SQL tool quotes such names for the dialect you pick, so "Customer Name" stays valid SQL — but you will have to quote it in every later query, so renaming it to something like customer_name in the sheet first is usually nicer. Check the generated column names either way.

Merged cells and formatting break more than they help

• A merged cell (a category header spanning several rows, say) is visually clear in Excel but only actually has a value in its first cell — the rest read as blank once flattened into rows, which isn't usually what you want for a data table.
• Cells formatted as currency or with thousands separators ($1,250.00) can come through as text rather than a number if the underlying value includes the formatting characters rather than being a plain numeric cell.
• A column of ZIP codes or IDs shown with leading zeros through a number format (a cell holding the number 501 displayed as 00501) is read as the number 501, because the zero padding exists only in the cell's display format. Keep such columns as text from the start (a text cell holding 00501 is kept as it is; changing the format of an existing number cell to Text does not bring the zeros back), or fix the type in the output.

Excel dates are a common source of silently wrong data

Excel stores dates internally as a serial number (in the usual 1900 system, serial 1 is January 1, 1900; older Mac workbooks use a 1904 system, 1,462 days apart) and only shows a formatted date because of cell formatting. The tool applies the workbook's own date system, but if the formatting doesn't carry through cleanly, a date column can come out as a meaningless five-digit number instead of a date. Worth spot-checking a date column in the output before trusting it, especially for a sheet that's been copy-pasted between files a few times (a common way date formatting quietly breaks).

One sheet at a time

A workbook with multiple sheets — a "Customers" tab and a "Products" tab, say — needs to be converted one sheet at a time into one table at a time. Make sure you're converting the sheet you think you are, especially in a workbook where the visible tab isn't always the first one.

Treat the inferred schema as a first draft

Whatever types get inferred from a spreadsheet — text, number, boolean, date or timestamp — are a reasonable starting point, not a schema you should assume is correct without looking. Spreadsheets mix formats within a column more often than CSVs do (a mostly-numeric ID column with one row typed in as text, for example), so it's worth a quick read-through of the generated CREATE TABLE statement before running it against a real database.

Convert your spreadsheet

The Excel to SQL tool reads the file you choose directly in the browser — it is not sent to our servers — and generates a CREATE TABLE statement plus INSERT rows you can review before running.