yugabyteDB Developer's Notebook

November 2026

Question: I've been manually downloading data from a home battery system's app and a weather station's web export, and hand-loading CSVs into yugabyteDB. What does a real, unattended pipeline for this look like, end to end?

Farrell: This month's article is built around a real daemon that replaced exactly this manual workflow -- polling a Tesla Fleet API every 5 minutes and a daily weather export every ~20 hours into yugabyteDB. Three real, non-obvious bugs surfaced along the way, each confirmed live against the actual API rather than found in documentation.

Read article (PDF)

October 2026

Question: Someone pasted a list of six Prometheus metric names into Slack and asked whether we could alert on them. I can't find any of these names in the yugabyteDB docs. Are they real?

Farrell: None of the six exist verbatim, but each has a real, close equivalent. This month we track down all six against a live 8-node cluster and actually try to trigger each one -- three proved out cleanly, and the other three produced real, verified findings about exactly why the obvious trigger doesn't move the needle under this cluster's configuration.

Read article (PDF)

September 2026

Question: Once a query plan goes bad in production, without anyone changing the query or schema, how do we find out automatically? yugabyteDB's Query Plan Management sounds like exactly this -- does it catch everything?

Farrell: Good nuance in that question. This month we reproduce a real, measured 280x plan-cache regression against a live cluster, confirm directly that QPM's own automatic cost-vs-reality flag does not catch this specific failure mode, and build a working, complementary monitor that does.

Read article (PDF)

Derived in part from: github.com/farrell0/query-optimizer

August 2026

Question: My team keeps hitting query plans we didn't expect. Is there a mental model for how yugabyteDB actually picks a plan, with some real, worked examples?

Farrell: Yes. This month we walk through eight verified exercises against a live cluster -- sharding strategy, pattern-matching indexes, join mechanics, a classic DISTINCT anti-pattern, correlated subqueries, and a real customer case separating join-order effects from index-column-order effects.

Read article (PDF)

Derived in part from: github.com/farrell0/query-optimizer

July 2026

Question: My company wishes to understand the options for change data capture (CDC) when using yugabyteDB. We wish to avoid the cost of polling the database with SQL SELECTs to determine when conditions have changed. Can you help?

Farrell: Excellent question! There are two distinct CDC subsystems built into yugabyteDB -- gRPC change data capture and PostgreSQL logical replication. Each has its own application and use. This article details both systems, including two complete, runnable demonstrations.

Read article (PDF)

Derived in part from: github.com/farrell0/cdc-01 and github.com/farrell0/cdc-02

June 2026

Question: We found documentation showing yugabyteDB can COPY a table straight to a Parquet file on S3 with one SQL statement. We tried it and it didn't work. Is this real, and what's the actual working path?

Farrell: pg_parquet is real and works for local files -- exporting straight to an s3:// destination in one COPY statement does not work today, confirmed directly against a live cluster. This month covers the real, working three-step pipeline that gets you there instead.

Read article (PDF)

May 2026

Question: We keep hearing yugabyteDB has a "smart driver" that's cluster-aware and does its own load balancing. What does that actually mean, and can we see it really distributing connections?

Farrell: This month, six real connection-distribution outcomes, one per load_balance driver setting, captured directly from a live 6-node cluster -- plus how the driver reacts differently to two different kinds of node blacklisting.

Read article (PDF)

April 2026

Question: We need a fast way to undo a bad deploy without a full restore, and an audit trail of who ran what against a sensitive table. Does yugabyteDB have real answers for both?

Farrell: Yes to both, each with real edges worth knowing. Point-in-Time Recovery is built on a genuinely clever hard-link mechanism; pgAudit is configurable down to the specific role and table, but has several real, confirmed configuration gotchas covered this month.

Read article (PDF)

March 2026

Question: We created a colocated database and a table with an explicit TABLESPACE clause specifying an 8-way replica placement. No error, but the data wasn't actually placed that way. What's going on?

Farrell: A real, reproducible gap: a colocated table's placement is never controlled by a TABLESPACE named on that table -- only by the database's own default placement. This month covers exactly why, plus several other real placement boundaries.

Read article (PDF)

February 2026

Question: We want to build an actual "next best offer" recommendation feature with real product data and a real distributed HNSW index, and we want honest numbers, not a marketing benchmark.

Farrell: This month is built around a real H&M retail dataset, yugabyteDB's own distributed ybhnsw index, a real published benchmark's actual recall/latency numbers, and why vector search is a candidate-generation stage, not the whole feature.

Read article (PDF)

Derived in part from: github.com/farrell0/vector-search-3

January 2026

Question: We have a real MongoDB application and we're evaluating yugabyteDB. Do we have to go through the MongoDB-compatible API, or is there a more direct path?

Farrell: There are genuinely two paths. This month covers both, using MongoDB's own MFlix sample app -- the MongoDB-API path hits the same secondary-index gap from December's article, while the JSONB-in-YSQL path this project actually runs in production sidesteps it entirely.

Read article (PDF)

Derived in part from: github.com/farrell0/mflix_jsonb