SQL for Finance: Why SQL When You Have Excel: SQLite, AtlasParts, First Query

Download the AtlasParts dataset and atlasparts.db — the same eight CSVs we used across the Excel & Power BI for Finance series, now also packaged as a SQLite database file: github.com/GoCelesteAI/excel-powerbi-for-finance. One download, eight episodes ahead.

If you finished the Excel & Power BI for Finance series, you can already do most of what a finance team needs in a spreadsheet. Pivot tables, lookups, Power Query, a Power BI dashboard with cross-filter wired across every visual. That’s a real skill set. Most people in finance never get that far.

But here’s what happens next.

The CFO asks a question. “How did Q3 margin look in the regions where the customers we acquired last year are concentrated?” You open Excel. The customers are in customers.csv. The regions are in countries.csv. The orders are in sales_orders.csv. The line items — where the actual revenue is — are in sales_order_lines.csv. The product categories are in products.csv. And the cost-of-goods is in the gl_journal.csv extract you got from the ERP this morning. Six files. Two thousand rows in one. Twenty-two thousand in another.

In Excel, this is two hours of work. In Power BI, this is fifteen minutes of work but only after you’ve built the model. In SQL, this is one query.

Welcome to SQL for Finance. Eight episodes. One language. The same AtlasParts dataset. By the end, you can take any question your CFO can ask and turn it into a query that runs in under a second on data Excel can’t even open.

What SQL actually is

If you’ve used Excel, you already think in tables. Rows are records. Columns are fields. The left part of an Excel formula is what you want; the right part is where to find it.

SQL is the same idea, but the tables live in a database file instead of a spreadsheet, and the formula syntax is different — closer to English. Show me the customer name and the country, from the customers table, where the country is the United States, ordered by the customer name. In SQL, that sentence is almost word-for-word what you’d type:

SELECT customer_name, country
FROM   customers
WHERE  country = 'US'
ORDER BY customer_name;

That’s not pseudocode. That’s a real, runnable query. SQL has been the language for talking to databases since 1974. Every analytics tool you’ll ever use sits on top of it. Power BI’s DAX exists because Excel people needed something that wasn’t SQL. The rest of the data team — engineers, analysts, the warehouse — they all speak SQL.

Excel is a tool. SQL is a language. The difference matters because once you can speak it, every database in the company is suddenly readable to you.

Why SQLite specifically

There are dozens of SQL databases. PostgreSQL. MySQL. SQL Server. Snowflake. BigQuery. Each has slightly different syntax, slightly different functions, slightly different installation horror stories.

We’re going to use SQLite, and it’s the right choice for finance learning specifically.

SQLite is a single file. The whole database — all your tables, all your data, all your indexes — sits in one file with a .db extension. You can email it. You can put it on a USB stick. You can commit it to git. There is no server to install. There is no port to open. There is no admin to ask. You install sqlite3 once, you have a database engine forever.

That matters because the friction in most SQL tutorials isn’t the SQL — it’s the setup. Postgres installation gone wrong has ended more aspiring data analysts than any concept in the language. SQLite eliminates the entire category. You’ll have a working database in two minutes after this video, and you’ll never lose access to it.

The SQL we’ll write in SQLite translates directly to every other database. The 95% that’s identical across SQLite, Postgres, MySQL, and Snowflake is the 95% that finance work actually uses.

Loading AtlasParts into a database

Open a terminal. Navigate to the AtlasParts folder you downloaded. The CSVs are in data/. Run this:

sqlite3 atlasparts.db

That command does two things at once. It creates an empty database file called atlasparts.db in your current directory. And it drops you into the SQLite command-line shell, ready to type queries. The prompt changes from $ to sqlite>. You’re inside the database now.

To load the CSVs, we tell SQLite to switch to CSV mode and import each file:

sqlite> .mode csv
sqlite> .import --skip 1 data/customers.csv customers
sqlite> .import --skip 1 data/gl_journal.csv gl_journal

.mode csv and .import are dot commands — instructions to the SQLite shell itself, not SQL queries. The SQLite CLI uses these for housekeeping; everything starting with a dot is a shell command, everything else is SQL. The --skip 1 tells the importer that the first line of each CSV is a header row, not data.

A loader script that imports all nine AtlasParts files is on the GitHub repo. Run it once. Now you have one file — atlasparts.db — that contains every row of finance data we’ll touch for the rest of the series.

Your first query

You’re inside the SQLite shell. The database is loaded. Type this:

SELECT * FROM customers LIMIT 5;

Hit Enter. You’ll see five rows of customer data come back. That’s a SQL query. Select all columns from the customers table, limit to five rows. Read it like a sentence. That’s the whole skill.

The default output is pipe-separated and noisy. Two more dot commands fix it:

sqlite> .headers on
sqlite> .mode column

Now run the query again. The output is a properly formatted table with a header row and aligned columns. This is the default look we’ll use for the rest of the series.

The moment SQL pays for itself

Here’s the line that makes a finance person fall in love with SQL.

SELECT COUNT(*) FROM gl_journal;

Hit Enter. The answer comes back in a few milliseconds. 22,027.

Twenty-two thousand journal entries. Counted. In the time it took the cursor to blink. Try opening the same CSV in Excel — Excel will open it, but every formula recalculation takes seconds and pivot tables stutter.

Now try a real question:

SELECT account_type, SUM(CAST(debit AS REAL)) AS total_debits
FROM   gl_journal
JOIN   chart_of_accounts USING (account_id)
GROUP  BY account_type
ORDER  BY total_debits DESC;

That’s six lines. It joins the GL extract to the chart of accounts, groups by the account class, sums the debit amounts. It runs on twenty-two thousand journal lines. And in SQLite it returns in under twenty milliseconds.

In Excel, that’s a SUMIFS-and-VLOOKUP exercise that takes an afternoon to build and breaks every time someone touches the chart of accounts. In Power BI, it’s a star schema, three measures, and a visual. In SQL, it’s a query you typed in the time it takes to drink half a coffee.

This is the deal. SQL takes longer to learn than Excel — about as long as Power BI did. In exchange, you stop being limited by file size, you stop being limited by the joins your tool can do, and you start being able to ask any question of the data without thinking about which tool to open first.

What’s coming in the rest of the series

Eight episodes. We move from “your first query” to “a folder of .sql files that produce a P&L, a balance sheet snapshot, an AR aging, an AP aging.”

Same dataset throughout. The skill compounds episode by episode. By Ep8 you’ll have a reports/ directory of queries you can re-run on any month-end and get a finance pack out the other side.

Recap

What we did today. Installed sqlite3. Loaded eight CSVs into one .db file. Ran the first SELECT. Counted twenty-two thousand journal entries in under fifty milliseconds. Pre-viewed a six-line query that produces a real P&L breakdown.

You haven’t learned SQL yet. You’ve learned that SQL exists, that SQLite makes it accessible, and that the AtlasParts data — the same data we used for twelve episodes of Excel and Power BI — is now in a form where any question takes one query.

Next episode: SELECT, WHERE, ORDER BY, LIMIT. The four clauses that handle 60% of every query you’ll ever write.

See you in the next one.