# Sammy Steele - Scaffolding for Scale (Highlights)  ## Metadata **Review**:: [readwise.io](https://readwise.io/bookreview/61998476) **Source**:: #from/readwise #from/reader **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Sammy Steele]] **Full Title**:: Scaffolding for Scale **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **Document Tags**:: #work **URL**:: [www.figma.com](https://www.figma.com/blog/how-figmas-databases-team-lived-to-tell-the-scale/) **Host**:: [[www.figma.com]] **Highlighted**:: [[2026-07-12]] **Created**:: [[2026-07-18]] ## Highlights - We built a DBProxy service that intercepts SQL queries generated by our application layer, and dynamically routes queries to various Postgres databases. ([View Highlight](https://read.readwise.io/read/01kxazep24wdqr02nykkqnrex3)) ^1033623108 - We avoided having to implement “filtered logical replication” (where only a subset of data is copied to each shard). Instead, we copied over the entire dataset and then only allowed reads/writes to the subset of data belonging to a given shard. ([View Highlight](https://read.readwise.io/read/01kxazg2hg857fshyzsqpr6rhk)) ^1033623134 - One downside of this is that range-scans on shard keys are less efficient, since sequential keys will be hashed to different database shards. However, this query pattern is not common in our codebase, so it was a trade-off we were willing to live with. ([View Highlight](https://read.readwise.io/read/01kxazmm7p5jbzwq96fvwcfe2g)) ^1033623377 - Rolling back logical sharding when we found bugs was a simple configuration change. Rolling back a physical shard operation is possible, but it requires more complex coordination to ensure data consistency. ([View Highlight](https://read.readwise.io/read/01kxaznna51xcyznfv7wmyf4hx)) ^1033623392 - Once a table is logically sharded, all reads and writes will act as if the table is already horizontally sharded. ([View Highlight](https://read.readwise.io/read/01kxaznzj0gpj5w090efqm39by)) ^1033623402 - To determine the right subset, we built out a “shadow planning” framework, which allowed users to define potential sharding schemes for their tables and then run shadow the logical planning phase on top of live production traffic. We logged the queries and associated query plans to a Snowflake database, where we could run offline analysis. From this data, we picked a query language that supported the most common 90% of queries, but avoided worst-case complexity in our query engine. ([View Highlight](https://read.readwise.io/read/01kxazvv3pbgz6meejmjwqayqq)) ^1033623925