<- all tokdocs
2026.10.12@arjay_mccandless

Postgres hit 589 req/s to SQLite's 1,244 on a one-vCPU droplet, which SQLite's own documentation calls the expected outcome of comparing a library to a server rather than a Postgres defect

Coding
Watch on TikTok

View on TikTok ->

The artifact is a 108.833333 s MP4 (container mov,mp4,m4a,3gp,3g2,mj2, 9,848,766 bytes, overall bitrate 723,952 bps) carrying one HEVC Main-profile video stream at 1080x1920, yuv420p, a constant 30/1 fps and 669,174 bps across 3,265 frames, plus one AAC HE-AACv2 audio stream at 44,100 Hz stereo, 48,071 bps, 2,347 frames, running 108.831927 s; yt-dlp recorded format id bytevc1_1080p_723947-1 and a rounded 108 s duration. The post timestamp is epoch 1791844309, or 2026-10-12T22:31:49Z, from uploader arjay_mccandless (uploader id 7352567358922097710, nickname "Arjay McCandless"), with audio credited as "original sound" by Arjay McCandless. The description is 71 characters and is a byte-for-byte copy of the title. At the metadata capture time (metadata.json mtime 2026-10-19 00:23:43 local) the counts read 39,400 views, 2,584 likes, 36 comments and 55 reposts. I read 21 of the 54 extracted frames: 001, 004, 006, 009, 011, 014, 018, 023, 025, 026, 027, 029, 033, 037, 038, 039, 040, 042, 046, 050 and 053, sampled at 2 s intervals so that frame_NNN sits at (NNN-1)x2 seconds. The transcript holds 463 words across 46 segments. The visual track is a split screen: a cream motion-graphics panel on top, the creator talking to camera in a white kitchen below, overlaid with burned-in auto-captions. Frame 001 (0 s) shows a "Postgres" card wired to an empty bar labeled "? req/s". Frame 004 (6 s) shows a spec card reading "DigitalOcean droplet", "Go API / net/http", "$12/mo", "2 GB RAM" and "Ubuntu", captioned "12 DOLLAR SERVER". Frame 006 (10 s) lists the seed data as "50,000 users", "500,000 posts" and "2,016,005 likes" feeding both engines, underlined "identical, checked byte for byte". Frame 011 (20 s) resolves the headline chart to "589 req/s" for Postgres, "1,244 req/s" for SQLite and a boxed "2.1x", footnoted "same Go code, CPU maxed", after frame 009 (16 s) held SQLite as a "?". Frame 014 (26 s) wires a Go "connection pool" of conn 1 through conn 4 one-to-one into four Postgres "backend process" boxes under the line "10 connections -> 10 Postgres processes". Frame 025 (48 s) fills a card headed "CPU while the server was maxed out" to "58%" labeled "Postgres". Frames 026, 027 and 029 (50 s to 56 s) show a Go "app process" holding "your code / handlers, JSON" beside a struck-out "database server" box, then redraw it as "one process" containing a Go "handler" wired to a "SQLite library". Frame 037 (72 s) shows "Postgres / row locks, all at once" with W1, W2 and W3 aligned, and frame 038 (74 s) adds "SQLite / one writer at a time" with the same bars staggered. Frames 039 and 040 (76 s, 78 s) label a second test "write-heavy mix / 43% writes" and resolve it to "Postgres 573" against "SQLite 233", footnoted "req/s . both fsync every commit to disk". Frame 042 (82 s) draws "app server #1", "#2" and "#3" converging on "Postgres / one shared DB", and frame 046 (90 s) shows a crossed-out "Primary" promoting to "New primary" under "streaming replication, built in", with "Patroni" and "pg_auto_failover" cards labeled "failover tool". Frame 050 (98 s) is a comparison table giving SQLite the checks for "Speed on one server" and "Setup: just a file" and Postgres the checks for "Many writers at once", "Many app servers" and "Replication, failover". Frame 053 (104 s) is a product screenshot headed "DEVMAXX" showing "LEVEL . 2 OF 8 / Junior Dev", "2,308 / 2,500 XP to Mid", "Silver . Rank 16 of 20 / 109 XP to move up" and a "NEXT LESSON / CDNs & Edge" card. No frame I read shows a terminal, a load-generator name or its output, Go source, a SQL schema, a PostgreSQL version, a SQLite PRAGMA or journal mode, a latency percentile, or a repository link: every benchmark figure is asserted on a motion-graphics card and never shown being produced. The spoken argument is that Postgres loses a one-box read-heavy load test because it runs as a separate server process reached over IPC while SQLite links into the application as a library, and that Postgres earns its production default anyway through concurrent writers, multiple app servers, built-in replication, granular permissions and extensions. On the transcript-end check: the audio runs 108.831927 s, but Whisper timestamps segment 45 as 107.04 to 116.96 s, overshooting the audio by 8.13 s. That segment, "You can check it out on the App Store or Google Play", starts inside real audio and matches the on-screen store beat, so the words are genuine and only the end timestamp is padded. Nothing after 108.83 s should be treated as spoken.

The process-model explanation is correct, and the fork it describes happens at connect time rather than per query

At 21.44 s the video says "Postgres runs as its own database server, completely separate from your application," and at 24.56 s "it actually creates a separate backend process for every single connection." The PostgreSQL architectural fundamentals page states the same thing: "The PostgreSQL server can handle multiple concurrent connections from clients. To achieve this it starts ("forks") a new process for each connection. From that point on, the client and the new server process communicate without intervention by the original postgres process." At 53.12 s the video says "SQLite runs as a library inside your application," and sqlite.org's About page opens with "SQLite is an in-process library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine," adding that "SQLite does not have a separate server process. SQLite reads and writes directly to ordinary disk files."

The part the video compresses is where the cost lands. The fork the documentation describes is paid once, when a connection is opened. Frame 014 at 26 s shows a Go connection pool captioned "10 connections -> 10 Postgres processes", which is a pooled setup: ten backends are forked at startup and reused for the length of the test. Under that arrangement the per-request cost is not process creation. It is the socket round trip between the Go process and a backend, the context switches that round trip forces on a single core, and the per-statement work PostgreSQL does that SQLite does not, including parse, plan, execute, MVCC visibility checks and WAL accounting. At 37.36 s the video calls this "a lot of overhead" without naming any of it, and at 34.08 s it says "my database and application are actually running on the same exact machine" without saying whether the Go client connected over a Unix-domain socket or over localhost TCP. The PostgreSQL connection settings documentation shows both paths exist, with unix_socket_directories defaulting to /tmp and the note that "only Unix-domain sockets can be used to connect" when listen_addresses is empty. Those paths carry different per-call costs, and the video never says which produced 589 req/s.

SQLite's own documentation predicts this result and declines the comparison the video builds on

The framing device, stated at 0.00 s as "Why is Postgres so slow compared to SQLite?", is a question SQLite's maintainers answer by rejecting its premise. The "Appropriate Uses For SQLite" page states flatly: "SQLite does not compete with client/server databases. SQLite competes with fopen()." The About page repeats the same instruction: "Think of SQLite not as a replacement for Oracle but as a replacement for fopen()."

The same page anticipates the exact scenario the video built. On SQLite as the storage layer inside an application server, it reports: "Developers report that SQLite is often faster than a client/server SQL database engine in this scenario. Database requests are serialized by the server, so concurrency is not an issue." A read-heavy mix driven by one Go process on one core is precisely that scenario. The 2.1x gap on frame 011 is therefore the documented, expected behavior of an embedded library beating a client/server engine on a workload that removes every reason the client/server engine exists. It is not evidence that PostgreSQL is slow in any general sense, and the video's hook presents it as though it were.

The same page already draws the boundary the video reaches in its second half: "If there are many client programs sending SQL to the same database over a network, then use a client/server database engine instead of SQLite," and "If the website is write-intensive or is so busy that it requires multiple servers, then consider using an enterprise-class client/server database engine instead of SQLite." Every advantage the video lists for Postgres after 60.08 s is already enumerated in SQLite's own guidance.

The benchmark figures are internally consistent, and the hardware is the reason they do not generalize

At 15.36 s the video says Postgres "maxed out at about 590 requests per second" and at 18.80 s that "SQLite handled over 1,200." Frame 011 at 20 s gives the precise figures, 589 and 1,244 req/s, and boxes the ratio as "2.1x". That checks: 1244 divided by 589 is 2.112. At 42.88 s the video says Postgres "was using about 60% of the CPU"; frame 025 at 48 s shows 58%, so the spoken figure is a rounding of the card and not a separate claim. At 47.84 s the video adds that "my Go application was using about a quarter," and that figure appears in no frame I read: the CPU card shows only the Postgres share.

The hardware decides the whole result, and the video is honest about it in passing. At 39.36 s it says "on a server with just one CPU, these are both competing for the same resources." Frame 004 identifies the box as a DigitalOcean droplet at $12 per month with 2 GB RAM running Ubuntu, but prints no vCPU count. DigitalOcean's published Droplet pricing confirms the spoken detail: the $12.00 per month Basic tier is 2 GiB RAM, 1 vCPU, 2,000 GiB transfer and 50 GiB SSD. On one core, every cycle the PostgreSQL backend spends is a cycle the Go process cannot have, and the 58 percent on frame 025 measures that zero-sum split directly. Add a second core and the contention term changes. The video never runs that variant, so 2.1x is a number about one $12 droplet rather than about the two engines.

The seed data is stated but not checkable. Frame 006 claims 50,000 users, 500,000 posts and 2,016,005 likes loaded into both engines, "identical, checked byte for byte", and no frame shows a checksum or row count confirming it. The read-heavy mix is spoken at 12.56 s as "92% reads, 8% writes" and appears on no card I read, unlike the write-heavy mix, which gets its own "43% writes" bar.

The write-heavy reversal is the strongest segment, and its "both fsync every commit" caption is the one claim with no supporting evidence

At 75.60 s the video says "when I switched to a write-heavy mix" and at 77.04 s "SQLite actually performed much worse than Postgres." Frame 040 at 78 s puts numbers on it that the voice track never speaks: Postgres 573 req/s against SQLite 233 req/s at 43 percent writes, a 2.46x reversal. This is the most useful stretch in the video: it inverts the headline on the same hardware with the same code and shows the architecture argument cutting both ways.

The footnote on that same card, "req/s . both fsync every commit to disk", is a configuration claim and the video supplies nothing to back it. For PostgreSQL the claim holds at defaults. The runtime WAL configuration documentation gives synchronous_commit a default of on, described as specifying "how much WAL processing must complete before the database server returns a "success" indication to the client", and fsync is likewise on by default, described as making "sure that updates are physically written to disk, by issuing fsync() system calls or various equivalent methods". For SQLite the claim holds only under specific pragmas. The WAL documentation states it explicitly: "Writers sync the WAL on every transaction commit if PRAGMA synchronous is set to FULL but omit this sync if PRAGMA synchronous is set to NORMAL." No frame I read names the SQLite journal mode or the synchronous pragma, and the transcript never mentions either. Whether the two engines were actually matched on durability is therefore unverified, and durability settings move SQLite write throughput by a large multiple. The same page notes that "WAL is significantly faster in most scenarios," so the journal-mode choice alone could account for a meaningful share of the 233 figure.

"SQLite can only handle one write at a time under a standard setup" is accurate, hedge included

At 71.36 s the video says Postgres "can handle multiple write transactions at the same time" and at 73.36 s that SQLite "can only handle one under a standard setup." Frames 037 and 038 draw this as three write transactions running in parallel under Postgres with the note "row locks, all at once" against three staggered bars under SQLite with the note "one writer at a time".

Both halves check out, and the qualifier "under a standard setup" does real work. The SQLite WAL documentation states that "WAL provides more concurrency as readers do not block writers and a writer does not block readers," then immediately draws the limit: "However, since there is only one WAL file, there can only be one writer at a time." The FAQ says the same about the default rollback journal: "only one process can be making changes to the database at any moment in time." Turning on WAL mode, the first thing most production SQLite deployments do, buys reader-writer concurrency but not multiple concurrent writers, so the video's phrasing survives the distinction intact.

The FAQ also supplies the reason Postgres wins the write-heavy test, in SQLite's own words: "client/server database engines (such as PostgreSQL, MySQL, or Oracle) usually support a higher level of concurrency and allow multiple processes to be writing to the same database at the same time."

The replication and failover segment is correct, and names the right external tools

At 86.00 s the video says "Postgres also has built-in replication," and at 87.68 s that "you can combine with some other pre-existing tools to have things like automatic failover." Frame 046 at 90 s underlines "streaming replication, built in" and puts "Patroni" and "pg_auto_failover" in boxes labeled "failover tool".

That split is exactly the one the PostgreSQL documentation draws. Streaming replication is a core feature, but the failover chapter states that "PostgreSQL does not provide the system software required to identify a failure on the primary and notify the standby database server. Many such tools exist." The same page warns that an operator "must have a mechanism for informing the old primary that it is no longer the primary. This is sometimes known as STONITH (Shoot The Other Node In The Head)." Promotion itself is a manual pg_ctl promote or pg_promote() until something external decides to issue it.

Both tool names on the card are spelled correctly and both are live. Patroni's documentation describes it as "a template for high availability (HA) PostgreSQL solutions using Python," supporting automatic failover through etcd, Consul, ZooKeeper or Kubernetes across PostgreSQL 9.3 through 18. pg_auto_failover is maintained by Microsoft under the hapostgres GitHub organization as "a Postgres extension and service for automated failover and high-availability" for PostgreSQL 13 through 18, and the repository is not archived. The remaining Postgres advantages, spoken at 91.04 s as "granular user permissions" and at 92.56 s as "a lot of extensions for things like vector search or geospatial data", are uncontested, and the table on frame 050 assigns the checkmarks the sources support.

Key Takeaways

  • Verified: Postgres forks one backend process per client connection and SQLite links in-process. The PostgreSQL architecture page says the server "starts ("forks") a new process for each connection"; sqlite.org says "SQLite does not have a separate server process."
  • Verified: The figures are internally consistent. Frame 011 shows 589 and 1,244 req/s against the spoken "about 590" and "over 1,200", and 1244/589 equals the boxed 2.1x. Frame 025's 58% matches the spoken "about 60%".
  • Verified: The $12 per month DigitalOcean Basic Droplet is 1 vCPU and 2 GiB RAM, confirming the one-CPU contention described at 39.36 s. Frame 004 shows the price and the RAM but omits the vCPU count.
  • Clarification: Frame 014 shows a pooled ten-connection setup, so the per-connection fork is paid once at startup rather than per request. The recurring cost is the socket round trip plus PostgreSQL's parse, plan, MVCC and WAL work, none of which the video names.
  • Correction: The headline premise, that Postgres is "slow compared to SQLite", is one SQLite's maintainers reject. The "Appropriate Uses For SQLite" page states "SQLite does not compete with client/server databases. SQLite competes with fopen()," and predicts the video's own result: "Developers report that SQLite is often faster than a client/server SQL database engine in this scenario."
  • Unverified: Frame 040's footnote "both fsync every commit to disk" is substantiated nowhere. PostgreSQL fsyncs at commit by default, but SQLite does so only at PRAGMA synchronous=FULL; the WAL docs say writers "omit this sync if PRAGMA synchronous is set to NORMAL." No frame or transcript line states SQLite's journal mode or synchronous setting.
  • Partial correction: WAL mode gives SQLite reader-writer concurrency, which frame 038's "one writer at a time" card omits, but not multiple concurrent writers: "since there is only one WAL file, there can only be one writer at a time." The video's hedge "under a standard setup" survives this.
  • Verified: Streaming replication is built into PostgreSQL and automatic failover is not. The failover chapter states "PostgreSQL does not provide the system software required to identify a failure on the primary and notify the standby database server," matching the video's "combine with some other pre-existing tools" at 87.68 s. Patroni and pg_auto_failover are spelled correctly on frame 046 and both are actively maintained.
  • Correction: The Whisper transcript renders the promoted app as "DevMax" at 100.48 s. The on-screen title on frame 053 is "DEVMAXX" and the product site spells it "Devmaxx". The creator's own burned-in captions are machine-generated too and fail on the subject matter: frame 026 reads "SEQUELITE", frame 039 reads "A RIGHT HEAVY MIX" where the card above it says write-heavy, and frame 040 reads "POSTGRESS".
  • Context: No frame shows a terminal, a load-generator name, source code, a schema, a PostgreSQL version or any raw output. Every number is an asserted card, and the video closes on a product the creator sells.
  • Context: The most useful number is never spoken. Frame 040 shows Postgres at 573 req/s against SQLite at 233 at 43 percent writes, a 2.46x reversal on the hardware that produced the 2.1x headline.

Resources

Published October 12, 2026. Writeup generated from a favorited TikTok.