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
308 posts about Postgres. Every summary links to the original.
- 308 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
Enabling Evolutionary Database Development: database branching with Lakebase, continued
This installment revisits Evolutionary Database Design and argues that Databricks Lakebase removes the infrastructure constraints that kept several of its database-change practices aspirational. Lakebase is a managed Postgres database with compute separated from shared durable storage, while copy-on-write branches create a new pointer and divergence marker in roughly one second without copying parent data. That enables per-developer, per-PR, and per-experiment databases, real Postgres test branches instead of mocks or in-memory substitutes, and CI isolation at pull-request granularity. The updated playbook adds idempotent migrations, destructive testing, and database-level A/B prototyping, with Unity Catalog governance inherited by branches and agents receiving branches rather than production access. Jen’s example corrupts production-shaped data to test an inventory-code migration and compares column and lookup-table designs, rejecting the latter because its common read path requires a join.
Multigres v0.1 Alpha: an operating system for Postgres
Multigres v0.1 alpha is an open-source release of a system intended to provide Vitess-grade horizontal scaling, high availability, and operational simplicity for Postgres. It manages Postgres instances with sharding, connection pooling, automatic failover, and backup orchestration, while this release adds advanced pooling, automatic failovers, and a Kubernetes operator. Its high-availability protocol builds on unmodified Postgres replication, supports user-defined durability policies, resolves split-brain scenarios without losing succeeded commits, and permits replica changes while running. The release is suitable for experimentation but not production workloads: v0.1 is single-shard, sharding is absent, the custom-resource API may change, backward compatibility is not guaranteed, and performance benchmarks are still in progress.
Supabase Series F
Supabase has raised a $500M Series F at a $10B pre-money valuation, led by GIC. Existing investors participated, Stripe invested again, and Georgian and Salesforce Ventures joined as new investors; the funding will accelerate open-source and Postgres tooling, support growth, and provide employee liquidity. Supabase is also releasing Multigres v0.1 alpha, an open-source, self-hostable scalable operating system for Postgres designed to provide high availability and operational simplicity; a future release is intended to add Vitess-grade horizontal scaling. The alpha is ready to try but not production-ready, with production-readiness expected in a few months. Over the past year, database launches grew 600%, more than 60% of new databases came from AI tools, and nearly 10 million developers built on Supabase.
Thank you for building with us
At its 2026 user conference in San Francisco, ClickHouse reports surpassing 4,000 customers and $250 million in annual run-rate revenue, while marking nearly ten years since Alexey Milovidov open-sourced the database. The company attributes its growth to a community of contributors and describes use across AI products, financial services, observability, analytics, and infrastructure. New offerings include ClickHouse Agents, a fully managed agentic analytics service powered by Anthropic’s Claude; CostBench, an open benchmark using each warehouse’s real billing model; and House Mates, a partner program launching with more than 50 partners across six continents. Additional updates include Managed Postgres in public beta, Managed ClickStack and Langfuse for AI-era observability, generally available full-text search, and automatic JOIN optimization, with cost-performance identified as the central constraint for high-concurrency, low-latency workloads.
ClickHouse tops $250M ARR and 4,000 customers, launches Claude-powered agents at Open House 2026
At Open House 2026, ClickHouse announced that its serverless cloud offering exceeded $250 million in annual run-rate revenue and reached 4,000 customers, with ARR more than tripling year-over-year and more than 1,000 net new customers added since January. The company launched ClickHouse Agents, a fully managed, no-code agentic analytics service powered by Anthropic’s Claude, with a chat interface, sandboxed code interpreter, artifacts, skills, memory, multi-agent workflows, and MCP-compatible integrations. It also published CostBench, an open benchmark applying each vendor’s real compute billing model to the same workload; ClickHouse Cloud was reported to have 23x better cost-performance than the nearest cloud data warehouse. Other announcements included Managed Postgres in public beta, managed ClickStack, generally available full-text search, cross-region replication, and the House Mates partner program.
Introducing Always-On pricing: automatic savings for Databricks Lakebase
Databricks introduces Always-On pricing for Lakebase, offering a lower rate for baseline compute while retaining elastic autoscaling. On any Lakebase Postgres Autoscaling project, operators turn off scale-to-zero and set an autoscaling range; the minimum capacity becomes the baseline, which receives the lower rate after 24 hours of continuous use. Capacity above the minimum continues to autoscale up to the configured maximum and is billed at standard Autoscaling rates, while users can re-enable scale-to-zero later. The pricing targets established workloads with a consistent activity floor; intermittent or new workloads can retain scale-to-zero to avoid paying for idle hours and uncertain baseline estimates. The announcement says the baseline price is 25% lower, and an additional 50% promotional discount runs through January 31, 2027.
How the lakebase architecture stays resilient to cloud failures
Lakebase is adapting its reliability architecture to agentic and on-demand workloads, which create far more control-plane activity, database starts, and pressure on finite cloud capacity. Lakebase uses stateless Postgres compute over zone-resilient storage, dedicated multi-availability-zone computes for optional high availability, and a vertically autoscaling virtualization layer that reduces dependence on cloud provisioning control planes. A dedicated data-plane controller is being developed for hot-path start and suspend operations, while cell-based regional deployments isolate failures and allow capacity to expand incrementally. The reliability program also uses component and whole-availability-zone failure injection, consistency checks, Service Level Indicators, and Service Level Objectives, including startup, failover, storage, and API measurements. The stated target is for every database to exceed 99.99% monthly availability; reported 2026 attainment through April shows 99.75% to 99.85% of databases meeting that threshold.
Open House 2026 Day 1: Real-time data without lock-in and what teams can build next
ClickHouse’s Open House 2026 Day 1 announced updates spanning ClickHouse Cloud, Postgres, distributed query execution, observability, AI agents, and lakehouse interoperability. ClickHouse Postgres entered public beta with local NVMe storage, high availability, S3-backed point-in-time recovery, and a native CDC path into ClickHouse; early benchmarks reported more than 5x the transactions per second of AWS RDS. Multi-stage distributed queries repartition intermediate data between stages to scale joins and high-cardinality aggregations, reducing TPC-H SF100 runtime from 117.6 seconds on one node to 54.7 seconds on eight nodes. Additional launches included a Claude-powered ClickHouse Agents public beta, an AI-enhanced query builder, Monitoring v2, and Langfuse V4’s reported 200x query performance improvement, while the wrap-up framed the releases around real-time systems without lock-in.
Postgres managed by ClickHouse is now in beta
ClickHouse Cloud has launched a fully managed Postgres service in beta to combine transactional and analytical workloads within a single platform. Backed by local NVMe storage, the service provides up to ten times faster transactional performance alongside native change data capture into ClickHouse. Developers can query across both transactional and analytical layers using the pg_clickhouse extension without managing custom data pipelines. The platform also offers managed migration workflows via ClickPipes, database branching, point-in-time recovery, high availability with up to two standbys, and support for over ninety PostgreSQL extensions. More than fifty virtual machine configurations are available, ranging from single vCPU instances to clusters with ninety-six vCPUs and sixty terabytes of NVMe storage.
clickhousectl v0.2.0: Postgres, ClickPipes and more
clickhousectl v0.2.0 expands the beta CLI with local and ClickHouse Cloud managed Postgres, ClickPipes, SQL over HTTP for Cloud services, agent-oriented output changes, and a standalone Rust client for the ClickHouse Cloud API. Local Postgres runs in Docker, is keyed by name and major version, stores isolated data under .clickhouse/servers/-pg/data/, and supports versions 16, 17, and 18. ClickPipes covers batch, streaming, CDC, and snapshot sources including object storage, Kafka-compatible systems, Kinesis, Postgres, MySQL, MongoDB, and BigQuery. Cloud queries use a provisioned or lazily enabled Query Endpoint and service-scoped API key, while the endpoint uses sql_console_admin and the key has no organization-level roles. The release also adds Markdown-style tables and credential debugging, with more than 5,000 users reported five weeks into the project.
Unlock seamless and cost-effective marketing campaigns with Lakebase
Retail marketing teams often store customer segments in OLTP databases, creating underused capacity between campaigns and synchronization work whenever new segments are requested. Lakebase, Databricks’ implementation of a lakebase architecture, separates storage from compute and uses elastic, serverless Postgres that can scale to zero when idle and up for bursty campaign traffic. The integration with the Lakehouse uses managed Synced Tables for customer segments and Lakehouse Sync for continuous CDC-based replication of operational data into Unity Catalog Delta tables. The SAP Engagement Cloud example configures a Lakebase Autoscaling project, native Postgres credentials, an ISRG Root X1 certificate, and snapshot synchronization for datasets with more than 10% updated. The post concludes that this design lowers idle and sizing costs, reduces pipeline maintenance, and supports low-latency point lookups, while warning that Lakebase is not optimized for large scans or classic OLAP.
How ChatFeatured migrated from PlanetScale Postgres to Postgres Managed by ClickHouse to power AI brand discovery
ChatFeatured, a Toronto-based startup, helps brands track and improve how AI models discover and recommend them, including by analyzing cited sources and guiding content production. As prompt ingestion grew to about 1,000 prompts daily across six AI models, managed Postgres instances became slow, CPU reached 90% during ingestion windows, and PlanetScale hit an IOPS limit; analytics queries remained the deeper constraint. The team migrated from PlanetScale to Postgres managed by ClickHouse using the Postgres-to-Postgres ClickPipes connector, which handled initial load, schema transfer, continuous sync, and a five-minute maintenance window; the migration took 30 minutes overall. This setup retains Postgres for transactional workloads while providing a built-in path to ClickHouse for analytics, and a 30-day LifestyleRx query fell from about two and a half minutes to less than a second, with 20x compression reported for CDN log data.
Backstage with Lakebase, part 2
Part 2 shows how moving Backstage’s operational Postgres database to Databricks Lakebase brings security, auditing, masking, and cost controls under Unity Catalog. The proof of concept used Lakehouse Federation to expose the catalog as the lakebase_bs foreign catalog, replacing cross-service RDS investigations with Unity Catalog grants and system.access.audit records. Audit events identify OAuth users and source IPs, while billing attributed 31.6130 DBU to production and 0.0107 DBU to a dropped test branch. Branch-level attribute masking propagates automatically to feature, CI, and QA copies, while the post cites a Perforce report stating that 60% of organizations experienced breaches or theft in non-production environments. It also introduces LakebaseOps, with three agents and seven scheduled jobs, and Lakebase MCP, exposing 46 governed tools across four profiles, so DBAs can design policies and workflows instead of handling repetitive provisioning.
Postgres FDW: Pushdown is a negotiation
Postgres Foreign Data Wrapper extensions allow PostgreSQL to query external datastores like ClickHouse by delegating execution to remote engines. Engineering pg_clickhouse centers on pushdown decisions that determine whether SQL expressions run remotely or stream raw data back across the wire. Because pushdown depends on planner callbacks, deparser translations, and ClickHouse semantic compatibility, a single untranslated clause can block upper-level query pushdown entirely. Resolving pushdown barriers enables complex analytic queries to return hundreds of rows in milliseconds rather than pulling tens of millions of rows for local processing. Ultimately, pushdown development requires an iterative negotiation across differing SQL grammars, occasionally requiring the revocation of translations that fail to maintain strict equivalence.
From vibe code to production-ready: observability for Next.js and Supabase apps
AI-assisted software development often generates functional code that lacks proper instrumentation, leading to unindexed database queries, N+1 patterns, and fragmented connection strategies. While Supabase provides built-in query analytics, security advisors, and subsystem logs, it cannot trace distributed requests across the entire application stack. Integrating Sentry bridges this visibility gap by establishing distributed traces across Next.js frontends, Deno-based Supabase Edge Functions, and Postgres databases. Teams can forward Supabase logs into dedicated Sentry projects and configure runtime integrations to automatically detect performance bottlenecks such as slow spans and Web Vitals regressions. Furthermore, integrating Model Context Protocol servers allows Sentry's Seer debugger to identify root causes and generate automated fixes for emerging issues.
Supabase Is Now an Official ChatGPT App
Supabase is now an official app in ChatGPT, allowing users to connect Supabase projects and manage database infrastructure through conversation. The app provides 29 tools for executing SQL on Postgres, designing and modifying schemas, listing tables and extensions, checking security recommendations, and handling project operations such as logs, costs, pausing, and restoring. It also supports development branches and migrations, serverless edge functions, and direct Supabase documentation search, while ChatGPT Projects can scope chats to a project reference. Users install it from ChatGPT’s app directory, authorize access to their Supabase organization, and can use it on all Supabase plans with paid ChatGPT plans. The stated result is conversational management of Supabase projects without leaving ChatGPT.
Introducing Postgres Query Insights in ClickHouse Cloud
ClickHouse Cloud introduced Query Insights in preview for Managed Postgres to help teams diagnose slow database queries. Powered by the open-source extension pg_stat_ch, the tool streams per-statement telemetry directly into ClickHouse to enable fast aggregations across billions of execution rows. Postgres normalizes query literals into placeholders during the parse-analyze phase before telemetry leaves the database, preventing sensitive data exposure. Telemetry emission maintains around three percent producer overhead by utilizing a non-blocking try-lock on a shared-memory ring buffer. Users can examine high-level database health metrics, rank query patterns by runtime or latency percentiles, and inspect execution flyouts detailing disk spills, cache hits, and parallel worker behavior.
How lakebase architecture delivers 5x faster Postgres writes
Lakebase’s separation of Postgres compute and distributed storage removes the local-disk torn-page risk that necessitates full page writes (FPW) in traditional deployments. The change disables FPW on compute and moves full page image generation into the pageserver, which creates reset points after a configured number of WAL deltas while preserving bounded read reconstruction. In HammerDB TPROC-C tests, 32-vCPU throughput rose from 95,686 to 439,300 new orders per minute, while average WAL per transaction fell from 58KB to under 4KB, a 94% reduction. Production validation reported WAL reductions from 30MB/s to 1MB/s on a 56-vCPU project, p99 read latency improvements of 30% to 50%, and up to threefold regional storage p99 improvement. The rollout reached all Lakebase Serverless and Neon databases without restarts or customer interruption, using the existing XLOG_FPW_CHANGE mechanism.
How nOps rebuilt their cloud optimization platform on Databricks Lakebase, and why other ISVs should too
nOps migrated its production cloud optimization platform to Databricks Lakebase, a fully managed PostgreSQL database integrated with the Databricks Lakehouse. Its previous setup separated customer-facing operational data from analytics, requiring scheduled jobs, cron-based change-detection logic, and synchronization work that introduced lag and operational overhead, especially as workloads expanded to GCP and Azure. In the new architecture, Lakebase is the central Postgres database and single source of truth for the front end and AI infrastructure, while the Lakehouse continuously consumes its data for analytics and metric computation. Databricks Metric Views are automatically surfaced in the application, and data flows one way without direct write-back. The reported results are faster data pipelines, lower operational overhead, and a better customer experience, with auto-scaling, auto-stop, restore, OAuth, and compatibility features supporting adoption.
Realtime or Pipelines? How to choose the right tool
Supabase Realtime and Supabase Pipelines both read PostgreSQL changes through logical replication, but they target different jobs. Realtime delivers live updates and communication to browsers and apps through Broadcast, Presence, and Postgres Changes; its Postgres Changes path checks Row Level Security for subscribed users, uses temporary replication slots, and offers best-effort delivery without replay after disconnects. Pipelines is a managed change-data-capture system that performs an initial sync, then replicates selected publication data in batches to supported analytical destinations through a persistent replication slot, retaining progress and retrying transient failures. The choice depends on the destination and delivery needs: use Realtime for low-latency user experiences that can tolerate gaps, Pipelines for durable analytical copies with at-least-once processing and idempotent destination writes, and both when an application needs both capabilities.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.