practical-sql-2: the SQL, data and exercises behind a beginner Postgres book

What the repository actually contains, and what it is not

practical-sql-2 is the code and data for the second edition of Practical SQL by Anthony DeBarros, published by No Starch Press, subtitled A Beginner's Guide to Storytelling with Data.

It is worth being explicit that this is a book repository rather than a software project. The primary language is recorded as PLpgSQL, which tells you the code is PostgreSQL stored procedure language, and the top level is a set of chapter directories, Chapter_01/ through Chapter_19/, plus a Try_It_Yourself/ directory, a LICENSE.md, the README, and four markdown files that hold the maintenance information.

The contents are described in four categories. Code is all the SQL statements and command-line listings used in each chapter, organized by chapter folders. Data is CSV and JSON files plus GIS shapefiles to import, also organized by chapter. Exercises are the Try It Yourself questions and answers for each chapter, listed separately, with the advice to work through the questions before peeking at the answers. Software installation updates are collected in software-installation-updates.md, and FAQ, updates and corrections in faq-updates-errata.md.

That separation of questions from answers is a small design decision that matters more than it sounds. A learner who can see the answer next to the question stops reasoning about the query, so putting them in a separate file makes the exercise real without giving up the answer key.

The book itself is available in PDF, .mobi, .epub and classic print formats, and the code is a companion to it rather than a replacement for it. Reading the chapter is what tells you why a query is shaped the way it is.

The chapter sequence, and why the ordering matters for a beginner

The chapter list is the clearest description of the curriculum available, and it moves in a deliberate order.

It starts with setting up a coding environment, then creating a first database and table, then beginning data exploration with SELECT, then understanding data types, then importing and exporting data. The middle run covers basic math and stats with SQL, joining tables in a relational database, table design that works for you, extracting information by grouping and summarizing, inspecting and modifying data, statistical functions in SQL, and working with dates and times.

The later chapters are the ones that separate this from an introductory query tutorial: advanced query techniques, mining text to find meaningful data, analyzing spatial data with PostGIS, working with JSON data, saving time with views, functions and triggers, using PostgreSQL from the command line, maintaining your database, and finally telling your data's story. That last chapter has no code exercises, which is the right call for a chapter about how to present a finding rather than how to compute it.

Note the pairing of chapter 15 on PostGIS with chapter 14 on text mining and chapter 16 on JSON. Those three are the parts of the book most likely to still be relevant to you after the basics fade, because they are the areas where a database stops being a table of rows and starts being a data platform. Chapter 17 on views, functions and triggers is the one that teaches you to put logic in the database rather than in the application.

There is also an appendix on additional PostgreSQL resources, and a resources.md file in the repository that holds updates to it.

Why PostgreSQL, and the one dialect the book will not get you ready for

The database choice is stated plainly and defended. The book uses PostgreSQL, which is free and open source, and notes that PostgreSQL is used by some of the world's largest companies. Its SQL syntax adheres closely to the ANSI SQL standard, and the concepts you learn will apply to most database management systems, including MySQL, Oracle, SQLite and others.

That is a real argument rather than a default. Teaching on PostgreSQL means the exercises run against a database you can install for free, that the window functions and JSON operators in later chapters are the well-documented PostgreSQL implementations rather than a vendor dialect, and that the standard adherence claim means the core concepts transfer.

The caveat is named just as clearly. Microsoft SQL Server employs a variant of SQL called T-SQL, which is not covered by Practical SQL. If your job runs on SQL Server, the syntax in the later chapters will not drop in, and the specific operators covered in the PostGIS, JSON and advanced query chapters will need translating.

The other side of the choice is tooling. The book writes SQL queries and manages its PostgreSQL databases with pgAdmin, which is a free and open source graphical user interface. The README flags that pgAdmin is under continuous development and its current interface may differ from the screenshots and instructions in the book, and points to the book FAQ for updates.

That warning is the honest part of the repository's design. The code in the chapter folders does not rot, because SQL does not change, but the clicks in the screenshots do.

The CSV warning, which is the most practically useful paragraph in the README

There is a warning about CSV files that is worth reading twice, because it describes silent data corruption rather than a visible error.

Opening CSV files with Excel could lead to data loss. Excel will remove leading zeros from numbers that are intended to be stored as text, such as ZIP codes. To view the contents of a CSV file, only do so with a plain-text editor and be careful not to save the file in an encoding other than UTF-8.

The reason this matters here is that the data is real. The book works with real-world data from the US Census and other government agencies, and US Census geography data is keyed by identifiers that are full of leading zeros, from ZIP codes to state and county codes. If a learner opens a CSV in Excel, edits it, and saves it, the identifiers change type silently, and then every join and every geographic match in the later chapters returns the wrong answer or nothing at all. The failure is invisible until a query returns zero rows and you assume the SQL is wrong.

The instruction to be careful about the encoding is the other half of it. Saving a UTF-8 file in a different encoding produces mojibake in the text columns, and the book has a chapter on mining text, so the encoding of the text data is load bearing for the later exercises.

This is a case where a repository README is doing real work that the book format cannot. The warning has to be repeated in both places, because a reader who downloads the archive and opens a file before picking up the book will never see the printed version.

Getting the code: a zip for everyone, a clone for the ones who will keep up

There are two documented ways to get hold of everything, and the difference is about whether you intend to work through the book over weeks or months.

For non-GitHub users, you can obtain all the code and data at once by downloading the repository as a .zip file: click the Code button at top right, click Download ZIP, then unzip the file on your computer and place it in a directory that is easy to remember, so you can reference it during the exercises that include importing data to PostgreSQL. The advice to put it somewhere memorable is practical rather than cosmetic, because chapter 2 and chapter 5 both involve pointing an import at a file path.

For GitHub users, the guidance is to clone the repository locally and occasionally perform a git pull to receive updates:

git pull

That is the whole mechanism, and it points at the reason the four markdown files at the root of the repository exist. The code does not change, the data does not change, but the installation instructions for PostgreSQL and pgAdmin do, and the errata accumulate as readers report problems. Pulling periodically is how you get those.

So the repository is a moving document in a way that a code archive usually is not, and the distinction between the two audiences is a sensible one. A reader working through the book in a fortnight benefits from a zip and never needs to know what a pull is. A reader going slowly benefits from a clone, because the software-installation-updates and faq-updates-errata files are the parts that will actually matter to them in month three.

Maintenance, the first edition fork, and how to get an answer

The maintenance picture is small and healthy. The last push to the repository was on 2026-08-14, and the repository is not archived, with no GitHub releases, which is the right shape for a book companion where there is nothing to version as an artefact.

The licence is recorded as a custom one that GitHub cannot classify, with a LICENSE.md at the root as the authoritative text, so read that file if you intend to reuse the queries or the data commercially. The data itself comes from US Census and other government agencies, which typically carries its own usage terms, so the practical question for anyone reusing it commercially is what those terms are rather than what the repository licence says.

The edition split is handled clearly, which is a common source of confusion for companion repositories. If you are reading the first edition of the book, published in 2018, you should use the code and data in the first edition repository. If the cover of your copy does not say 2nd Edition, then you are using the first edition. That check takes two seconds and saves you from running first-edition SQL against second-edition schema.

Support is handled by issue tracker, with the note that the author will answer usually within 1 to 2 business days, and an email address for other inquiries.

One more file deserves a mention because it says something about how the project is run. There is a pgadmin-ai-assistant.md at the root of the repository. Given that the book's own documentation warns that pgAdmin's interface has moved on since publication, it is a reasonable bet that the project is exploring how to help readers bridge the gap between the printed instructions and the current tool.

Editorial conclusion

Adopt this repository if you are learning SQL properly and want to practise on real government data with queries that are known to work, since the alternative is a synthetic dataset and a tutorial that may never have been run. Do not adopt it as a reference for a specific database engine, because the SQL taught is PostgreSQL and the book explicitly does not cover T-SQL. Before you start, read the warning about opening the CSV files in Excel, because that step silently corrupts the ZIP code columns, and check the faq-updates-errata file and the software-installation-updates file, since both change as the tools move on.

Frequently asked questions

Official sources

1. anthonydb/practical-sql-2 on GitHub
2. Issues
3. README