Closing message

  • Even outside database work, everyone eventually hits "this query is slow, this database sucks" — this class puts you in a position to understand what the system is trying to do for you, and whether you are working with it or against it (1:18:55).

The technology-choice recommendation

  • Avoid premature optimization. Do not assume your data will be huge and reach for Snowflake or another scale-out system (1:19:28).
  • Recommended order: Postgres first, then DuckDB — that covers roughly 99% of the way, and Postgres alone is good enough for nine out of ten people (1:19:28, 1:19:57).
  • By the time Postgres or DuckDB falls apart, you will likely have the money to hire someone to build or migrate to a large-scale system (1:19:57).

Q&A — backups in Postgres

  • Use pg_dump / PG backup; it can also do deltas that you append back. This is what he does nightly for the db.io website (1:20:17, 1:20:48).
  • On a hosted service like RDS, the provider handles it for you (1:20:48).
  • For a hypothetical ~100 GB database: PG backup writing to external storage is good enough for a long time. Replicas are for high availability, not backup — Postgres has gotten better at standby replicas, but then you are managing that yourself (1:21:11, 1:21:33, 1:22:04).

Q&A — managed service vs self-hosting

  • Depends on money and priorities. For a startup, nobody cares whether you self-host Postgres — that time is better spent making the application better, so offload to a managed provider (Neon's free tier is called out as generous) (1:22:04, 1:22:28, 1:22:51).

Q&A — MotherDuck

  • MotherDuck is the commercial offshoot of DuckDB, founded not by the DuckDB creators but by the person who ran BigQuery for 10 years — and who wrote the "most data isn't that big" blog post behind the earlier slide (1:22:51, 1:23:06).
  • What it does: a DuckDB extension that offloads part of a query plan to the cloud. If some data is local and some sits in S3, MotherDuck runs DuckDB in the cloud next to the remote data and returns results instead of pulling everything down — no change to the SQL query (1:23:06, 1:23:32, 1:23:56).
  • On whether DuckDB will scale out across nodes: VCs repeatedly asked whether DuckDB could become "the next Snowflake". The answer given was that is a major rewrite, the founders did not want it, and they did not do it — judged the smart call (1:24:17, 1:24:41).