DEV Community: Abhishek Sharma

Phoenix LiveView vs Rails Hotwire: I Built the Same Real-Time App in Both. The Numbers Aren't Close.

Abhishek Sharma — Sun, 17 May 2026 13:56:33 +0000

Phoenix LiveView vs Rails Hotwire: I Built the Same Real-Time App in Both. The Numbers Aren't Close

TL;DR — Phoenix LiveView delivers ~5× more HTTP throughput and establishes WebSocket connections ~14× faster under load. Rails is not broken — it's a mature, productive framework — but for real-time collaborative applications, the Erlang VM is a different league.

Why I Did This

Every time the Phoenix vs Rails debate comes up online, the arguments are the same: "Phoenix is fast but Elixir has a small ecosystem." "Rails is slow but you can hire Rails developers." Nobody shows numbers from a fair, controlled experiment.

So I built the exact same app twice — a collaborative real-time todo board — once in Phoenix LiveView and once in Rails 8 + Hotwire. Same features. Same HTML structure. Same Tailwind classes. Different everything underneath. Then I hammered both with k6 and a Node.js WebSocket flood and let the data speak.

The source code and CI results are open on GitHub.

What I Built

A collaborative todo board where multiple users share a room, see each other's presence as colored avatars, and watch todos appear, toggle, and disappear in real time — without any page refreshes. Think a stripped-down Trello card.

Features:

Live presence — colored avatar per connected user, updated instantly
Typing indicator — "[Name] is typing…" shown to all other clients
Real-time CRUD — add, toggle, edit, delete — broadcast to all connected clients

Same URL scheme on both: /room/:id drops you into a shared room.

The Architecture Gap

Before the numbers, you need to understand what's different under the hood. This is the part that explains the numbers.

Phoenix: One socket, one process, zero JS

Browser
 └─ 1 WebSocket
     ├─ LiveView process (stateful, in Erlang VM)
     │   ├─ Phoenix.Presence (CRDT, built-in)
     │   ├─ PubSub subscription
     │   └─ handle_event (add/toggle/delete todo)
     └─ Erlang PubSub ── broadcasts to all LiveView processes

Every browser tab gets one WebSocket that carries everything: DOM patches, presence diffs, typing events. The LiveView process is a long-lived Erlang process (~2KB RAM) that holds the full room state in memory. When a user adds a todo, it goes over the existing WebSocket, the process saves it to Postgres, broadcasts to the room, and sends back a minimal DOM diff — all within the same process. Zero lines of application JavaScript were written for any of this.

Rails: Two sockets, HTTP round-trips, ~200 lines of JS

Browser
 ├─ WS #1: Turbo::StreamsChannel (HTML diffs for todos)
 └─ WS #2: RoomChannel (presence + typing JSON)

HTTP POST/PATCH/DELETE
 └─ TodosController → saves to DB → broadcasts Turbo Stream

Rails Hotwire splits the work across two Action Cable connections per tab. CRUD goes over HTTP (POST/PATCH/DELETE), the controller saves to the DB, then broadcasts a Turbo Stream to update other clients' DOMs. Presence and typing go over a second, separate WebSocket. Three Stimulus controllers (~200 lines of JS) wire everything together on the client.

Neither approach is wrong. Rails' model is straightforward and maps cleanly to how the web works. Phoenix's model is more novel but more powerful. The question is: at what cost?

The Benchmark Setup

Hardware: GitHub Actions ubuntu-latest (2 vCPU, 7GB RAM) — identical for both
Database: PostgreSQL 16 (service container)
Phoenix: dev mode, default config
Rails: dev mode, tuned: 2 Puma workers × 5 threads = 10 concurrent handlers, PostgreSQL Action Cable adapter

Rails was given every reasonable advantage for a fair fight: multiple Puma workers, threads tuned to the core count, and a proper cross-process cable adapter.

Three benchmark tools were run sequentially so they never competed for CPU:

k6 HTTP — ramps from 10 → 100 virtual users, each loading the room page then creating a todo
k6 WebSocket — ramps from 50 → 500 VUs, each connecting and subscribing to a room
ws_flood — opens 500 persistent WebSocket connections and holds them for 20 seconds

The Numbers

All three benchmark tools ran sequentially on the same CI runner so they never competed for CPU. Here's what came back.

HTTP Throughput

Metric	Phoenix LiveView	Rails Hotwire
Request p50 (median)	130 ms	1,484 ms
Request p95	1,051 ms	8,131 ms
Request p99	1,397 ms	8,708 ms
Todo create p95	888 ms	8,138 ms
Todos created in 70s	~3,200	~640
Error rate	0%	0%

Phoenix handled ~5× more requests and responded at the median ~11× faster.

The reason is architectural, not a tuning problem. Rails handles requests with OS threads (bounded by workers × threads). The Erlang VM schedules millions of lightweight processes across all CPU cores, preemptively time-slices them, and never blocks. When 100 users hit simultaneously, Erlang fans them out across all available schedulers. Puma queues them.

WebSocket Flood: 500 Persistent Connections

Metric	Phoenix LiveView	Rails Hotwire
Connections established	500 / 500	500 / 500
Connect p50	30 ms	418 ms
Connect p95	49 ms	704 ms
Connect p99	54 ms	754 ms
Errors	0	0
Memory at 500 connections	~70 MB	~70 MB

Both apps successfully held 500 concurrent WebSocket connections — a good result for Rails after the tuning work. But Phoenix established each connection ~14× faster (30ms vs 418ms at p50).

Memory was the surprise: nearly identical at ~70MB. The Erlang process-per-connection model is often described as memory-efficient, and it lives up to the claim — but so does Rails' threaded model at this scale.

The Rails WebSocket Journey

Getting Rails to 500/500 took three fixes that are worth understanding:

Anonymous connections — Action Cable rejected ws_flood because it had no session cookie. Fixed by returning a temporary identity instead of rejecting.
PostgreSQL adapter — the default async adapter is in-process only. With 2 Puma workers, broadcasts from one worker never reached clients on another. Switched to the PostgreSQL LISTEN/NOTIFY adapter.
Origin header — Action Cable's forgery protection rejects WebSocket upgrades without a matching Origin header. Disabled for development.

None of these are hacks — they're the correct production configuration. The Erlang VM had zero equivalent issues.

The Code Cost

Beyond performance, writing both apps revealed a stark difference in how much you have to build.

What	Phoenix	Rails
WebSocket connections per tab	1	2
CRUD transport	WebSocket (same socket)	HTTP POST → Turbo Stream
Presence system	`Phoenix.Presence` — 1 function call	Custom `RoomPresence` class (~50 lines)
Real-time JS written	0 lines	~200 lines (3 Stimulus controllers)
Cross-process broadcasts	Built into Erlang PubSub	Requires Redis or Postgres LISTEN/NOTIFY

The typing indicator is the clearest example. In Phoenix:

Presence.update(self(), topic, user.id, fn m -> %{m | typing: true} end)

Every connected client sees the update. Done.

In Rails, you write a Stimulus controller to detect keystrokes, send a typed message over the RoomChannel WebSocket, handle it server-side in room_channel.rb, broadcast a JSON blob, then write another Stimulus controller to receive it and update the DOM.

Both work. One is four steps, the other is one.

So Who Wins?

Phoenix wins if you're building real-time

If your app has WebSockets, live presence, collaborative features, or anything where concurrent connections matter — Phoenix is not marginally better, it's a different category. The numbers aren't close: 5× HTTP throughput, 14× faster WebSocket setup, zero JS for real-time, and a built-in distributed presence system that Just Works.

The Erlang VM was built for exactly this problem: massive concurrency, fault tolerance, and low-latency message passing. Phoenix LiveView is the most ergonomic wrapper that problem has ever had.

Rails wins if you're building everything else

The Rails ecosystem is enormous. Gems for every problem. Decades of Stack Overflow answers. A hiring pool that dwarfs the Elixir community. If you're building a standard web app — even one with some real-time features — Rails ships faster. Turbo Streams feel like magic for simple broadcast use cases, and you stay in a language (Ruby) that reads like English.

The performance gap also matters less than the numbers suggest at small scale. If you have 10 concurrent users, both frameworks feel instant.

The honest verdict

For real-time collaborative software: Phoenix. No contest.

For everything else: Rails. No apology needed.

The mistake is treating this as a binary choice about which framework is "better." They optimize for different things. Phoenix optimizes for concurrency — handling thousands of simultaneous connections efficiently. Rails optimizes for developer velocity — moving fast with a rich ecosystem.

The numbers I ran reflect that clearly. Phoenix is not a better Rails. It's a better Erlang/OTP web framework that happens to look friendly.

What I'd Do Differently

Run benchmarks in production mode for both. Dev mode penalizes Rails more (no eager loading, code reloading overhead) and likely flatters the comparison.
Test with Redis backing Rails — the PostgreSQL LISTEN/NOTIFY adapter adds latency that Redis wouldn't.
Increase to 5,000 WebSocket connections to find where each breaks.
Measure memory per connection more precisely — the ~70MB baseline includes the app itself.

The repository is open. Run it yourself, tune it differently, and let me know what you find.

Stack Details

	Phoenix	Rails
Framework	Phoenix 1.7 + LiveView	Rails 8 + Hotwire
Server	Bandit	Puma (2 workers × 5 threads)
Database	PostgreSQL 16	PostgreSQL 16
Cable adapter	Erlang PubSub (built-in)	PostgreSQL LISTEN/NOTIFY
JS written	0 lines	~200 lines
Language	Elixir 1.17 / OTP 27	Ruby 3.3.4

abhsss96 / same-same-but-different

Same UX. Same features. Different stacks. Phoenix LiveView vs Rails Hotwire, head to head.

Phoenix LiveView vs Rails Hotwire

Source for the blog post: "Phoenix LiveView vs Rails Hotwire: What I learned building the same app twice."

Two identical collaborative todo boards, one in each stack. Same features, same HTML structure, same Tailwind classes. Different everything underneath.

phoenix_app/   Phoenix 1.7 · LiveView · Ecto · PostgreSQL · Bandit
rails_app/     Rails 8 · Turbo Streams · Stimulus · Action Cable · PostgreSQL · Puma
bench/         k6 HTTP + WebSocket scripts · Node.js flood script
shared/        architecture diagram (see below)

Architecture

┌──────────────────────────────┐    ┌──────────────────────────────────────┐
│       Phoenix LiveView        │    │         Rails 8 + Hotwire             │
│                              │    │                                        │
│  Browser                     │    │  Browser                               │
│   └─ 1 WebSocket ────────────┼──  │   ├─ WS #1: Turbo::StreamsChannel ───┐ │
│       ├─ LiveView process     │    │   │   (todo HTML diffs)               │ │
│       │   ├─ Presence.track  │    │   └─ WS #2: RoomChannel ─────────────┤ │
│       │   ├─ PubSub.subscribe│    │       (presence +

…

View on GitHub

Zero-Downtime PostgreSQL Major Version Upgrades in Containers: The Problem Nobody Talks About

Abhishek Sharma — Sun, 10 May 2026 08:35:45 +0000

Running PostgreSQL in containers is one of the smartest infrastructure decisions a team can make — until the day you need to upgrade across a major version.

Then it becomes one of the most painful ones.

This post walks through why major PostgreSQL upgrades are uniquely hard in containerized environments, the common approaches teams reach for (and why they hurt), and how pg-upgrade — a Docker-native upgrade toolkit — turns a weekend-long migration into a reproducible, CI-validated three-step process.

Why Containerized PostgreSQL in the First Place?

Before diving into the upgrade problem, it's worth understanding why teams choose self-managed containerized PostgreSQL over managed services like Amazon RDS, Aurora, or Google Cloud SQL.

The cost difference is stark:

Setup	Monthly cost (50 GB, 4 vCPU, 16 GB RAM)
Amazon RDS PostgreSQL (db.r6g.xlarge)	~$400–600/month
Aurora PostgreSQL (db.r6g.xlarge)	~$500–700/month
Self-managed PostgreSQL on EKS (m6g.xlarge node)	~$120–180/month

That's a 3–5x cost difference, which compounds quickly as your data grows. Beyond cost, containerized PostgreSQL gives you:

Full control over PostgreSQL configuration, extensions, and versions
Portability — the same docker-compose.yml works in dev, staging, and production
No vendor lock-in — you're not tied to a cloud provider's upgrade schedule or supported version matrix
Extension freedom — install PostGIS, TimescaleDB, pgvector, or any community extension without waiting for a managed service to support it

The tradeoff? You own the operational complexity. And nowhere does that complexity bite harder than major version upgrades.

The Problem: Major Version Upgrades Are Not Like Container Restarts

Upgrading a PostgreSQL minor version (e.g. 15.3 → 15.7) is trivial — swap the image tag and restart. The data directory format doesn't change.

Major version upgrades (e.g. 13 → 16) are a different beast entirely. PostgreSQL's internal data format changes between major versions. You cannot simply point a PostgreSQL 16 binary at a data directory written by PostgreSQL 13 and expect it to work. It will refuse to start.

The official tool for major version upgrades is pg_upgrade. It migrates the data directory in-place from the old format to the new one. But pg_upgrade has a constraint that makes it awkward in containerized environments:

Both the old and new PostgreSQL binaries must be present on the same machine, with access to the same data directories.

In a container world, this is an unnatural requirement. Your PostgreSQL 13 container has PG 13 binaries. Your PostgreSQL 16 image has PG 16 binaries. They don't share a filesystem, and they were never designed to.

What Teams Actually Do (And Why It Hurts)

Let's look at the common approaches teams reach for when they need to upgrade, and the hidden costs of each.

Option 1: `pg_dumpall` / `pg_dump` + Restore

The most common approach. Dump the entire database with pg_dumpall, spin up a new PostgreSQL 16 container, and restore.

# Dump from old container
docker exec pg13 pg_dumpall -U postgres > full_dump.sql

# Restore into new container
docker exec -i pg16 psql -U postgres < full_dump.sql

The problem:

Downtime scales with database size. A 100 GB database takes 1–3 hours to dump and another 2–5 hours to restore (indexes are rebuilt from scratch). Your application is down for all of it.
No rollback. Once you've promoted the new cluster and your application is writing to it, you can't go back to the dump — it's already stale.
No integrity proof. Did every row make it? Did all sequences reset correctly? Did materialized views survive? You're trusting the process.
Memory and disk pressure. The dump file itself can be enormous. A 500 GB database produces a 200–400 GB SQL file that needs to live somewhere during the migration.

For a production database that your business depends on, multi-hour downtime windows are often simply not acceptable.

Option 2: Logical Replication with `pglogical` or Built-in Slots

A more sophisticated approach: set up logical replication from the old cluster to a new PG 16 cluster, let it catch up, then cut over.

PG 13 (primary) ──logical replication──► PG 16 (replica)
                                            │
                              [catch up, then promote]

The problems:

Replication lag during cutover. Logical replication does not replicate DDL (schema changes). Any schema migrations running during the replication period must be manually applied to both clusters.
Setup complexity is high. You need to configure wal_level = logical, create replication slots, manage slot lag, handle large objects (which logical replication doesn't support), and deal with sequences (which are not replicated).
Slots can accumulate WAL indefinitely. If the replica falls behind, the primary holds WAL segments in reserve. On a busy write-heavy database, this can fill your disk within hours.
Not all data types replicate cleanly. pg_largeobject (lo/bytea blobs stored via lo functions), unlogged tables, and some partitioning configurations don't replicate through logical slots without extra work.
Still requires a cutover window. Even with replication in place, you need a moment where writes stop on the old cluster, you confirm the replica is caught up, and you flip the application over. That window is shorter than a dump/restore — but it's still a window.

Option 3: Snapshot + Restore on a New Node

Cloud-native teams sometimes use volume snapshots: snapshot the EBS/PD volume backing the old cluster, mount it on a new instance with PostgreSQL 16 installed, and run pg_upgrade there.

The problems:

PostgreSQL 16 isn't installed on the new node. You're back to the original problem: pg_upgrade needs both binary sets on the same machine. You either have to install both versions manually or find a way to get them there.
No reproducibility. The upgrade is a manual, unrepeatable operation. If something goes wrong, you start over from the snapshot — but you have no record of what commands were run, in what order, or what state the system was in when they failed.
No integrity check. After pg_upgrade finishes, how do you know the data is intact? You might spot-check a few tables manually, but there's no systematic verification.
Hard to test in staging. The snapshot approach is environment-specific. The commands that worked on production won't necessarily work in your staging environment because the volume setup is different.

Option 4: Manual `pg_upgrade` Inside a Container

Some teams install both PostgreSQL versions inside a single container and run pg_upgrade manually:

FROM ubuntu:22.04
RUN apt-get install postgresql-13 postgresql-16

The problems:

No standard image for this. Every team builds their own one-off image, with different assumptions about data directory paths, binary locations, and user permissions.
Permissions are a minefield. pg_upgrade must be run as the postgres OS user, not root. The data directories must be owned by postgres. Getting this right inside a custom container is non-trivial.
No CI validation. The upgrade is run once, manually, against production. There's no prior test run to prove it would work.
Old Debian/Ubuntu base images hit EOL. PostgreSQL 9.6 was only available on Debian Stretch and Buster, both of which reached end-of-life. Their apt mirrors were moved off the main servers, so apt-get install postgresql-9.6 fails on a fresh install — producing cryptic 404 errors with no obvious fix.

How `pg-upgrade` Solves This

pg-upgrade is a set of Docker images that package both the old and new PostgreSQL binaries, along with three coordinated container steps — init-old, upgrade, and verify — connected by Docker volumes.

The core insight: instead of trying to install two PostgreSQL versions in a running container at migration time, bake both binary sets into a purpose-built upgrade image at build time. Then the upgrade is just docker run.

The Three-Step Pipeline

┌──────────────────────────────────────────────────────────────────┐
│  Step 1 — init-old                                               │
│  Seeds the old cluster with real-world schema: tables, indexes,  │
│  views, sequences, materialized views, FK constraints, sample    │
│  data across multiple databases.                                 │
└──────────────────────┬───────────────────────────────────────────┘
                       │  pg-old-data volume
┌──────────────────────▼───────────────────────────────────────────┐
│  Step 2 — upgrade                                                │
│  Runs pg_upgrade --check (dry run first), then the real upgrade. │
│  Prints before/after directory snapshots, file sizes, structural │
│  renames, and wall-clock duration.                               │
└──────────────────────┬───────────────────────────────────────────┘
                       │  pg-new-data volume
┌──────────────────────▼───────────────────────────────────────────┐
│  Step 3 — verify                                                 │
│  Starts the upgraded cluster and asserts: databases exist, row   │
│  counts match, indexes are intact, views work, sequences are     │
│  preserved, foreign keys survive.                                │
└──────────────────────────────────────────────────────────────────┘

For a production upgrade, you skip init-old and mount your existing data PVC directly into the upgrade step. The old cluster must be scaled to zero first (your downtime window) — but the upgrade itself runs in seconds to minutes, not hours.

Downtime Comparison

Approach	10 GB DB	100 GB DB	1 TB DB
`pg_dump` + restore	30–90 min	3–8 hours	30+ hours
Logical replication cutover	5–30 min	5–30 min	5–30 min
pg-upgrade (copy mode)	~45 sec	~7 min	~70 min
pg-upgrade (link mode `-k`)	< 5 sec	< 5 sec	< 5 sec

Link mode (-k) uses hard links instead of copying data files. The upgrade completes in seconds regardless of cluster size, because no bytes are moved — the old and new clusters share the same underlying files. The tradeoff is that the old data directory is no longer independently valid after the upgrade, so you delete it only after confirming the new cluster is healthy in production.

What the Upgrade Output Looks Like

After the upgrade step, you get a structured report directly in your CI log:

──────────────────────────────────────────────────────────────────────
  Old cluster — PostgreSQL 9.6
──────────────────────────────────────────────────────────────────────
  Path:                /var/lib/postgresql/9.6/main
  Total size:          47M

  Notable structural changes applied during this upgrade:
    pg_xlog/    → pg_wal/    (WAL directory, renamed in PG 10)
    pg_clog/    → pg_xact/   (transaction status, renamed in PG 10)
    pg_log/     → log/       (server log directory, renamed in PG 10)

──────────────────────────────────────────────────────────────────────
  Upgrade complete
──────────────────────────────────────────────────────────────────────
  Cluster size:        47M → 49M  (+4%)
  Upgrade duration:    8s
  PostgreSQL version:  9.6 → 16
──────────────────────────────────────────────────────────────────────

And after the verify step:

──────────────────────────────────────────────────────────────────────
  Verification result — PostgreSQL 16
──────────────────────────────────────────────────────────────────────
  Passed:    9
  Failed:    0
──────────────────────────────────────────────────────────────────────

This is the piece every other approach lacks: a systematic, scripted assertion that the data survived intact.

No Credentials Required

One of the underrated advantages of pg_upgrade over dump/restore or logical replication: it never connects to a running database server. It reads and writes data files directly on disk as the postgres OS user. No database password is passed around, no pg_hba.conf changes are needed, and application credentials (stored in pg_authid) are migrated automatically along with everything else.

CI-Validated Upgrade Paths

Every supported upgrade path — from 9.6→12 all the way through 15→16 — is validated in GitHub Actions on every commit. The matrix runs the full three-step pipeline (init → upgrade → verify) and fails the build if any integrity check doesn't pass.

This means when you pull abhsss/pg-upgrade:13-to-16 and run it against your production data, you're not running an untested script. You're running the same pipeline that passed CI.

Kubernetes Ready, No Changes Required

The same image runs on Kubernetes without modification. Replace Docker volumes with PersistentVolumeClaims and docker run with Jobs:

# Apply the upgrade Job
kubectl apply -f pg-upgrade-job.yaml

# Wait for it to complete
kubectl wait --for=condition=complete job/pg-upgrade-run --timeout=30m

# Check the output
kubectl logs job/pg-upgrade-run

For a production cluster running as a StatefulSet, the workflow is:

Scale the StatefulSet to zero (kubectl scale statefulset postgres --replicas=0)
Run the upgrade Job, mounting the existing PVC
Update the StatefulSet's image tag to PostgreSQL 16
Run the verify Job
Scale the StatefulSet back up

The downtime window is steps 1–5. With link mode, steps 2–4 take under a minute for any database size.

Quick Start

# Pull the image for your upgrade path
docker pull abhsss/pg-upgrade:13-to-16

# Create volumes
docker volume create pg-old-data
docker volume create pg-new-data

# Step 1 — seed test data (skip this in production; mount your existing volume)
docker run --rm \
  -v pg-old-data:/var/lib/postgresql/13/main \
  abhsss/pg-upgrade:13-to-16 init-old

# Step 2 — upgrade
docker run --rm \
  -v pg-old-data:/var/lib/postgresql/13/main \
  -v pg-new-data:/var/lib/postgresql/16/main \
  abhsss/pg-upgrade:13-to-16 upgrade

# Step 3 — verify
docker run --rm \
  -v pg-new-data:/var/lib/postgresql/16/main \
  abhsss/pg-upgrade:13-to-16 verify

# Cleanup
docker volume rm pg-old-data pg-new-data

Supported upgrade paths are published on DockerHub. Images exist for every common path from PG 9.6 to PG 16.

When to Use What

Situation	Recommended approach
Small DB, extended downtime window acceptable	`pg_dump` / restore — simple, no extra tooling
Zero downtime requirement, complex schema with DDL changes during cutover	Logical replication + careful cutover scripting
Containerized PostgreSQL, predictable downtime window	`pg-upgrade` — reproducible, CI-validated, fast
Containerized PostgreSQL, absolute minimum downtime	`pg-upgrade` with link mode `-k`

Want to Contribute?

The project is open source and there are good entry points for contributors at every level. If something above resonated with you, the easiest way to get involved is to pick up one of the open issues:

Good first issues — low scope, well-defined:

#1 — Add pgvector CI matrix entries and fixtures
Add test fixtures that exercise pgvector embeddings through an upgrade, so vector similarity queries survive the migration intact.
#4 — Support --jobs N parallelism for pg_upgrade
pg_upgrade supports parallel catalog processing via --jobs. Wire it through as an environment variable so large clusters with many tables upgrade faster.
#6 — Add a delete-old entrypoint command
After a successful verify, the generated delete_old_cluster.sh needs to be run. Wrapping it as a first-class delete-old command keeps the interface consistent.
#7 — Update the README
Documentation fixes: stale quick-start commands, outdated repo structure, and missing extension docs. Good for a first PR if you want to understand the codebase before touching scripts.
#8 — Fill in missing upgrade matrix paths
Paths like 10→12, 11→13, and 12→13 are absent from the matrix. Adding one requires a new Dockerfile and two lines in the CI workflow — no script changes needed.

Larger contributions — help wanted:

#2 — CI coverage for pg_partman, pg_cron, and pgaudit
Extensions that touch background workers and cron scheduling have different upgrade behavior than data extensions. This adds matrix entries and verify assertions for each.
#3 — Add PG 17 as an upgrade target
PG 17 ships on Debian Bookworm (OpenSSL 3), while older source versions were compiled against OpenSSL 1.1. Getting both to coexist in one image requires a careful COPY --from and ldconfig dance.
#5 — Support --link and --clone upgrade modes
Link mode (-k) reduces upgrade time to under 5 seconds regardless of cluster size. Clone mode offers a middle ground. This wires both through as options without breaking the default copy-mode behavior.

No contribution is too small. Open an issue first if you want to discuss scope before sending a pull request.

Conclusion

Containerized PostgreSQL is a compelling alternative to managed cloud databases — significant cost savings, full control, and no vendor lock-in. But that control comes with responsibility, and major version upgrades are where that responsibility shows up most clearly.

The conventional approaches — dump/restore, logical replication, manual pg_upgrade — all work, but they carry hidden costs: hours of downtime, unrepeatable procedures, no systematic integrity verification, and no way to prove the upgrade would succeed before running it against production.

pg-upgrade addresses each of these. It's a reproducible, Docker-native upgrade pipeline that runs the same three steps in CI that you'll run in production. The upgrade is fast (seconds to minutes, not hours), the output is structured and machine-readable, and the verify step gives you a signed-off assertion that the data survived intact — before you promote the new cluster and scale your application back up.

Source code and contribution guidelines: github.com/abhsss96/postgres-upgrade-kit

Docker images: hub.docker.com/r/abhsss/pg-upgrade

Use your Obsidian vault from Neovim, organized by project

Abhishek Sharma — Sun, 26 Apr 2026 16:51:00 +0000

I built notes-nvim because I wanted to use my Obsidian vault from inside Neovim without leaving my project.

Obsidian is great for storing notes — graph view, mobile sync, plugin ecosystem. But my actual work happens in Neovim, and every Alt-Tab over to grab something from my vault was a small context-switch tax. Multiply that by a day of deep work and it adds up.

notes-nvim points at any markdown directory — your existing Obsidian vault, a plain ~/notes folder, anything — and exposes it inside Neovim, organized automatically by project. When you're inside my-api, your notes live under my-api/. When you switch to dotfiles, you're looking at dotfiles/. Plain markdown, no custom format, your vault stays portable.

The core idea

Most note plugins go one of two ways:

Project-local — notes live inside the project folder. Clean in theory, but they end up in .gitignore purgatory and scatter across dozens of repos.
Global flat pile — one big notes folder. Works until you have 200 files and no way to filter by context.

notes-nvim takes a third path: all notes live in one central directory (~/notes by default), but they're automatically organized by project root. When you're inside my-api, your notes go to ~/notes/my-api/. When you switch to dotfiles, you're looking at ~/notes/dotfiles/.

~/notes/                ← can be your existing Obsidian vault
  daily/                ← one shared daily log across all projects
    2026-04-26.md
    2026-04-25.md
  my-api/
    _index.md           ← auto-created, links to every note in the project
    auth.md
    api-design.md
  dotfiles/
    _index.md
    zsh.md

You get the organization of project-local notes without the mess of scattering files across repos.

Using it with your existing Obsidian vault

If you already have an Obsidian vault, point notes-nvim straight at it:

{
  "abhsss96/notes-nvim",
  opts = {
    notes_dir = "~/Documents/ObsidianVault",
  },
}

The plugin treats it like any markdown directory. Notes you create from Neovim show up in Obsidian on next open. Notes you create in Obsidian are searchable and openable from Neovim. Your vault stays a vault — Obsidian sync, mobile, and plugins keep working.

Native Obsidian features like [[wikilinks]] and embeds aren't fully resolved inside Neovim yet — that's the next big direction (more on this below).

Features at a glance

Daily notes — :NoteToday opens today's YYYY-MM-DD.md, shared globally across all projects
Project index — _index.md is auto-created per project and backlinks every note you create
Note from visual selection — select code in visual mode, hit <leader>ns, get a new note pre-populated with the snippet, source file, and line range
Link-safe rename — :NoteRename updates every markdown link pointing to the old file
Tag search — find notes by #hashtag or YAML tags: frontmatter
Recent notes — :NoteRecent surfaces notes you visited lately via oldfiles
Multi-picker — works with snacks.nvim, telescope, fzf-lua, or the built-in vim.ui.select
File browser — opens in oil.nvim, nvim-tree, neo-tree, or netrw — whichever you have
snacks.dashboard integration — show recent notes on your startup dashboard
which-key — <leader>n group registered automatically
Health check — :checkhealth notes-nvim tells you what's wired up and what's missing

Installation

lazy.nvim (recommended):

{
  "abhsss96/notes-nvim",
  opts = {
    notes_dir = "~/notes",
  },
}

That's it for a working setup. The plugin auto-detects your fuzzy picker and file browser — no extra wiring required for most setups.

Commands and keymaps

All commands are available as both Ex commands and keymaps under <leader>n:

Command	Keymap	What it does
`:Note [name]`	`<leader>no`	Open or create a note in the current project
`:NoteToday`	`<leader>nt`	Open today's daily note
`:NoteIndex`	`<leader>ni`	Open `_index.md` for the current project
`:NoteFind`	`<leader>np`	Fuzzy-find notes in the current project
`:NoteFindAll`	`<leader>na`	Fuzzy-find notes across all projects
`:NoteRecent`	`<leader>nr`	Browse recently opened notes
`:NoteBrowse`	`<leader>nb`	Open project notes folder in your file browser
`:NoteGrep`	`<leader>ng`	Live-grep inside the current project's notes
`:NoteGrepAll`	`<leader>nG`	Live-grep across all notes
`:NoteFindByTag`	—	Pick a tag and jump to matching notes
`:NoteFromSelection`	`<leader>ns`	Create a note from a visual selection
`:NoteRename [name]`	—	Rename the current note and rewrite all links

The feature I use most: Note from selection

This is the workflow killer that made me build the plugin in the first place.

You're reading through code — maybe debugging, maybe doing a review — and you land on a function you need to reason about later. Select it in visual mode, press <leader>ns, give the note a name, and you get this:

# Authenticate function

Created: 2026-04-26

Source: `src/auth.lua` lines 42–58

local function authenticate(user)
  local token = db.find_token(user.id)
  if not token or token.expires_at < os.time() then
    return nil, "token expired"
  end
  return token
end

Source file, line range, and filetype are all captured automatically. Your future self will know exactly where this came from.

Tag search

notes-nvim understands two tag formats so you don't have to pick one:

YAML frontmatter:

---
tags: [neovim, workflow, auth]
---

Inline hashtags:

Ran into a weird edge case with token refresh. #auth #debugging

:NoteFindByTag scans both formats and gives you a picker of all tags in the current project. :NoteFindByTagAll does the same globally.

Custom templates

New notes are created from a Lua template function, so you can inject whatever frontmatter or boilerplate you want:

require("notes-nvim").setup({
  template = function(ctx)
    return string.format([[
---
title: %s
project: %s
date: %s
tags: []
---

# %s

]], ctx.title, ctx.project, ctx.date, ctx.title)
  end,
})

The ctx table has title, filepath, project, and date — enough to build most templates.

snacks.dashboard integration

If you use snacks.nvim, you can show recent notes right on your startup screen:

require("snacks").setup({
  dashboard = {
    sections = {
      { section = "header" },
      { section = "keys" },
      require("notes-nvim.dashboard").snacks_section({
        limit = 5,
        title = "Recent Notes",
      }),
      { section = "startup" },
    },
  },
})

What I want to build next — and where I'd love input

This is where you come in. notes-nvim is at v1.0 and the core workflow is solid, but there's a lot of room to grow. The biggest direction I'm focused on next:

Deeper Obsidian compatibility — [[wikilink]] resolution and navigation, alias support from frontmatter, embed (![[file]]) handling, and other vault-native features. The goal is for notes-nvim to be a first-class Obsidian companion inside Neovim, not just a markdown reader.

A few other things on the list:

Templates per project — different boilerplate for different project types (e.g., a meeting note template for work projects, a learning note for side projects)
Note linking / backlinks — jump to all notes that link to the current one
Inline preview — float a preview of a linked note on hover
Export — push a note or a project's notes to a markdown directory ready for a static site
Git integration — auto-commit notes directory on save, or show a diff of today's notes
Note archiving — move old notes to an archive without breaking links

If you use both Obsidian and Neovim, I'd especially love to hear what's missing for you. Which Obsidian features do you reach for most that you'd want inside Neovim? And for Neovim users without an Obsidian vault — what does your current note setup look like, and what's the one thing that still makes you reach for an external app?

Drop a comment below — I read all of them and a good chunk of the features above came from conversations with other Neovim users.

Switch Your Samsung M8 Monitor HDMI Inputs from the Terminal (No Remote Needed)

Abhishek Sharma — Fri, 17 Apr 2026 05:28:05 +0000

If you run two machines — a work laptop and a personal desktop — connected to a Samsung M8, you already know the pain: reach for the remote, navigate the OSD menu, switch source, repeat twenty times a day. Here's how to collapse that into a single terminal command using the SmartThings CLI.

The best part: this approach works identically on both macOS and Linux since it's Node.js-based.

How This Works

The Samsung M8 is a SmartThings-connected display. Samsung exposes a first-party CLI — @smartthings/cli — that can send commands to any registered SmartThings device, including input source switching on the M8. No hacking, no reverse engineering, no X11 tools.

What You Need

Samsung M8 monitor connected to your SmartThings account
Node.js (we'll use asdf for version management)
SmartThings CLI installed globally via npm
Your M8's SmartThings device ID

Step 1: Install Node.js via asdf

asdf works the same on macOS and Linux, which is why it's the cleanest approach here.

macOS:

brew install asdf

Linux (Ubuntu/Debian):

sudo apt install curl git
git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.14.0
echo '. "$HOME/.asdf/asdf.sh"' >> ~/.zshrc
source ~/.zshrc

Then install Node.js:

asdf plugin add nodejs
asdf install nodejs 24.13.0
asdf global nodejs 24.13.0

Verify:

node --version   # v24.13.0

Step 2: Install the SmartThings CLI

npm install -g @smartthings/cli

Verify:

smartthings --version

Step 3: Authenticate with SmartThings

smartthings devices

This will open a browser and ask you to log in with your Samsung account. After authentication, it lists all your SmartThings devices.

Step 4: Find Your M8 Device ID

After authentication, smartthings devices outputs a table. Find your Samsung M8 and copy its device ID — it looks like a UUID:

┌────┬─────────────────┬──────────────────────────────────────┐
│ #  │ Label           │ Device ID                            │
├────┼─────────────────┼──────────────────────────────────────┤
│  1 │ Samsung M8      │ xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx │
└────┴─────────────────┴──────────────────────────────────────┘

Export it in your ~/.zshrc.local (keep it out of your dotfiles repo since it's device-specific):

export SMARTTHINGS_MONITOR_ID='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'

Step 5: The Toggle Script

Create ~/dotfiles/scripts/monitor_input.sh:

#!/usr/bin/env bash
# Control Samsung M8 monitor input via SmartThings CLI
# Requires: smartthings CLI + SMARTTHINGS_MONITOR_ID env var set in ~/.zshrc.local

_smartthings_cmd() {
  local st_bin="$HOME/.asdf/installs/nodejs/24.13.0/bin/smartthings"
  if [[ -x "$st_bin" ]]; then
    "$st_bin" "$@"
  else
    command smartthings "$@"
  fi
}

_monitor_check() {
  if ! _smartthings_cmd --version &>/dev/null; then
    echo "smartthings CLI not found." >&2
    echo "Run: npm install -g @smartthings/cli" >&2
    return 1
  fi
  if [[ -z "$SMARTTHINGS_MONITOR_ID" ]]; then
    echo "SMARTTHINGS_MONITOR_ID is not set." >&2
    echo "Run: smartthings devices   → find your M8 device ID" >&2
    echo "Then add to ~/.zshrc.local:  export SMARTTHINGS_MONITOR_ID='<id>'" >&2
    return 1
  fi
}

monitor_hdmi1() {
  _monitor_check || return 1
  echo "Switching to HDMI 1..."
  _smartthings_cmd devices:commands "$SMARTTHINGS_MONITOR_ID" \
    'main:mediaInputSource:setInputSource("HDMI1")'
}

monitor_hdmi2() {
  _monitor_check || return 1
  echo "Switching to HDMI 2..."
  _smartthings_cmd devices:commands "$SMARTTHINGS_MONITOR_ID" \
    'main:mediaInputSource:setInputSource("HDMI2")'
}

monitor_toggle() {
  _monitor_check || return 1
  local current
  current=$(_smartthings_cmd devices:status "$SMARTTHINGS_MONITOR_ID" 2>/dev/null \
    | jq -r '.components.main."samsungvd.mediaInputSource".inputSource.value // empty')

  if [[ -z "$current" ]]; then
    echo "Could not read current input source." >&2
    return 1
  fi

  echo "Current input: $current"
  if [[ "$current" == "HDMI1" ]]; then
    monitor_hdmi2
  else
    monitor_hdmi1
  fi
}

# Allow running directly: ./monitor_input.sh [hdmi1|hdmi2|toggle]
case "${1:-}" in
  hdmi1)  monitor_hdmi1 ;;
  hdmi2)  monitor_hdmi2 ;;
  toggle) monitor_toggle ;;
  *)
    echo "Usage: $0 [hdmi1|hdmi2|toggle]"
    echo "  or source this file and call monitor_hdmi1 / monitor_hdmi2 / monitor_toggle"
    ;;
esac

A couple of things worth noting in _smartthings_cmd: it tries the asdf-managed binary path first, then falls back to whatever smartthings is on $PATH. This means the script works whether you're using asdf or a global npm install.

Step 6: Wire Up the Aliases

Create ~/dotfiles/zsh/aliases/monitor.sh:

# ── Samsung M8 Monitor Input (SmartThings) ──────────────────────────────────

if command -v smartthings &>/dev/null; then
  source "$HOME/dotfiles/scripts/monitor_input.sh" 2>/dev/null

  alias hdmi1='monitor_hdmi1'
  alias hdmi2='monitor_hdmi2'
  alias hdmi-toggle='monitor_toggle'
  alias t='monitor_toggle'
fi

Source it from your .zshrc:

source "$HOME/dotfiles/zsh/aliases/monitor.sh"

The command -v smartthings guard means the aliases are silently skipped on any machine that doesn't have the CLI installed — no errors, no noise.

Usage

hdmi1         # switch to HDMI 1 (machine A)
hdmi2         # switch to HDMI 2 (machine B)
hdmi-toggle   # toggle between whichever is active
t             # same as hdmi-toggle, just shorter

Run it directly without sourcing:

~/dotfiles/scripts/monitor_input.sh toggle
~/dotfiles/scripts/monitor_input.sh hdmi1

Workflow in Practice

My setup: work MacBook on HDMI 1, personal Linux desktop on HDMI 2. A single t in the terminal and the monitor switches — no remote, no OSD, no context switch. Since it goes through SmartThings rather than DDC/CI, it works over the network too, so you don't even need to be in the same session as the machine you're switching away from.

Troubleshooting

smartthings CLI not found — Make sure the npm global bin is on your $PATH. Check with npm bin -g and add it to your shell profile if missing.

SMARTTHINGS_MONITOR_ID is not set — Add the export to ~/.zshrc.local (not your dotfiles repo) and re-source your shell.

Could not read current input source — Run smartthings devices:status $SMARTTHINGS_MONITOR_ID manually to inspect the raw JSON. The capability key may differ slightly on older M8 firmware; look for mediaInputSource in the output.

Commands time out — The M8 needs to be on and connected to your Wi-Fi network. Wake it from standby first, or disable deep sleep in the monitor's power settings.

That's it. SmartThings CLI, one script, four aliases, zero remote-reaching.

Full script and aliases live in my dotfiles: github.com/abhsss96/dotfiles — see scripts/monitor_input.sh and zsh/aliases/monitor.sh.

Switch Your Samsung M8 Monitor Inputs from the Terminal (No Remote Needed)

Abhishek Sharma — Fri, 17 Apr 2026 05:22:37 +0000

The best part: this approach works identically on both macOS and Linux since it's Node.js-based.

How This Works

What You Need

Samsung M8 monitor connected to your SmartThings account
Node.js (we'll use asdf for version management)
SmartThings CLI installed globally via npm
Your M8's SmartThings device ID

Step 1: Install Node.js via asdf

asdf works the same on macOS and Linux, which is why it's the cleanest approach here.

macOS:

brew install asdf

Linux (Ubuntu/Debian):

sudo apt install curl git
git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.14.0
echo '. "$HOME/.asdf/asdf.sh"' >> ~/.zshrc
source ~/.zshrc

Then install Node.js:

asdf plugin add nodejs
asdf install nodejs 24.13.0
asdf global nodejs 24.13.0

Verify:

node --version   # v24.13.0

Step 2: Install the SmartThings CLI

npm install -g @smartthings/cli

Verify:

smartthings --version

Step 3: Authenticate with SmartThings

smartthings devices

This will open a browser and ask you to log in with your Samsung account. After authentication, it lists all your SmartThings devices.

Step 4: Find Your M8 Device ID

After authentication, smartthings devices outputs a table. Find your Samsung M8 and copy its device ID — it looks like a UUID:

┌────┬─────────────────┬──────────────────────────────────────┐
│ #  │ Label           │ Device ID                            │
├────┼─────────────────┼──────────────────────────────────────┤
│  1 │ Samsung M8      │ xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx │
└────┴─────────────────┴──────────────────────────────────────┘

Export it in your ~/.zshrc.local (keep it out of your dotfiles repo since it's device-specific):

export SMARTTHINGS_MONITOR_ID='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'

Step 5: The Toggle Script

Create ~/dotfiles/scripts/monitor_input.sh:

#!/usr/bin/env bash
# Control Samsung M8 monitor input via SmartThings CLI
# Requires: smartthings CLI + SMARTTHINGS_MONITOR_ID env var set in ~/.zshrc.local

_smartthings_cmd() {
  local st_bin="$HOME/.asdf/installs/nodejs/24.13.0/bin/smartthings"
  if [[ -x "$st_bin" ]]; then
    "$st_bin" "$@"
  else
    command smartthings "$@"
  fi
}

_monitor_check() {
  if ! _smartthings_cmd --version &>/dev/null; then
    echo "smartthings CLI not found." >&2
    echo "Run: npm install -g @smartthings/cli" >&2
    return 1
  fi
  if [[ -z "$SMARTTHINGS_MONITOR_ID" ]]; then
    echo "SMARTTHINGS_MONITOR_ID is not set." >&2
    echo "Run: smartthings devices   → find your M8 device ID" >&2
    echo "Then add to ~/.zshrc.local:  export SMARTTHINGS_MONITOR_ID='<id>'" >&2
    return 1
  fi
}

monitor_hdmi1() {
  _monitor_check || return 1
  echo "Switching to HDMI 1..."
  _smartthings_cmd devices:commands "$SMARTTHINGS_MONITOR_ID" \
    'main:mediaInputSource:setInputSource("HDMI1")'
}

monitor_hdmi2() {
  _monitor_check || return 1
  echo "Switching to HDMI 2..."
  _smartthings_cmd devices:commands "$SMARTTHINGS_MONITOR_ID" \
    'main:mediaInputSource:setInputSource("HDMI2")'
}

monitor_toggle() {
  _monitor_check || return 1
  local current
  current=$(_smartthings_cmd devices:status "$SMARTTHINGS_MONITOR_ID" 2>/dev/null \
    | jq -r '.components.main."samsungvd.mediaInputSource".inputSource.value // empty')

  if [[ -z "$current" ]]; then
    echo "Could not read current input source." >&2
    return 1
  fi

  echo "Current input: $current"
  if [[ "$current" == "HDMI1" ]]; then
    monitor_hdmi2
  else
    monitor_hdmi1
  fi
}

# Allow running directly: ./monitor_input.sh [hdmi1|hdmi2|toggle]
case "${1:-}" in
  hdmi1)  monitor_hdmi1 ;;
  hdmi2)  monitor_hdmi2 ;;
  toggle) monitor_toggle ;;
  *)
    echo "Usage: $0 [hdmi1|hdmi2|toggle]"
    echo "  or source this file and call monitor_hdmi1 / monitor_hdmi2 / monitor_toggle"
    ;;
esac

Step 6: Wire Up the Aliases

Create ~/dotfiles/zsh/aliases/monitor.sh:

# ── Samsung M8 Monitor Input (SmartThings) ──────────────────────────────────

if command -v smartthings &>/dev/null; then
  source "$HOME/dotfiles/scripts/monitor_input.sh" 2>/dev/null

  alias hdmi1='monitor_hdmi1'
  alias hdmi2='monitor_hdmi2'
  alias hdmi-toggle='monitor_toggle'
  alias t='monitor_toggle'
fi

Source it from your .zshrc:

source "$HOME/dotfiles/zsh/aliases/monitor.sh"

The command -v smartthings guard means the aliases are silently skipped on any machine that doesn't have the CLI installed — no errors, no noise.

Usage

hdmi1         # switch to HDMI 1 (machine A)
hdmi2         # switch to HDMI 2 (machine B)
hdmi-toggle   # toggle between whichever is active
t             # same as hdmi-toggle, just shorter

Run it directly without sourcing:

~/dotfiles/scripts/monitor_input.sh toggle
~/dotfiles/scripts/monitor_input.sh hdmi1

Workflow in Practice

Troubleshooting

smartthings CLI not found — Make sure the npm global bin is on your $PATH. Check with npm bin -g and add it to your shell profile if missing.

SMARTTHINGS_MONITOR_ID is not set — Add the export to ~/.zshrc.local (not your dotfiles repo) and re-source your shell.

Commands time out — The M8 needs to be on and connected to your Wi-Fi network. Wake it from standby first, or disable deep sleep in the monitor's power settings.

That's it. SmartThings CLI, one script, four aliases, zero remote-reaching.

Full script and aliases live in my dotfiles: github.com/abhsss96/dotfiles — see scripts/monitor_input.sh and zsh/aliases/monitor.sh.

DEV Community: Abhishek Sharma

Phoenix LiveView vs Rails Hotwire: I Built the Same Real-Time App in Both. The Numbers Aren't Close.

Phoenix LiveView vs Rails Hotwire: I Built the Same Real-Time App in Both. The Numbers Aren't Close

Why I Did This

What I Built

The Architecture Gap

Phoenix: One socket, one process, zero JS

Rails: Two sockets, HTTP round-trips, ~200 lines of JS

The Benchmark Setup

The Numbers

HTTP Throughput

WebSocket Flood: 500 Persistent Connections

The Rails WebSocket Journey

The Code Cost

So Who Wins?

Phoenix wins if you're building real-time

Rails wins if you're building everything else

The honest verdict

What I'd Do Differently

Stack Details

abhsss96 / same-same-but-different

Same UX. Same features. Different stacks. Phoenix LiveView vs Rails Hotwire, head to head.

Phoenix LiveView vs Rails Hotwire

Architecture

Zero-Downtime PostgreSQL Major Version Upgrades in Containers: The Problem Nobody Talks About

Why Containerized PostgreSQL in the First Place?

The Problem: Major Version Upgrades Are Not Like Container Restarts

What Teams Actually Do (And Why It Hurts)

Option 1: pg_dumpall / pg_dump + Restore

Option 2: Logical Replication with pglogical or Built-in Slots

Option 3: Snapshot + Restore on a New Node

Option 4: Manual pg_upgrade Inside a Container

How pg-upgrade Solves This

The Three-Step Pipeline

Downtime Comparison

What the Upgrade Output Looks Like

No Credentials Required

CI-Validated Upgrade Paths

Kubernetes Ready, No Changes Required

Quick Start

When to Use What

Want to Contribute?

Conclusion

Use your Obsidian vault from Neovim, organized by project

The core idea

Using it with your existing Obsidian vault

Features at a glance

Installation

Commands and keymaps

The feature I use most: Note from selection

Tag search

Custom templates

snacks.dashboard integration

What I want to build next — and where I'd love input

Links

Switch Your Samsung M8 Monitor HDMI Inputs from the Terminal (No Remote Needed)

How This Works

What You Need

Step 1: Install Node.js via asdf

Step 2: Install the SmartThings CLI

Step 3: Authenticate with SmartThings

Step 4: Find Your M8 Device ID

Step 5: The Toggle Script

Step 6: Wire Up the Aliases

Usage

Workflow in Practice

Troubleshooting

Switch Your Samsung M8 Monitor Inputs from the Terminal (No Remote Needed)

How This Works

What You Need

Step 1: Install Node.js via asdf

Step 2: Install the SmartThings CLI

Step 3: Authenticate with SmartThings

Step 4: Find Your M8 Device ID

Step 5: The Toggle Script

Step 6: Wire Up the Aliases

Usage

Workflow in Practice

Troubleshooting

Option 1: `pg_dumpall` / `pg_dump` + Restore

Option 2: Logical Replication with `pglogical` or Built-in Slots

Option 4: Manual `pg_upgrade` Inside a Container

How `pg-upgrade` Solves This