Copy-and-Replay vs Branch-at-a-Point: Two Backup Recovery Paths
A side-by-side comparison of copy-and-replay recovery and branch-at-a-point restores, showing why restore time scales with data size in one model and not the other.
Loading…
Topic
Postgres
301 posts about Postgres. Every summary links to the original.
- 301 posts
- 15 companies
- 2 explainers
See the idea
Postgres explainers
Agent Memory: What Outlives the Run
Agent memory is the knowledge that survives a run, not the working state inside one. This explainer separates the two, then maps the write path, the read path, and the database limits that cap recall.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
Branching databases like code: a CI/CD pattern for Lakebase, in production at Glaspoort
Glaspoort replaced a sprawl of outdated, one-off BI reports with a custom application that combines Databricks analytical tools with Lakebase, a serverless Postgres OLTP database. The application keeps curated lakehouse data in a read-only schema while application state occupies a separate schema, and supports development, acceptance, and production environments. Its CI/CD pattern treats database branches like code: long-lived environments branch directly from production, each pull request receives an ephemeral production-shaped branch, migrations are replayed, and a staging app image runs the full test suite against it. This topology makes periodic resets cheap, avoids deleting dependent branches, and preserves fresh test data; the team chose stacked promotion for velocity, retaining a separate crisis pipeline for urgent fixes.
Eclipse Dataspace Components on AWS: Cost optimization strategies
Deploying Eclipse Dataspace Components (EDC) connectors on AWS presents challenges in forecasting infrastructure expenses without clear benchmarks. Estimated costs differ substantially between business-critical setups and non-critical environments based on compute and database sizing. A business-critical configuration relying on Amazon Aurora PostgreSQL db.r6g.large and standard Amazon ECS with AWS Fargate totals an estimated 387.00 USD monthly in the eu-south-2 region. Sizing down to db.t4g.medium and switching to AWS Fargate Spot lowers the non-critical monthly expense to 164.00 USD, representing a 58% reduction. Core cost drivers remain baseline infrastructure components, while storage, API calls, and data transfers contribute marginally under baseline assumptions.
What happens in the milliseconds after you tap pay
At checkout, fraud scoring must combine transaction inference with customer-specific rules while keeping latency low enough for an interactive payment. The retail-app sample pairs a FastAPI backend and React frontend in a Databricks App with Model Serving route optimization and Lakebase Postgres, where the model retrieves historical features and the backend reads profile controls. A transaction is scored first, then checked against daily spending, international-transaction, and country rules; pooled OAuth-authenticated connections and token-rotation handling avoid repeated handshakes and stale credentials. In the supplied benchmark, route-optimized calls reached 27.2 ms p50 and 37.3 ms p95 end-to-end, with feature lookup at 8.9 ms p50, CatBoost inference at 0.4 ms, and network overhead at 17.4 ms p50; actual performance varies by model.
Why Trainy migrated from Amazon RDS Postgres to ClickHouse Managed Postgres
Trainy’s Pluto is an open-source experiment tracker that separates analytics metrics in ClickHouse Cloud from relational run metadata in Postgres. Its original metadata store, Amazon RDS Postgres, was too expensive for the volume observed and contributed to slower initial page loads, so Trainy migrated roughly 40–50 GB to ClickHouse Managed Postgres, which uses local NVMe storage and keeps both databases in one account. After migration, initial page loads became 2–3 times faster, while a complex query reported as taking 10–15 minutes previously returned in five seconds; visualization queries over runs with hundreds of thousands of steps typically return in 50–100 milliseconds at the P50. Trainy reports 100% reliable ingestion with zero dropped data points and says the unified stack could support future joins between GPU metrics and run metadata, as well as governed agent access.
How we configure huge pages in ClickHouse Managed Postgres
ClickHouse Managed Postgres configures Linux huge pages to reduce the per-connection page-table cost and translation overhead of a large PostgreSQL shared_buffers cache. The configuration reserves a quarter of machine memory before PostgreSQL starts, verifies HugePages_Total, sets huge_pages = 'on' to prevent silent fallback, and sizes shared_buffers against the complete shared-memory segment, including buffer descriptors, WAL buffers, and lock tables. On an r7i.4xlarge with 32GB shared_buffers, 4KB pages added 31.1MB of page tables per connection and reached 6.12GB at 200 connections, while 2MB huge pages reached 111MB. A select-only pgbench test at 100 clients also rose from 373,083 TPS to 418,087 TPS, a 12% increase, while startup failure without a sufficient pool made misconfiguration explicit.
Foundational context: Cross-industry & function-specific accelerators for Lakebase
Databricks presents Lakebase as a fully managed, serverless, standard Postgres database for combining operational and analytical workloads on its Data + AI Platform. The platform separates compute from storage, integrates with the lakehouse through Synced Tables and Lakebase CDF, and uses Unity Catalog for governance; copy-on-write branching and autoscaling to zero are described as core infrastructure primitives. The post showcases partner-built, ready-to-deploy accelerators spanning technology, finance, marketing, sales, supply chain, human resources, customer service, and operations. Examples include PostgreSQL migration assessment, multi-agent Genie orchestration, stateful enterprise agents, autonomous data reliability, governed contact-center intelligence, and project operations management. These offerings package Lakebase patterns into migration controls, domain-specific solutions, and agent frameworks intended to accelerate modernization and reduce transformation complexity.
How Trigger.dev is using ClickHouse to scale observability for long-running AI workflows
Trigger.dev, an open-source platform for serverless asynchronous tasks, needed to scale observability for increasingly complex, long-running AI workflows spanning thousands of tenants. Its initial Postgres design stored logs, traces, and events in a growing table, making indexes, analytics, and operational reliability increasingly difficult to manage. The team moved observability workloads to ClickHouse after evaluating performance, scalability, open-source compatibility, deployment flexibility, and support for dynamic telemetry, including its native JSON data type. Migration occurred gradually at the task-execution level, routing each run’s logs to either database without downtime or customer intervention. ClickHouse now supports real-time telemetry analysis, approximately 200-millisecond P95 latency for queries returning tens of thousands of rows, and a dramatically smaller telemetry storage footprint.
Searchable field-level encryption on Supabase with CipherStash
CipherStash’s integration for Supabase adds searchable field-level encryption to Postgres applications without requiring a schema change. The encrypted Supabase SDK wrapper encrypts marked fields in the application, stores each value as a JSON payload containing ciphertext and Searchable Encrypted Metadata (SEM), and converts queries to SEM so Postgres can filter, sort, and join without plaintext access. ZeroKMS keeps keys under the customer’s control, while decryption policies determine who can read each value; the source states that neither CipherStash nor Supabase can access plaintext data. The integration supports Supabase.js, Drizzle, and Prisma Next, with a one-command setup, and CipherStash Proxy covers analytics, background workers, and other direct database access through the Postgres wire protocol.
Introducing pg_re2, fast, RE2-powered regular expressions in Postgres
pg_re2 is a Postgres extension that brings RE2-powered regular expression functions and operators to Postgres, designed to address both execution speed and syntax compatibility with ClickHouse. It uses finite-automata-based RE2 rather than Postgres's backtracking POSIX engine, and version 0.4.0 adds the @~ operator plus btree and GIN index support. Benchmarks on an AWS m6g.2xlarge with PostgreSQL 18 report RE2's functions running at 1.8x to 8.6x the speed of native equivalents, while indexed operations are 1.1x to 1.8x faster. With pg_clickhouse, using RE2-backed functions such as re2match() keeps regex behavior consistent between Postgres execution and ClickHouse pushdown, including patterns such as Quake\b. The extension duplicates ClickHouse's suite for string search, replacement, extraction, and splitting.
AI needs the best-of-breed data stack: Postgres and ClickHouse
AI-native applications generate large volumes of operational data, while agents and users increasingly require real-time answers from that data. This pressure raises both query concurrency and reliability requirements, with a cited sample of companies using Postgres and ClickHouse showing more than 1,000% data growth in six months and over 85 TB added. The proposed stack assigns Postgres low-latency transactional workloads and ClickHouse real-time analytics, connecting them through PeerDB and ClickPipes CDC with single-digit-second replication, pg_clickhouse query pushdown, and pg_stat_ch telemetry streaming. The conclusion is that AI makes the OLTP/OLAP distinction more important, favoring an open best-of-breed stack over a single platform while preserving each database's specialized role.
98% faster queries, 50% lower cloud costs: Verihubs’ journey from Postgres to ClickHouse
Verihubs rebuilt its data warehouse after a Postgres-based, daily-batch pipeline became slow, unreliable, and difficult to correct when late vendor callbacks required backfills. The new architecture uses Kafka, Kafka Connect, and Debezium for real-time ingestion into ClickHouse, with MergeTree for append-only logs and ReplacingMergeTree for datasets updated through change data capture. Materialized views create daily and monthly rollups, projections accelerate existing query patterns, and Dagster handles complex detection workflows that can notify Slack. The migration, completed in about six months, reduced query times from 20–30 minutes to two or three seconds on datasets up to 18 million rows, representing as much as 98% faster queries and 50% lower infrastructure costs. Verihubs says the resulting real-time OLAP system gives finance and operations fresher data for traffic analysis, reconciliation, performance reporting, and invoicing.
ClickHouse Agents is now available for Managed Postgres
ClickHouse Agents is now available for all Managed Postgres services in ClickHouse Cloud, extending its plain-English agent interface to operational data. The beta service, powered by Claude and built on LibreChat, combines an agent builder and chat interface with a sandboxed code interpreter; it is read-only by default and supports MCP-compatible systems. Agents can inspect Postgres schemas, run read-only queries, return the SQL used, and reason across Postgres and ClickHouse by querying each engine independently before merging results. Additional skills guide migration from Postgres to ClickHouse through discovery, access-pattern analysis, schema design, type mapping, CDC ingestion, and validation, while other workflows use metrics, Query Insights, and EXPLAIN to rank performance fixes. Planned extensions include scheduled recommendations and safe automated remediation, but the current release focuses on exploration, analysis, monitoring, and guided database work.
How we scale PgBouncer in ClickHouse Managed Postgres
PgBouncer is single-threaded, so a single process can bottleneck connection pooling on multi-vCPU machines even when Postgres has capacity. ClickHouse Managed Postgres runs a fleet of PgBouncer processes sized to available cores, sharing one port through so_reuseport; peering forwards query-cancellation requests to the process that owns the session, while transaction pooling and per-process connection-budget splits limit Postgres connections. In tests on identical AWS EC2 c7i.4xlarge pooler instances, a 16-process fleet reached roughly 336,000 transactions per second at 256 clients, compared with 76,893 for one process, while using about 49% versus 8% in-guest CPU. The fleet's advantage emerged under concurrency, whereas the single process was slightly faster at eight clients, and the described setup ships by default with every ClickHouse Managed Postgres server.
From monolith to Lakebase to LTAP: rethinking the database from storage up
The post examines why monolithic OLTP databases become fragile and difficult to scale when compute, the write-ahead log (WAL), and data files share one machine. Using Postgres as its primary example, it contrasts local WAL durability and physical cloning with Lakebase, whose stateless Postgres compute externalizes those components into SafeKeeper and PageServer services. SafeKeeper replicates log records across a quorum through Paxos-based network replication, while PageServer applies the WAL and materializes data in cloud object storage. The resulting separation is presented as a way to improve durability, independently scale reads and writes, isolate workloads, and support high availability and branching without physical database clones. LTAP extends the design by making transactional tables directly queryable for analytics from a single governed copy, avoiding CDC or mirroring and allowing transactional and analytical engines to scale independently.
ClickHouse is now a native connection in Notion Custom Agents
ClickHouse is now a native, preconfigured connection in Notion Custom Agents, allowing agents to access ClickHouse Cloud data without leaving Notion. After an OAuth connection, agents can explore schemas, translate plain-language questions into ClickHouse SQL, run read-only queries, and return results in the workspace. The connection exposes 14 read-only tools covering databases and tables, SELECT queries against ClickHouse and Managed Postgres, and organization, service, ClickPipes, backup, and cost information; users can set each tool to run automatically or require approval. Custom Agents can run on a schedule, including a daily observability report that queries error rates, p99 latency, and request volume from a Managed ClickStack service. The connector is in beta and requires a ClickHouse Cloud service with Remote MCP enabled plus a Notion Business or Enterprise workspace.
Why we rewrote WAL-G for Postgres backups in Rust: Meet WAL-RUS
ClickHouse Cloud built WAL-RUS, an open-source Rust implementation of PostgreSQL backup and WAL archival tooling, after encountering difficulty predicting WAL-G’s memory usage in resource-constrained environments. The project preserves WAL-G’s core functionality and compatibility while using bounded worker pools, controlled concurrency, persistent object-storage connections, and a streaming pipeline that limits buffering and data copies. It uses the same WALG_ configuration variables, and WAL-G and WAL-RUS can read each other’s archives. In a sustained WAL-heavy benchmark with four archival workers, WAL-RUS stayed below 1 GB of peak virtual memory versus nearly 2.8 GB for WAL-G, while both maintained minimal backlog and comparable CPU usage. The authors plan to make WAL-RUS the default backup and archival mechanism for ClickHouse Cloud’s managed Postgres offering and are working to upstream its Postgres 17 wal summaries support to WAL-G.
How Vibe.co handles billions of ad impressions with ClickHouse Cloud
Vibe.co, recently acquired by Walmart, uses ClickHouse Cloud to provide real-time campaign reporting for thousands of Connected TV advertisers across billions of ad impressions. It migrated from Postgres after aggregation-heavy OLAP queries made its pre-aggregation layer a bottleneck, limiting interactive slicing and requiring new jobs for reporting use cases. The team evaluated self-hosted ClickHouse, another managed option, and ClickHouse Cloud, choosing the latter for operational simplicity, support from ClickHouse engineers, and separation of storage and compute with more predictable costs. Vibe uses refreshable materialized views for hot/cold tiering, keeping the last 30 days in a hot table; stored data grew from about 100 GB to over 2 TB without rearchitecting, while more than 90% of client campaign reports respond in under 100ms.
What To Look For in a Serverless Database for AI Applications
Serverless databases are presented as a baseline for AI applications whose traffic can be volatile, idle for long periods, or spike when agents fan out queries. The guide distinguishes managed serverless systems from autoscaling products by focusing on architectural separation of compute and storage, true scale-to-zero, cold-start behavior, connection handling, pricing, performance, portability, governance, and AI capabilities such as vector search. It recommends evaluating both low- and high-utilization costs, published warm-up times, tail latency (p95/p99), and built-in pooling or HTTP/Data APIs for high-concurrency agents and serverless functions. The text positions Lakebase as an example that combines serverless Postgres, shared lakehouse storage, and Unity Catalog governance, and cites reported cost and management reductions from a 2025 study while noting that provisioned deployments may suit continuously high-throughput workloads.
What Is Serverless PostgreSQL?
Serverless PostgreSQL is presented as a fully managed cloud database model that decouples compute and storage, allowing each to scale independently with demand. Traditional deployments require teams to size infrastructure, manually manage scaling, and absorb costs from idle capacity. In serverless systems, the provider provisions compute on demand, can suspend it when idle, and bills according to active usage; scale-to-zero may introduce cold-start latency. The architecture can also support database branching through copy-on-write, creating isolated environments without duplicating data. The article distinguishes this model from lakebase architecture, which combines transactional and analytical workloads on a shared foundation using decoupled compute, durable object storage, log-based storage systems, and orchestration.
Databricks positioned highest in execution and furthest in vision for the second consecutive year in Gartner Magic Quadrant
Databricks says Gartner positioned it highest for execution and furthest for vision in the Magic Quadrant for the second consecutive year. The post connects this recognition to a category reclassified from “Data Science and Machine Learning” to “AI Platforms for Data Science and Machine Learning,” and argues that agentic applications require enterprise data, governance, observability, and business context. Databricks presents a unified approach combining the lakehouse, Lakebase, Agent Bricks, Unity Catalog, and Unity AI Gateway to build, monitor, and govern agents, models, data, apps, and tools. Reported examples include YipitData’s 20x increase in company coverage with 92–95% tagging accuracy, Block’s unified AI and data estate, and Novo Nordisk’s attribution of more than $157 million in net new value to governed clinical-trial optimization.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.