Blog - kimserey lam

Aug 26, 2026

Go Basics — Types, Memory and Data Structures

This is the first tutorial in a series on Go. It covers three foundational topics: pointers and references (how Go passes data around and when mutations are visible), structs with methods and receivers (how Go models data and behavior without classes), and slices and maps (the two built-in data structures you will use constantly). Each section builds on the previous one — pointers explain why receiver types matter, and receiver types explain how slice and map patterns work in practice.

Aug 22, 2026

DuckLake — Open Lakehouse with DuckDB

DuckLake is a lakehouse format built as a DuckDB extension. It separates metadata from data: a catalog (a local .ducklake file or a PostgreSQL database) tracks table schemas, snapshots, and file pointers, while Parquet files hold the actual data on a local filesystem or in S3-compatible object storage. This separation is the central design decision — the catalog knows what files exist, what columns they contain, and what value ranges they hold, but it never stores the data itself. In this post, we’ll go from running DuckLake locally to running it with PostgreSQL and MinIO, look at how partitioning organizes data in S3, and see how DuckLake’s query engine prunes files and pushes predicates down to avoid reading data it doesn’t need.

Aug 19, 2026

AWS Networking for Aurora RDS PostgreSQL

Running PostgreSQL in AWS isn’t just about creating the database — you first build the network it sits in. With Aurora RDS, you are the network engineer: you decide the IP range, which parts are reachable from the internet, what traffic is allowed between resources, and which data centers your database runs in. This post walks through the core networking concepts — VPC, subnets, gateways, route tables, security groups, and DB subnet groups — that you need to understand before provisioning Aurora RDS PostgreSQL.

Aug 15, 2026

Debezium PostgreSQL Connector — Failure Modes and Slot Management

Debezium’s reliability comes from PostgreSQL’s replication slots — they guarantee that no WAL is discarded before the connector has consumed it, so a crashed connector can catch up without data loss. But that same guarantee creates the biggest operational risk: an abandoned slot tells PostgreSQL to hold WAL indefinitely, and on a busy database the WAL can fill the disk. This post covers connector failure and recovery, leaked slots, and how Debezium handles schema evolution.

Aug 12, 2026

Debezium PostgreSQL Connector — Configuration That Matters

The default Debezium connector config produces usable events, but the defaults leave important gaps — before values are missing on UPDATEs and DELETEs, all tables are captured including system tables, and each table gets its own Kafka topic. This post covers the configuration knobs that close those gaps: replica identity, table filtering, publication modes, and single-topic routing with the ByLogicalTableRouter transform.

Aug 08, 2026

Debezium PostgreSQL Connector — CDC in Action

Debezium is a distributed CDC platform that tails PostgreSQL’s Write-Ahead Log and produces a Kafka event for every row change. It runs as a connector inside Kafka Connect, which means you deploy it by POSTing a JSON config to a REST API — no custom code needed. This post walks through setting up a local Debezium stack, registering a connector, and reading the events it produces.

Aug 05, 2026

PostgreSQL Logical Replication and CDC

PostgreSQL logical replication lets an external consumer receive a stream of row-level changes (INSERT, UPDATE, DELETE, TRUNCATE) from the database in real time. It piggybacks on the Write-Ahead Log — the same mechanism Postgres already uses for crash recovery — and exposes decoded, row-level events over a TCP connection using Postgres’s own wire protocol. This is the foundation for Change-Data-Capture (CDC): a consumer connects, creates a replication slot, and starts receiving a stream of changes it can forward to Kafka, another database, a search index, or anywhere else.

Aug 01, 2026

Why Parquet, and Why It Works So Well on S3

If you’ve been following the OLAP series, Parquet will look familiar — it’s essentially the production-grade, standardized version of what we built in Phase 1 and Phase 2. Phase 1’s columnar vectors map to Parquet’s column-by-column layout within row groups. Phase 2’s row groups with column segments and zone maps map directly to Parquet’s row groups with column chunks and min/max statistics. The main structural difference is that our format stores segment headers inline before each column’s data, so you walk through the file sequentially. Parquet moved all that metadata into a footer with precomputed absolute byte offsets — and that single design decision is what makes the S3 range-request pattern possible. This post is about why that matters.

Parquet is a columnar binary file format with a metadata footer at the end of the file. The footer contains the schema, the location (byte offset and length) of every column chunk in every row group, and statistics like min/max and null counts for each. Because all of this is laid out with precise byte offsets, a reader that can fetch arbitrary byte ranges can navigate a Parquet file surgically — read the footer, decide what it actually needs, and fetch only those bytes.

Jul 29, 2026

Transaction Isolation and Exported Snapshots in PostgreSQL

Transaction isolation levels control what data a transaction can see when other transactions are concurrently modifying the database. Understanding them is essential for CDC (Change Data Capture), where an initial snapshot of the database must be taken at the exact point a replication slot is created — ensuring no gaps or overlaps between the snapshot and the WAL stream.

This post explains the four isolation levels, the read anomalies they prevent, how MVCC snapshots work under the hood, and how PostgreSQL’s exported snapshot mechanism ties it all together for CDC.

Jul 25, 2026

OLAP – Phase 10 Sorting, Parallel Execution, REPL, and Server

The database can parse SQL, plan queries, join tables, and aggregate results. But it’s missing four things that make it usable: ORDER BY (sorting results), parallel execution (using multiple CPU cores), an interactive REPL for exploring data, and a TCP server for remote connections.

This phase ties everything together into a complete, runnable OLAP engine.

Jul 22, 2026

OLAP – Phase 9 Query Planner and Optimizer

The parser produces an AST — a syntactic representation of the SQL query. But the AST doesn’t know whether table names exist, what types columns have, or how to execute the query efficiently. This phase bridges the gap with three components: a binder that resolves names and types, an optimizer that rewrites the logical plan for efficiency, and a physical planner that maps logical operators to executable physical operators.

The pipeline is: AST → Binder → Logical Plan → Optimizer → Physical Planner → Physical Plan.

Jul 18, 2026

OLAP – Phase 8 SQL Parser

The execution engine from Phases 5-7 works, but it requires manually constructing operator trees and expression objects in Go code. A real database accepts SQL text from users. This phase builds a SQL parser that converts a SQL string into an Abstract Syntax Tree (AST) — a structured representation that the planner (Phase 9) can transform into a physical execution plan.

The parser has two stages: a lexer that splits the SQL string into tokens, and a recursive descent parser that builds the AST from the token stream.

Jul 15, 2026

OLAP – Phase 7 Hash Join

Analytical queries rarely touch a single table. “Revenue by region” needs to join orders with regions. “Sales by product category” needs to join sales with products with categories. The hash join is the standard OLAP join algorithm — it builds a hash table from one table (the smaller one), then probes it with the other (the larger one), achieving O(n + m) complexity instead of nested-loop’s O(n x m).

This phase implements the HashJoinOperator with support for INNER and LEFT joins, including NULL key handling.

Jul 11, 2026

OLAP – Phase 6 Hash Aggregation

The scan/filter/project pipeline from Phase 5 processes rows one batch at a time — it’s a streaming operation where each batch flows through independently. Aggregation (GROUP BY with SUM, COUNT, AVG) is fundamentally different: it needs to see all the data before producing any output. This makes it a pipeline breaker — it consumes all input, builds an internal state, then emits results.

This phase implements GROUP BY aggregation using a hash table: the HashAggregateOperator, the GroupByHashTable, and five aggregate functions (COUNT, SUM, AVG, MIN, MAX).

Jul 08, 2026

OLAP – Phase 5 Vectorized Expressions and Scan/Filter/Project

The storage layer can persist and read columnar data. Now we need to query it. This phase builds the execution engine’s foundation: expressions that evaluate on entire vectors at once (2048 rows per call), and three physical operators — SeqScan, Filter, and Projection — that form the basic query pipeline.

The key insight is vectorized execution: instead of evaluating amount > 100 one row at a time, we evaluate it on 2048 rows at once in a tight loop. This eliminates per-row function call overhead and lets the CPU pipeline and cache work efficiently.