DEV Community: Shahid

The Most Overlooked Part in Docker Compose

Shahid — Tue, 11 Aug 2026 07:35:52 +0000

A Docker container can be running while the application inside it is completely unavailable. This is one of the most common misunderstandings in Docker Compose.

The container process may still exist, but the web server may not have started, the database may still be initializing, or the application may be unable to respond to requests. That is why a Compose file should define a meaningful healthcheck, not just a restart policy.

A health check executes a command inside the container. If that command returns exit code 0, Docker marks the container as healthy; any non-zero exit code indicates failure.

Running Is Not Ready

Consider this simple Compose file:

services:
  app:
    image: my-app:latest
    ports:
      - "3000:3000"
    restart: unless-stopped

Docker may report the container as running immediately after the process starts. That does not necessarily mean the application is ready to receive traffic.

The application might still be:

Loading configuration.
Running database migrations.
Compiling an extension.
Waiting for PostgreSQL.
Starting an HTTP server.
Connecting to an external service.

Without a health check, Docker has no reliable way to distinguish “the process exists” from “the application works.”

Basic Health Check

A health check can test the application’s HTTP endpoint:

services:
  app:
    image: my-app:latest
    ports:
      - "3000:3000"
    healthcheck:
      test:
        [
          "CMD",
          "curl",
          "--fail",
          "--silent",
          "--show-error",
          "http://127.0.0.1:3000/"
        ]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 60s

The command runs inside the container. Therefore, the check must use the container port, 3000, rather than necessarily using the host port mapping.

The start_period gives the application time to start before failures count against it. The interval controls how often Docker checks the service, timeout limits how long an individual check may run, and retries controls how many consecutive failures are allowed.

Choose the Right Option

The most overlooked detail is that the health-check command must exist inside the image. Minimal images often do not contain curl, wget, Bash, or network tools. A health check can be perfectly written and still fail because its executable is missing.

Option 1: curl

If the image contains curl:

healthcheck:
  test:
    [
      "CMD",
      "curl",
      "--fail",
      "--silent",
      "--show-error",
      "http://127.0.0.1:3000/"
    ]
  interval: 30s
  timeout: 10s
  retries: 5
  start_period: 60s

For a Debian-based image such as node:20-slim, install it in the Dockerfile:

FROM node:20-slim

RUN apt-get update \
    && apt-get install -y --no-install-recommends curl \
    && rm -rf /var/lib/apt/lists/*

Slim images intentionally contain fewer utilities, so installing curl explicitly is expected. github

Option 2: Node.js

For a Node application, Node itself can perform the check without installing another package:

healthcheck:
  test:
    [
      "CMD",
      "node",
      "-e",
      "require('http').get('http://127.0.0.1:3000/',r=>process.exit(r.statusCode>=200&&r.statusCode<400?0:1)).on('error',()=>process.exit(1))"
    ]
  interval: 30s
  timeout: 10s
  retries: 5
  start_period: 60s

This is a useful option for node:20-slim, especially when the only purpose of curl would be the health check.

Option 3: wget

If the image already includes wget, use:

healthcheck:
  test:
    [
      "CMD",
      "wget",
      "--quiet",
      "--tries=1",
      "--spider",
      "http://127.0.0.1:3000/"
    ]
  interval: 30s
  timeout: 10s
  retries: 5
  start_period: 60s

Always test the command manually before relying on it:

docker exec <container-name> \
  wget --quiet --tries=1 --spider http://127.0.0.1:3000/

Option 4: PostgreSQL

A database should have its own health check:

services:
  database:
    image: postgres:16
    environment:
      POSTGRES_DB: my-app-db
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: change-this-password
    healthcheck:
      test:
        [
          "CMD-SHELL",
          "pg_isready -U postgres -d my-app-db"
        ]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 20s

pg_isready is included in the PostgreSQL image, so no additional package is required.

Startup Order Matters

A health check becomes more useful when combined with a health-based dependency:

services:
  app:
    build: .
    depends_on:
      database:
        condition: service_healthy
    healthcheck:
      test:
        [
          "CMD",
          "node",
          "-e",
          "require('http').get('http://127.0.0.1:3000/',r=>process.exit(r.statusCode>=200&&r.statusCode<400?0:1)).on('error',()=>process.exit(1))"
        ]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 60s

  database:
    image: postgres:16
    healthcheck:
      test:
        [
          "CMD-SHELL",
          "pg_isready -U postgres -d my-app-db"
        ]
      interval: 10s
      timeout: 5s
      retries: 5

With condition: service_healthy, Compose waits for the database health check to pass before starting the application. last9

For an my-app-db deployment, the application health check can test port 3000:

environment:
  HOST: 0.0.0.0
  PORT: 3000

The health check should use:

http://127.0.0.1:3000/

not:

http://127.0.0.1/

unless the application actually listens on port 80.

Test Before You Trust It

A health check should be tested manually inside the container. For the Node-based check:

docker exec <container-name> \
node -e "require('http').get('http://127.0.0.1:3000/',r=>{console.log('HTTP',r.statusCode);process.exit(r.statusCode>=200&&r.statusCode<400?0:1)}).on('error',e=>{console.error(e.message);process.exit(1)})"

A successful result might be:

HTTP 200

Then inspect the health status:

docker compose ps

For detailed results:

docker inspect <container-name> \
  | jq '.[0].State.Health'

The health state normally moves through:

starting → healthy

If checks continue to fail, Docker eventually reports:

unhealthy

The inspection output includes the failing command and its output, which often reveals simple problems such as:

curl: executable file not found

Health Checks Do Not Restart Containers

A health check reports the state of a container. It does not automatically restart a container merely because it becomes unhealthy. forums.docker

Use a restart policy for processes that exit:

restart: unless-stopped

But treat health status and restart behavior as separate concerns:

healthcheck answers: “Is the application responding correctly?”
restart answers: “What should Docker do if the container process exits?”
depends_on answers: “Should another service wait for this dependency?”
Monitoring answers: “Who should be alerted when the service is unhealthy?”

This distinction is why health checks are easy to overlook but important to design properly.

Final Compose Example

services:
  app:
    build:
      context: .
    container_name: my-app
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      HOST: 0.0.0.0
      PORT: 3000
      DB_HOST: database
      DB_PORT: 5432
      DB_NAME: myapp
      DB_USER: postgres
      DB_PASSWORD: change-this-password
    depends_on:
      database:
        condition: service_healthy
    healthcheck:
      test:
        [
          "CMD",
          "node",
          "-e",
          "require('http').get('http://127.0.0.1:3000/',r=>process.exit(r.statusCode>=200&&r.statusCode<400?0:1)).on('error',()=>process.exit(1))"
        ]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 60s

  database:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: myapp
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: change-this-password
    healthcheck:
      test:
        [
          "CMD-SHELL",
          "pg_isready -U postgres -d myapp"
        ]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 20s

volumes:
  postgres-data:

The best health check is not the most complicated one. It is the smallest command that verifies the condition users actually need: that the service is ready to do its job.

PostgreSQL psql Backslash Commands: A Practical Guide

Shahid — Sun, 09 Aug 2026 05:41:11 +0000

When working with PostgreSQL from the terminal, psql provides special commands that begin with a backslash, such as \l, \dt, and \d. These are called meta-commands or backslash commands; they are processed by the psql client rather than sent to the PostgreSQL server as SQL. postgresql

This guide explains the most useful commands for viewing databases, tables, schemas, users, permissions, query results, and configuration.

Getting started

Connect to PostgreSQL from your terminal:

psql -U postgres -d postgres -h localhost -p 5432

Where:

-U postgres specifies the PostgreSQL user.
-d postgres specifies the database.
-h localhost specifies the server host.
-p 5432 specifies the port.

On Linux, you may also connect as the operating-system postgres user:

sudo -u postgres psql

A successful connection displays a prompt similar to:

postgres=#

The prompt changes when you connect to another database:

myapp_db=#

Help and exiting

Show all `psql` commands

\?

This displays the complete list of available psql meta-commands.

You can also display help for a category:

\? commands
\? options
\? variables

Get help for SQL commands

\h

Show the syntax for a specific SQL command:

\h CREATE TABLE
\h ALTER USER
\h GRANT

Exit `psql`

\q

You can also press Ctrl+D on Linux and macOS.

Databases and connections

List all databases

\l

Example output:

   Name    |  Owner   | Encoding | Collate |  Ctype  | Access privileges
-----------+----------+----------+---------+---------+-------------------
 myapp_db  | postgres | UTF8     | C.UTF-8 | C.UTF-8 |
 postgres  | postgres | UTF8     | C.UTF-8 | C.UTF-8 |

Show additional information such as database size:

\l+

Connect to another database

\c myapp_db

You can specify both a database and a user:

\c myapp_db app_user

For a remote database:

\c myapp_db app_user db.example.com 5432

Show the current connection

\conninfo

Example:

You are connected to database "myapp_db" as user "app_user" on host "localhost" at port "5432".

Show or change client encoding

\encoding

Set UTF-8 encoding:

\encoding UTF8

Schemas and tables

List schemas

\dn

Show schemas with descriptions and access privileges:

\dn+

List tables

\dt

This lists tables visible through the current search_path.

List tables in all schemas:

\dt *.*

List tables in a particular schema:

\dt myapp.*

Show extra information, such as table size:

\dt+

Describe a table

\d users

This usually shows:

Column names.
Data types.
Nullable status.
Default values.
Indexes.
Primary keys.
Foreign keys.
Constraints.

For a table in a specific schema:

\d myapp.users

Show more detailed information:

\d+ myapp.users

Example output:

                                      Table "myapp.users"
 Column |           Type           | Collation | Nullable |              Default
--------+--------------------------+-----------+----------+-----------------------------------
 id     | bigint                   |           | not null | generated by default as identity
 email  | text                     |           | not null |
 name   | text                     |           |          |
Indexes:
    "users_pkey" PRIMARY KEY, btree (id)
    "users_email_key" UNIQUE CONSTRAINT, btree (email)

List all relations

\d

This can show tables, views, sequences, and other relation-like objects.

Views, indexes, sequences, and functions

List views

\dv
\dv+

Describe a view:

\d myapp.active_users

Show the SQL definition of a view:

\sv myapp.active_users

List materialized views

\dm
\dm+

List indexes

\di
\di+

Describe indexes for a table:

\d myapp.users

List sequences

\ds
\ds+

List functions

\df
\df+

List functions matching a pattern:

\df *email*

Describe a particular function:

\df myapp.calculate_total

Users, roles, and permissions

List users and roles

\du

Show additional role information:

\du+

Example output:

 Role name  | Attributes | Member of
------------+------------+-----------
 app_user   |            | {}
 postgres   | Superuser  | {}

Show table privileges

\dp

You can also use:

\z

Show privileges for a specific table:

\dp myapp.users

Example:

                              Access privileges
 Schema | Name  | Type  | Access privileges
--------+-------+-------+-------------------
 myapp  | users | table | app_user=arwdDxt/app_owner

The privilege letters generally represent:

r: SELECT
a: INSERT
w: UPDATE
d: DELETE
D: TRUNCATE
x: REFERENCES
t: TRIGGER

Show object descriptions

\dd

Show the description of a specific object:

\dd myapp.users

Viewing table data

Backslash commands show metadata. To view actual rows, use SQL.

Display all rows:

SELECT * FROM myapp.users;

Display selected columns:

SELECT id, email, name
FROM myapp.users;

Limit the result:

SELECT *
FROM myapp.users
LIMIT 10;

Sort the result:

SELECT id, email, created_at
FROM myapp.users
ORDER BY created_at DESC
LIMIT 10;

Count rows:

SELECT COUNT(*)
FROM myapp.users;

The SQL statement must end with a semicolon:

SELECT * FROM myapp.users;

A psql meta-command such as \dt normally does not require a semicolon:

\dt

Improving query output

Toggle expanded output

Normal output is displayed horizontally:

SELECT * FROM myapp.users LIMIT 1;

For wide rows, use expanded output:

\x
SELECT * FROM myapp.users LIMIT 1;

Toggle it back:

\x

You can let psql decide automatically:

\x auto

Show query execution time

\timing on

Now each query displays its execution time.

Disable it with:

\timing off

Show only rows without headers

\t

Run a query:

SELECT email FROM myapp.users;

Toggle tuple-only output off:

\t

Change the output format

Use expanded output:

\x on

Use unaligned output, which is useful for scripts:

\a

Set a particular output format:

\pset format aligned
\pset format unaligned
\pset format csv

Set a display value for NULL:

\pset null '(none)'

Running SQL files

Execute a SQL file

\i /path/to/schema.sql

Example:

\i /home/admin/migrations/001_create_users.sql

For a file relative to the current script:

\ir migrations/001_create_users.sql

This is useful for running database setup scripts and migrations.

Redirect output to a file

\o query_output.txt
SELECT * FROM myapp.users;
\o

The first \o starts writing output to the file. The second \o returns output to the terminal.

Export data with `\copy`

Export a query result to CSV:

\copy (
  SELECT id, email, name
  FROM myapp.users
) TO '/tmp/users.csv' WITH CSV HEADER

Import CSV data into a table:

\copy myapp.users(email, name)
FROM '/tmp/users.csv'
WITH CSV HEADER

\copy reads and writes files on the machine running the psql client, which is different from server-side SQL COPY.

Query history and editing

Show command history

\history

You can also use:

\s

Save history to a file:

\s /tmp/psql-history.txt

Clear the current query buffer

\r

This is useful if you started writing a SQL command but no longer want to execute it.

Edit the current query

\e

This opens the current query buffer in your configured text editor.

You can set an editor before launching psql:

export EDITOR=nano
psql -U postgres -d myapp_db

Execute the query buffer

\g

This runs the SQL currently stored in the query buffer.

Shell and file-system commands

Run an operating-system command

On Linux or macOS:

\! pwd
\! ls

On Windows:

\! cd
\! dir

Change the client working directory

\cd /tmp

Check the current client working directory:

\! pwd

This affects local file commands such as \i and \copy.

Variables and prompts

List `psql` variables

\set

Set a variable:

\set environment 'development'

Display it:

\echo :environment

Unset it:

\unset environment

Variables can be used in SQL:

\set user_id 10

SELECT *
FROM myapp.users
WHERE id = :user_id;

For string values, quote the value appropriately:

\set email '''alice@example.com'''

SELECT *
FROM myapp.users
WHERE email = :email;

For application scripts, use parameterized queries rather than manually constructing SQL strings.

Automatic query execution

Repeat a query

Run a query every five seconds:

SELECT COUNT(*) FROM myapp.users
\watch 5

Stop the repeating query with:

Ctrl+C

Execute query output as SQL

SELECT 'CREATE TABLE test(id integer);'
\gexec

\gexec executes each value returned by the query as SQL. Use it carefully, especially in production.

A complete inspection workflow

The following sequence is useful when investigating a database:

-- Show the current connection
\conninfo

-- List all databases
\l

-- Connect to the application database
\c myapp_db

-- List schemas
\dn+

-- List tables in the application schema
\dt myapp.*

-- Describe a table
\d+ myapp.users

-- List views
\dv myapp.*

-- List indexes
\di myapp.*

-- List sequences
\ds myapp.*

-- List users and roles
\du+

-- Show table privileges
\dp myapp.users

-- Show query execution time
\timing on

-- Inspect some rows
SELECT *
FROM myapp.users
LIMIT 10;

Common mistakes

Using a backslash command outside `psql`

This will not work directly in a normal shell:

\dt

Start psql first:

psql -U app_user -d myapp_db

Then run:

\dt

Adding a semicolon incorrectly

Use:

\dt

Not:

\dt;

SQL commands, however, require a semicolon:

SELECT * FROM myapp.users;

Expecting tables from another database

Tables belong to a specific database. First connect to the correct database:

\c myapp_db
\dt

Not seeing a table

The table may be in another schema. Try:

\dt *.*

Or describe it with its full name:

\d myapp.users

You may also lack the privileges required to see or access it.

Quick reference

Command	Purpose	Example
`\l`	List databases	`\l`
`\c`	Connect to a database	`\c myapp_db`
`\conninfo`	Show connection details	`\conninfo`
`\dn`	List schemas	`\dn`
`\dt`	List tables	`\dt myapp.*`
`\d`	Describe an object	`\d myapp.users`
`\dv`	List views	`\dv`
`\di`	List indexes	`\di`
`\ds`	List sequences	`\ds`
`\df`	List functions	`\df`
`\du`	List users and roles	`\du`
`\dp` or `\z`	Show privileges	`\dp myapp.users`
`\x`	Toggle expanded output	`\x auto`
`\timing`	Toggle query timing	`\timing on`
`\i`	Execute a SQL file	`\i setup.sql`
`\copy`	Import or export CSV	`\copy users TO 'users.csv' CSV`
`\e`	Edit the query buffer	`\e`
`\r`	Clear the query buffer	`\r`
`\?`	Show `psql` help	`\?`
`\h`	Show SQL help	`\h CREATE TABLE`
`\q`	Exit `psql`	`\q`

The most important commands to remember are:

\l
\c database_name
\dn
\dt
\d table_name
\du
\dp
\conninfo
\?
\q

For the authoritative and version-specific list, run \? inside psql; available commands can vary slightly between PostgreSQL client versions. postgresql

Transfer files between devices with light — zero network, zero pairing, 100% offline.

Shahid — Sun, 02 Aug 2026 11:04:38 +0000

Transfer files between devices with light — zero network, zero pairing, 100% offline.

a Progressive Web App that moves files and text snippets from one screen to another device's camera using fountain-coded animated QR codes.
Live at App — open it on both devices and
go. Works offline after the first visit.

Why it's useful:

Air-gapped & offline: No Wi-Fi, Bluetooth, local LAN path, cloud storage, or account required.
Fountain-coded transmission: Uses Luby transform (soliton) fountain codes so the receiver can scan frames in any order. Dropping a frame never corrupts the transfer.
Any file or text: Automatically compresses compressible data with gzip and restores original filenames and bytes bit-exact (verified via SHA-256).
Zero-install PWA: Runs entirely in the browser. You can install it once and use it offline forever.
Open it on your laptop, point your phone camera at the screen, and transfer files with light. Send a file between two devices using nothing but a screen and a camera. One page displays the file as an endless stream of animated QR codes; another device points its camera at it and reconstructs the file. No network path between the devices, no app, no pairing, no permissions beyond the camera. The payload travels as light.

Live at App — open it on both devices and go. Works offline after the first visit.

This is a minimal proof of concept extracted from a larger experiment that reached 128 KB/s phone-to-phone with denser frames, multi-code grids, and an error-corrected color channel. This version accepts arbitrary files up to 64 MB, preserves their filename and media type inside the fountain stream, adaptively uses gzip only when it shrinks the optical payload, and verifies SHA-256 before offering the received file for download. The sender can also stream a pasted text snippet instead of a file; the receiver works out which one is arriving from the container's media type.

Phone receiving a 2 MB image over light: 129.2 KB/s goodput, decoding the sender's animated QR code

Mid-transfer: a phone pulling a 2 MB image out of the air at 129 KB/s.

Try it
App
The hosted site is live at App; everything below is for running it yourself.

Similar projects

I didn't come up with this on my own. It turns out a few different people have tackled this idea, and their perspectives are worth a look:

bashalarmistalt/decimen-optical-transfer: initial app and idea.
mohankumarelec/airgapped-qr-code-transfer: browser-based QR file transfer with compression and sequential chunking. Discovered after publicly demoing this project; convergent evolution in action.
divan/txqr (2018): animated QR plus fountain codes in Go, with two excellent write-ups on why fountain coding beats sequential looping.
sz3/libcimbar: goes past QR entirely with a custom high-density color code purpose-built for this channel.

Built with node-qrcode and
zxing-wasm.

Managing Git Remotes: Deleting, Updating, and Switching Origins

Shahid — Sun, 26 Jul 2026 09:04:28 +0000

Whether you've cloned a repo and need to point it at a different GitHub project, or you just want to clean up stray remote branches, Git gives you a few reliable commands to handle it. This post walks through the concepts and ends with a quick-reference cheat sheet you can bookmark.

Why You'd Change a Remote

The most common scenario is forking or migrating: you clone an existing repository, but your actual destination is a different GitHub repo—maybe your own fork, a renamed project, or a new organization. Rather than re-cloning from scratch, Git lets you simply repoint your local copy's origin remote, preserving all your commit history and local branches. stackoverflow

Checking Your Current Remote

Before changing anything, confirm what's currently set up:

git remote -v

This lists the remote name (usually origin) alongside its fetch and push URLs. It's good practice to run this both before and after any change to confirm the update took effect. docs.gitlab

Updating the Remote URL (Recommended Method)

The cleanest way to switch to a new GitHub repo is git remote set-url, which updates the existing origin in place without disturbing branch tracking or history: gist.github

git remote set-url origin <new-repo-url>

For example, switching to an HTTPS-based GitHub URL looks like git remote set-url origin https://github.com/OWNER/REPOSITORY.git, or for SSH, git@github.com:OWNER/REPOSITORY.git. Afterward, run git remote show origin to confirm the update and verify your local branches are correctly tracked to the new remote. docs.github

Removing and Re-adding the Remote (Alternative Method)

If you'd rather start clean, you can delete the remote entirely and add a new one under the same name:

git remote remove origin
git remote add origin <new-repo-url>

This achieves functionally the same result as set-url—it's mostly a matter of preference or troubleshooting stale configuration. Some teams prefer this approach when they want an explicit reset rather than an in-place edit. graphite

Handling Multiple Remotes

If you're managing more than one remote (e.g., origin and upstream for a fork), the same set-url pattern applies—just swap in the remote's name:

git remote set-url <remote_name> <new_url>

This is useful when you fork a repo, clone your fork, and also want an upstream remote pointing back to the original project you forked from. gitlab

Pushing After the Switch

Once your remote points to the new repo, push your code over:

git push -u origin main

If the new repo is empty, this works immediately. If it already has unrelated commit history, you may need git push origin --all or resolve merge conflicts with --allow-unrelated-histories first.

Deleting a Remote Branch

Separately, if you just want to remove a specific branch on the remote (not the whole remote itself), use:

git push origin --delete <branch-name>

Follow up with git fetch --prune to clean up any stale local references to the deleted branch.

Git Remote Cheatsheet

Task	Command
View current remotes	`git remote -v`
Update remote URL (in place)	`git remote set-url origin <new-url>`
Remove a remote	`git remote remove origin`
Add a new remote	`git remote add origin <new-url>`
Rename a remote	`git remote rename <old-name> <new-name>`
Verify remote + tracking	`git remote show origin`
Update URL for any named remote	`git remote set-url <remote_name> <new_url>`
Push local branch to new remote	`git push -u origin main`
Delete a remote branch	`git push origin --delete <branch-name>`
Prune stale remote-tracking refs	`git fetch --prune`
List all remote branches	`git branch -r`

Keep this table handy—git remote set-url covers 90% of "I need to point my repo somewhere else" situations, while remove + add is your fallback for a full reset.

PostgreSQL Extensions by Category: Real-World Use Cases for Modern Production Systems

Shahid — Sun, 12 Jul 2026 06:16:31 +0000

PostgreSQL is no longer just a relational database you spin up and forget. Its extension ecosystem lets teams turn one database into a search engine, geospatial engine, vector store, job scheduler, document database, and workflow runtime without introducing a separate platform too early. That flexibility is one of the main reasons PostgreSQL remains a default choice for modern SaaS, internal platforms, analytics systems, and AI-backed applications.

For engineering teams, extensions matter because they reduce architectural sprawl. Instead of adding Redis, Elasticsearch, MongoDB, Airflow, or a separate geospatial engine on day one, teams can often cover the first serious version of those workloads inside PostgreSQL and split them out later only when scale or specialization demands it.

This guide lists PostgreSQL extensions category-wise and pairs each one with a practical production use case. The goal is not just to name extensions, but to show where they fit in real systems and how they help solve actual application problems.

Why extensions matter

Extensions let PostgreSQL gain new data types, operators, functions, indexing methods, and runtime features without changing the core database engine. In practical terms, that means a team can keep transactional data, search features, background jobs, vectors, and even document-style data close together, which simplifies deployment, access control, backups, and operational debugging.

That does not mean PostgreSQL should replace every specialized system forever. It means PostgreSQL extensions give teams a powerful middle path: start with fewer moving parts, validate the product, and then decide later whether a dedicated system is still necessary.

How to enable extensions

Most PostgreSQL extensions are enabled with CREATE EXTENSION, and administrators can inspect what is available using pg_available_extensions. Managed platforms usually support only a subset, so the exact list depends on whether the database is self-hosted, running on a cloud-managed service, or offered through a platform with its own extension policy.

SELECT * FROM pg_available_extensions;

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS pgcrypto;

SELECT * FROM pg_extension;

A good rule is to enable only what the workload needs. Extensions add power, but they also become part of operational policy, version compatibility, backup planning, and schema management.

Observability and performance

pg_stat_statements

pg_stat_statements is one of the most widely installed PostgreSQL extensions because it records execution statistics for SQL statements and helps teams identify where time is actually going inside the database. It is especially useful when an application looks slow at the API layer but the real issue is a small set of high-cost SQL queries.

A real-world use case is an e-commerce checkout service where payment creation, cart refresh, coupon validation, and stock lookup all touch the database. With pg_stat_statements, the team can rank queries by total time, call count, or average latency and quickly identify whether the problem is a missing index, N+1 query pattern, or poor join path.

SELECT query, calls, total_time, mean_time
FROM pg_stat_statements
ORDER BY total_time DESC
LIMIT 10;

auto_explain

auto_explain is useful when slow queries appear only under real production traffic and are difficult to reproduce in development. It logs execution plans automatically, making it easier to understand why the planner chose a bad path for a query that only becomes problematic with production-sized data.

A practical use case is a B2B admin dashboard that is fast in staging but slow in production after data volume grows. auto_explain helps capture the exact execution plan at the moment the query becomes expensive, which is often more useful than manually running EXPLAIN later on a changed dataset.

hypopg

hypopg lets teams create hypothetical indexes to test whether a proposed index would help before paying the cost of building it on a large table. This is valuable when a table is large enough that creating the wrong index wastes both time and storage.

A good real-world example is an orders table with hundreds of millions of rows in a marketplace system. Before adding a composite index for merchant, status, and created date, the database team can simulate the index and inspect whether the planner would actually use it.

Search and text processing

pg_trgm

pg_trgm is one of the most practical extensions for application teams because it enables fuzzy string matching and typo-tolerant search by breaking text into trigrams. It is widely used for autocomplete, approximate matching, and user-facing search where exact text equality is too strict.

A real-time use case is product search in an online storefront. A customer typing “iphon”, “samsng”, or a slightly misspelled brand name can still get useful results, which improves conversion and reduces search abandonment.

SELECT *
FROM products
WHERE name % 'iphon'
ORDER BY similarity(name, 'iphon') DESC
LIMIT 10;

unaccent

unaccent removes accents and diacritics, which makes search more forgiving for multilingual applications and international catalogs. This is a small extension, but it often solves a very visible customer-experience problem.

A real-world example is a travel, education, or food platform where users search terms such as “Cafe”, “Creme Brulee”, or “Resume” even though the stored content contains accented forms. unaccent helps normalize the comparison and makes search behavior feel more natural.

citext

citext provides case-insensitive text behavior without forcing developers to wrap every comparison in LOWER(...). It is particularly useful for fields where humans treat different letter casing as the same value.

A practical production use case is user identity data. Email addresses, usernames, and tags often need case-insensitive uniqueness and lookups, and citext avoids subtle bugs where Alice@example.com and alice@example.com are treated differently in parts of the application.

hstore

hstore stores key-value pairs inside a column and remains useful for lightweight semi-structured attributes. While jsonb is more common today, hstore is still attractive when the data is simple, flat, and frequently queried by key.

A good use case is a product catalog with sparse attributes such as color, material, finish, or voltage that vary by SKU. Instead of creating dozens of mostly empty columns, a team can keep these attributes in hstore and query them when needed.

Geospatial and location data

PostGIS

PostGIS is the standard PostgreSQL extension for spatial data, spatial indexing, and location-aware queries. It adds types such as geometry and geography along with a large set of functions for distance, containment, area, routing support patterns, and shape operations.

Its real-world use cases are broad: store locator apps, delivery radius calculations, route-aware logistics, ride-hailing pickup matching, real estate search by map area, and warehouse service coverage analysis. For example, a food delivery platform can use PostGIS to find all active stores within a delivery radius of the customer and then filter them further by service status and estimated delivery time.

SELECT *
FROM locations
WHERE ST_DWithin(
  geom,
  ST_MakePoint(-122.4, 37.8)::geography,
  5000
);

Security, identity, and cryptography

pgcrypto

pgcrypto adds cryptographic functions directly inside PostgreSQL, including hashing, random value generation, and encryption-related helpers. It is commonly used in authentication systems, secure metadata handling, and cases where values must be generated or verified close to the data layer.

A real-world example is a SaaS application that stores password hashes, API verification tokens, or signed one-time secrets. Instead of sending sensitive values out of the database for all cryptographic operations, a team can perform key operations directly in SQL and reduce unnecessary data movement.

SELECT crypt('my_password', gen_salt('bf'));

uuid-ossp

uuid-ossp is widely used to generate UUID values inside PostgreSQL, especially for primary keys or externally visible identifiers. UUID-based identifiers are useful when sequential IDs would leak business volume or allow enumeration attacks.

A good use case is a marketplace API where order IDs, customer-facing shipment IDs, or public resource keys should not reveal insertion order. UUIDs make IDs harder to guess and easier to generate safely across distributed systems.

AI and vector search

pgvector

pgvector adds a vector data type and similarity search support, turning PostgreSQL into a practical vector store for many AI applications. It is commonly used for semantic search, retrieval-augmented generation, recommendation systems, duplicate detection, and embedding-based classification.

A production use case is a support knowledge assistant that stores article embeddings next to the relational article metadata. When a user asks a question, the system can retrieve semantically similar content from PostgreSQL without maintaining a separate vector database in the first version of the product.

SELECT id, embedding <#> '[0.1, 0.2, 0.3]' AS distance
FROM items
ORDER BY distance
LIMIT 5;

Another strong use case is product recommendation in commerce. Instead of relying only on category filters or co-purchase heuristics, embeddings can capture semantic similarity between products, user intent, and content descriptions, which improves discovery for long-tail inventory.

Scheduling and maintenance

pg_cron

pg_cron gives PostgreSQL a built-in scheduling mechanism for recurring SQL jobs, which is useful for automation tasks that belong close to the data. It helps teams avoid building an external scheduler for simple but essential database operations.

Real-world examples include deleting expired cache rows, refreshing materialized views, rotating partitions, generating nightly aggregates, and backfilling reporting tables after business hours. In many systems, pg_cron is the simplest reliable way to keep regular database maintenance visible and version-controlled.

pg_partman

pg_partman automates partition management for large time-based or serial-based tables. This becomes important when tables such as event logs, audit trails, financial transactions, or telemetry data grow fast enough that manual partition maintenance becomes error-prone.

A practical example is an order-event stream or clickstream table that grows by millions of rows per day. pg_partman can pre-create future partitions and help with retention workflows so that inserts stay predictable and cleanup stays manageable.

Time-series and analytics

TimescaleDB

TimescaleDB extends PostgreSQL for time-series workloads and is commonly used for metrics, telemetry, stock ticks, IoT streams, and event-heavy analytical pipelines. It is attractive because teams can keep SQL, relational joins, and operational familiarity while gaining features designed for time-based data growth.

A real-world use case is infrastructure monitoring for a SaaS platform. Application latency, queue depth, API errors, and worker CPU usage can be stored as time-series data and queried for dashboards, rollups, and anomaly windows without moving immediately to a separate metrics engine.

hll

hll implements HyperLogLog for approximate distinct counts, which is extremely useful in analytics systems where exact uniqueness is expensive but approximate answers are acceptable. It helps reduce compute and storage pressure for cardinality-heavy metrics.

A common production example is counting unique visitors, unique coupon users, unique sessions, or unique SKUs viewed during a time period. In growth analytics or retail traffic reporting, hll makes these queries much more efficient at scale.

Cross-database and scale-out access

postgres_fdw

postgres_fdw lets PostgreSQL query tables from another PostgreSQL database as if they were local, which is valuable for integration-heavy architectures. It offers a practical option when teams need shared access across services without immediately committing to a full ETL pipeline.

A real-world use case is a commerce platform where operational order data lives in one PostgreSQL cluster and finance reconciliation data lives in another. postgres_fdw can help build internal reporting or migration bridges while preserving separate ownership boundaries.

Citus

Citus extends PostgreSQL for distributed scale-out and is often used for multi-tenant SaaS, large analytical workloads, and systems that need sharding with PostgreSQL compatibility. It helps when a single node is no longer enough for storage, throughput, or parallel processing requirements.

A practical use case is a SaaS platform serving many tenants with tenant-scoped data and predictable distribution keys. Citus can shard data across nodes while preserving a familiar PostgreSQL interface for most application code.

Document database extensions

pg_documentdb_core and pg_documentdb_api

pg_documentdb_core adds BSON datatype support and native BSON operations to PostgreSQL, while pg_documentdb_api provides CRUD and advanced document APIs on top of that foundation. Together, they allow PostgreSQL to act more like a MongoDB-compatible document database while still benefiting from the PostgreSQL ecosystem.

The feature set goes beyond simple CRUD. The DocumentDB stack supports advanced queries such as full-text search, geospatial queries, vector search, aggregation pipelines, and multiple index types including TTL, text, geospatial, and vector indexes. That makes it relevant not only for document storage but also for hybrid operational workloads where JSON-like flexibility and rich querying are both necessary.

A strong real-world example is a product catalog or merchant onboarding system with highly variable nested attributes across categories. Electronics, apparel, furniture, and automotive parts often do not share a stable schema, so a document model helps teams move fast while PostgreSQL still handles surrounding transactional data.

Another practical use case is event payload storage for AI and fraud analysis. Since the extension stack supports full-text, vector, and geospatial capabilities, it can support workloads such as chatbot context documents, anomaly investigation payloads, and customer activity streams without splitting the data across multiple database engines too early.

Durable workflows and orchestration

pg_durable

pg_durable is an open-source PostgreSQL extension that brings durable execution directly into the database. It runs long-lived, fault-tolerant workflows with built-in retries, parallelism, scheduling, and recovery, and it does so using a background worker so the user session is not blocked for the duration of the workflow.

This matters because many teams eventually need multi-step jobs that are tightly coupled to database state: transformations, aggregations, maintenance workflows, embedding pipelines, approvals, and queue-driven business processes. Without a durable execution model, those teams often end up choosing between one fragile long-running SQL function or a separate orchestration system with queue tables, workers, retry logic, and crash recovery code.

pg_durable is strongest when the workflow reads and writes rows that already live in PostgreSQL and should inherit PostgreSQL durability, backups, high availability, and recovery behavior. The extension breaks workflows into discrete steps, checkpoints state inside PostgreSQL, and retries failed steps individually instead of rerunning the entire process.

A real-world e-commerce example is an order orchestration flow: validate order, reserve inventory, charge payment, create fulfillment request, notify the customer, and retry only the failed step if an external dependency times out. Another strong use case is an internal AI pipeline where chunking, embedding, indexing, and downstream refreshes should survive restarts without rebuilding completed steps.

CREATE EXTENSION IF NOT EXISTS pg_durable;
SELECT df.start($$
  SELECT 'Hello, durable world!' AS message
$$);

The Microsoft example also shows pg_durable handling ETL pipelines, scheduled sync jobs, and human-in-the-loop approvals, which makes it relevant well beyond simple background tasks. For teams that want orchestration close to the data instead of a separate workflow platform, this extension is one of the most interesting recent additions to the PostgreSQL ecosystem.

API and REST access

PostgREST / pgrest

pgrest is best described in practice as the category of tools that expose PostgreSQL tables, views, and stored procedures as HTTP APIs. While the exact packaging depends on the implementation a team adopts, the architectural use case is consistent: turn database objects into REST endpoints quickly for internal tools, dashboards, admin apps, prototypes, and data-centric services.

A real-world use case is a back-office operations app where catalog data, merchant records, settlements, or support queues need fast API exposure without building a large custom backend first. This approach is especially effective when access rules are already modeled in PostgreSQL and the API mostly reflects relational resources and stored procedures.

Another good example is a BFF-style internal platform for dashboards. When product, finance, and operations teams need secure read APIs on curated views, a Postgres-to-REST layer can shorten delivery time significantly and keep the data contract close to the schema.

Procedural logic and database-native business rules

plpgsql

plpgsql powers stored procedures, triggers, and custom business logic inside PostgreSQL, and it is installed by default in a very large number of databases. It is essential when teams need transactional business rules to execute close to the data with predictable behavior.

A practical use case is enforcing inventory consistency or audit logging through triggers. For example, when a stock row changes, a plpgsql trigger can write an audit event, validate transitions, or derive dependent values before the transaction commits.

How to choose the right extension

The best extension depends on the workload, not on popularity alone. Search-heavy products usually benefit first from pg_trgm, unaccent, and citext; operations-heavy systems benefit from pg_stat_statements, pg_cron, and pg_partman; AI-backed products often reach for pgvector; and location-aware platforms almost always need PostGIS.

For systems with fast-changing schemas, pg_documentdb_core and pg_documentdb_api provide a document-oriented option on top of PostgreSQL. For systems with multi-step jobs tied to database state, pg_durable can eliminate a surprising amount of application-side orchestration code.

A practical selection framework looks like this:

Choose observability extensions when the main pain is slow queries and poor visibility.
Choose search extensions when users search messy, multilingual, or typo-prone text.
Choose geospatial extensions when distance, service areas, or coordinates are part of the business model.
Choose AI extensions when semantic retrieval or recommendations matter.
Choose scheduling and orchestration extensions when recurring jobs or multi-step workflows are becoming application infrastructure.
Choose document extensions when schemas are highly variable and nested documents are central to the product.
Choose REST exposure tools when the fastest path to value is to publish clean APIs directly from data models.

Extension shortlist by scenario

Scenario	Recommended extensions	Why they fit
E-commerce catalog search	`pg_trgm`, `unaccent`, `citext`	Handles fuzzy, multilingual, and case-insensitive product and identity search.
Store locator or delivery zone	`postgis`	Supports location indexing, radius search, and spatial filtering.
AI knowledge base or RAG	`pgvector`, `pg_durable`	Stores embeddings and can orchestrate durable embedding pipelines.
Operational database tuning	`pg_stat_statements`, `auto_explain`, `hypopg`	Improves visibility into query cost and index decisions.
High-volume event data	`pg_partman`, `TimescaleDB`, `hll`	Helps with partitioning, time-series analysis, and approximate uniqueness metrics.
Flexible document-style domain model	`pg_documentdb_core`, `pg_documentdb_api`	Supports BSON, CRUD APIs, advanced queries, and multiple index types.
Quick internal API platform	`pgrest` / PostgREST-style layer	Exposes tables, views, and functions rapidly as REST endpoints.

Closing perspective

The strongest PostgreSQL architectures usually do not come from using the most extensions. They come from choosing a small, focused set of extensions that match real product needs and keep the system operationally simple for as long as possible.

That is the real advantage of PostgreSQL’s extension ecosystem. It lets a single platform grow from a transactional database into a broader application data layer, and it gives engineering teams room to delay complexity until there is a proven reason to introduce more infrastructure.

Stop Running 5 Databases: PostgreSQL Does It All in 2026

Shahid — Mon, 15 Jun 2026 10:37:20 +0000

How a 35-year-old open-source database became the default choice for relational storage, full-text search, vector AI workloads, geospatial queries, and event-driven architecture — in a single deployment.

Most production architectures look like a small city: a relational database for core data, a document store for flexible schemas, an Elasticsearch cluster for search, a vector database for AI-powered features, and a message broker stitching it all together. Five services. Five deployment pipelines. Five monitoring dashboards. Five points of failure — all to solve problems that, in most applications, one database already handles.

That database is PostgreSQL. It started as a research project at UC Berkeley in the 1980s and has quietly evolved into one of the most capable data platforms ever built. In 2026, as teams race to bolt AI onto their stacks without doubling infrastructure costs, Postgres has emerged as the default answer — not because it's new, but because it was built right.

What Makes Postgres Different

At its core, Postgres is a relational, ACID-compliant SQL database: tables, rows, foreign keys, joins, everything you'd expect. What separates it architecturally from MySQL or SQLite is that it was built for extensibility from day one. There is a formalized plugin API that lets you add new data types, new index strategies, and entirely new capabilities via a single CREATE EXTENSION command. This is not a bolt-on feature or a marketing checkbox — it is a deeply deliberate design choice baked into the query engine itself.

The result: Postgres doesn't just store data. It becomes the entire data layer of your application, without stitching together a fleet of specialized services you need to deploy, monitor, and keep in sync.

Replacing the Document Store: JSONB

The standard pitch for MongoDB has always been: relational schemas are too rigid for modern applications. Postgres answers that directly with JSONB — a binary-encoded JSON column type that lets you store fully schemaless documents right next to your strict relational tables, in the same database, under the same transaction.

You can query deep into nested JSON using path expressions, check for key existence, test containment, and — critically — put a GIN index on the entire document so those queries stay fast at scale:

CREATE TABLE users (
  id     SERIAL PRIMARY KEY,
  email  TEXT NOT NULL,
  data   JSONB
);

CREATE INDEX idx_users_data ON users USING GIN (data);

-- Find all users on the 'pro' plan
SELECT email
FROM users
WHERE data @> '{"plan": "pro"}';

Your schemaless layer and your relational layer live in the same table, under the same backup, in the same SELECT. No data synchronization. No eventual consistency headaches. No second server.

Replacing Elasticsearch: Built-in Full-Text Search

Elasticsearch is powerful — but it's also one of the heaviest pieces of infrastructure you can operate. It needs its own cluster, its own memory tuning, its own index lifecycle management, and it demands you keep two copies of your data in sync at all times.

Postgres has a native full-text search engine that handles tokenization, stemming (so "running" matches "run" and "runs"), stop-word filtering, relevance ranking, and indexed retrieval. For the overwhelming majority of product search boxes and content discovery features, it is more than sufficient:

-- GIN-indexed full-text search
CREATE INDEX idx_articles_fts
ON articles USING GIN (to_tsvector('english', title || ' ' || body));

-- Ranked search results
SELECT title,
       ts_rank(to_tsvector('english', title || ' ' || body), query) AS rank
FROM articles,
     to_tsquery('english', 'distributed & systems') AS query
WHERE to_tsvector('english', title || ' ' || body) @@ query
ORDER BY rank DESC;

The only time Elasticsearch genuinely pulls ahead is at massive scale with advanced requirements — complex multi-language synonym pipelines, cross-cluster federation, or deep faceted navigation. For everything else, Postgres saves you an entire infrastructure tier.

Replacing Pinecone and Weaviate: AI-Native Vector Search

This is the capability that has become non-negotiable in 2026. Every application now has an AI feature. Every AI feature needs semantic search. The pgvector extension adds a native vector column type and approximate nearest-neighbor (ANN) search, making Postgres the backbone of Retrieval-Augmented Generation (RAG) pipelines without standing up a dedicated vector database.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
  id        SERIAL PRIMARY KEY,
  content   TEXT,
  embedding vector(1536)
);

-- HNSW index for fast approximate nearest-neighbor search
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

-- Semantic similarity search
SELECT content,
       1 - (embedding <=> '[0.12, 0.47, ...]') AS similarity
FROM documents
ORDER BY embedding <=> '[0.12, 0.47, ...]'
LIMIT 5;

For workloads under roughly 100 million vectors, Postgres with pgvector eliminates dedicated vector database overhead with no measurable quality trade-off. The real advantage over standalone vector databases isn't just eliminating a service — it's composability: your vector search can be combined with WHERE filters, JOINs across tables, and Row-Level Security in a single query. Pinecone cannot join against your application data. Postgres can.

Replacing Redis and RabbitMQ: Queues and Pub/Sub

Two underused, underappreciated Postgres features handle most messaging needs without introducing a broker.

LISTEN / NOTIFY is a lightweight pub/sub mechanism built directly into the wire protocol. One session publishes a text payload to a named channel; every subscribed session receives it in milliseconds. It's not Kafka — but for triggering background workers, pushing cache invalidation events, or wiring up a simple notification system, it's zero-infrastructure pub/sub.

SELECT FOR UPDATE SKIP LOCKED turns an ordinary table into a reliable, concurrent job queue. Multiple workers pull jobs simultaneously without race conditions, because each SELECT atomically locks the row it claims and skips all rows already locked by other workers:

-- Worker atomically claims the next available job
BEGIN;

SELECT * FROM jobs
WHERE status = 'pending'
ORDER BY created_at
FOR UPDATE SKIP LOCKED
LIMIT 1;

-- ... process the job ...

UPDATE jobs SET status = 'done' WHERE id = :id;
COMMIT;

If a worker crashes mid-job, the transaction rolls back and the row becomes claimable again — automatic exactly-once delivery, built on the ACID guarantees you already have.

Replacing Geospatial APIs: PostGIS

The PostGIS extension is one of the most capable geospatial engines in the entire software ecosystem — commercial or otherwise. It adds geometry and geography column types (points, lines, polygons, multipolygons), spatial indexing via GiST, and a rich library of functions for distance calculations, intersection tests, buffering, and coordinate system transformations:

-- Find all stores within 5km of a user's location in Bengaluru
SELECT name,
       ST_Distance(location, ST_MakePoint(77.5946, 12.9716)::geography) AS dist_meters
FROM stores
WHERE ST_DWithin(
  location,
  ST_MakePoint(77.5946, 12.9716)::geography,
  5000
)
ORDER BY dist_meters;

Entire commercial GIS platforms used by governments and logistics companies worldwide are built on PostGIS. It replaces the need for a separate geospatial API service for any proximity or boundary query against your own data.

The SQL You're Probably Under-Using

Beyond extensions, most developers use roughly 60% of Postgres's SQL capabilities. The remaining 40% eliminates entire categories of application-layer code.

Window Functions compute aggregates across rows related to the current row without collapsing them like GROUP BY does — running totals, moving averages, percentile ranks, all in a single pass:

SELECT
  order_date,
  amount,
  SUM(amount) OVER (ORDER BY order_date) AS running_total,
  AVG(amount) OVER (
    ORDER BY order_date
    ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
  ) AS rolling_7day_avg
FROM orders;

Recursive CTEs walk tree structures — org hierarchies, category trees, threaded comments, dependency graphs — in pure SQL, with no application-side recursion or multiple round trips:

WITH RECURSIVE category_tree AS (
  SELECT id, name, parent_id, 0 AS depth
  FROM categories WHERE parent_id IS NULL

  UNION ALL

  SELECT c.id, c.name, c.parent_id, t.depth + 1
  FROM categories c
  JOIN category_tree t ON c.parent_id = t.id
)
SELECT * FROM category_tree ORDER BY depth, name;

Atomic Upserts handle the classic insert-or-update race condition with a single statement — no optimistic locking, no read-then-write, no race:

INSERT INTO inventory (product_id, stock)
VALUES (42, 100)
ON CONFLICT (product_id) DO UPDATE
  SET stock = EXCLUDED.stock,
      updated_at = NOW();

Indexes: A Write Tax for a Read Benefit

Postgres gives you multiple index types, each precision-engineered for a different access pattern. Picking the right one is one of the highest-leverage optimizations available:

Index Type	Best For	Typical Use Case
B-tree	Equality, ranges, ordering (default)	`WHERE created_at > '2025-01-01'`
GIN	JSONB keys, full-text search, arrays	`data @> '{"plan": "pro"}'`
GiST	Geometry, ranges, fuzzy matching	`ST_DWithin(location, point, 500)`
BRIN	Massive append-only time-series tables	IoT sensor logs, event streams
HNSW / IVFFlat	Vector ANN similarity search	Embedding-based semantic retrieval

Every index is a write tax for a read benefit — it makes INSERT, UPDATE, and DELETE slightly slower because Postgres maintains the index alongside the table. Add indexes surgically, guided by EXPLAIN ANALYZE output, not speculatively:

EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM orders WHERE customer_id = 1234 AND status = 'shipped';

The most important thing to look for in the output: Seq Scan vs Index Scan. A sequential scan on a large table is your bottleneck. An appropriately chosen index on the same query is your fix.

PostgreSQL 18: Built for the AI Era

PostgreSQL 18, released in 2026, doubles down on AI-era workloads with several meaningful improvements.

Asynchronous I/O significantly reduces latency on storage-bound operations, directly benefiting heavy embedding writes and similarity search workloads
Skip-scan on multicolumn indexes makes filtering around vector similarity searches dramatically faster
UUIDv7 index optimization improves insert and scan performance for tables that use UUID primary keys — common in distributed and event-driven systems
Automatic data checksums are now enabled by default on new clusters, eliminating a common silent data corruption risk
OAuth 2.0 authentication support out of the box for enterprise identity integration

These aren't cosmetic improvements — they're direct responses to the workload patterns that have emerged as teams integrate LLMs and AI features into their production stacks.

Under the Hood: Three Mechanisms That Explain Everything

Three internal systems explain most of Postgres's observable behavior — and knowing them prevents a category of production incidents.

MVCC (Multi-Version Concurrency Control) is why readers and writers never block each other. When you update a row, Postgres doesn't overwrite it. It writes a new version of the row and marks the old one as expired. Every transaction sees the world as it existed when that transaction started, regardless of what other transactions are doing concurrently. This is what makes SERIALIZABLE isolation achievable without locking tables.

WAL (Write-Ahead Log) is why Postgres survives crashes with full consistency. Every change is written to a sequential log before it's applied to data files on disk. On restart after a crash, Postgres replays the WAL and arrives at exactly the state it would have been in had the crash never happened. The same WAL stream is also shipped to read replicas in real time — replication is essentially a free side effect of crash recovery.

VACUUM and Dead Tuple Bloat is the tax you pay for MVCC. Because old row versions aren't overwritten, they accumulate as "dead tuples" on disk. The background autovacuum process reclaims this space continuously. In write-heavy workloads, autovacuum can fall behind — leading to table bloat, index bloat, and eventually a transaction ID wraparound emergency. Monitor pg_stat_user_tables for n_dead_tup values that keep climbing.

Scaling Postgres: What's Real and What's Honest

Read scaling is well-understood: stream the WAL to standby servers and route SELECT queries across them. Read replicas are typically milliseconds behind the primary.
Write scaling is the honest hard limit. One primary accepts all writes. When you genuinely hit that ceiling, these are your options:

Table Partitioning — splits large tables (by month, by region, by tenant) into physical partitions; Postgres prunes irrelevant partitions at query time, dramatically reducing scan sizes on time-series or multi-tenant data
Citus — distributes both data and queries across a cluster of Postgres nodes, enabling horizontal write scaling while keeping the full Postgres SQL interface
PgBouncer — not a scaling tool but an operational necessity. Each Postgres connection is a full OS process consuming 5–10MB of RAM. Serverless functions and connection-heavy frameworks will exhaust your connection limit quickly. PgBouncer pools thousands of application connections onto a small, stable set of real server connections, and it belongs in every production deployment ***

When to Reach for Something Else

Postgres is honest about its limits. You should be too.

Pure hot-path in-memory cache at millions of ops/sec → Redis; Postgres is not a memory store
Horizontal write sharding across 10+ nodes from day one → purpose-built distributed systems like Cassandra or CockroachDB
Petabyte-scale OLAP with complex aggregations → columnar engines like ClickHouse, DuckDB, or BigQuery will be orders of magnitude faster
High-throughput real-time event streaming → Kafka or Redpanda own that space; NOTIFY doesn't match their throughput guarantees

The engineering discipline is: start with Postgres, measure your actual bottlenecks, and add specialized tooling only when you've conclusively outgrown what Postgres offers. The biggest architectural mistake teams make is adding distributed complexity in anticipation of hypothetical scale that never arrives.

Why the License Is a Competitive Moat

Postgres is governed by the PostgreSQL Global Development Group — a community intentionally structured so that no single company can change its terms. The license is permissive, similar in spirit to BSD/MIT. You own your deployment. You control your upgrade path.

This is not a footnote. In recent years, MongoDB switched to SSPL and Redis changed to BSL, sending engineering teams scrambling for alternatives. That cannot structurally happen with Postgres. The community governance model is the moat — and in a world where vendor lock-in risk has become a real architecture consideration, that stability has genuine business value.

The Single-Database Architecture

One database. One backup strategy. One set of credentials. One monitoring dashboard. One EXPLAIN ANALYZE. It handles your relational data, your documents, your full-text search, your vector embeddings, your geospatial queries, your job queue, and your pub/sub events — and it has been reliably doing so for production systems at scale for over thirty years.

In 2026, the question isn't whether Postgres is capable enough. The question is whether your architecture has already added five services it didn't need.

Testing MCP Server Tools in AI Agents — A Practical Guide

Shahid — Sun, 24 May 2026 08:26:10 +0000

Building an MCP server is only half the job. The other half — testing its tools — is where most developers drop the ball.

If you're using the Vercel AI SDK to build AI agents with Model Context Protocol (MCP), you already know how powerful tool-calling can be. But an untested tool is a liability. A hallucinating LLM calling a broken tool can cause cascading failures that are notoriously hard to debug in production. This guide walks you through a layered testing strategy — from fast unit tests to full end-to-end evaluations.

Why Testing MCP Tools Is Uniquely Hard

MCP tools sit at the intersection of three systems: your server logic, the LLM's tool selection behavior, and the AI SDK's execution pipeline. A bug can live in any one of them. Testing just the server in isolation gives you false confidence — you also need to verify that the LLM actually picks the right tool for a given prompt, and that the AI SDK correctly routes the call.

Layer 1: Unit Test Tool Logic Directly

Before involving any LLM, test your tool's execute() function in complete isolation. The AI SDK lets you invoke tool execution directly with a typed input:

const result = await tools['search-docs'].execute(
  { query: 'MCP transport options' },
  { messages: [], toolCallId: 'test-001' }
);

expect(result.documents.length).toBeGreaterThan(0);

This runs in milliseconds, costs nothing, and catches the most common bugs — wrong output shapes, missing error handling, and schema mismatches.

Layer 2: Inspect Schemas with the MCP Inspector

Run the official @modelcontextprotocol/inspector CLI tool against your server before writing a single test:

npx @modelcontextprotocol/inspector node dist/server.js

The browser UI lets you browse all registered tools, manually invoke them with custom inputs, and inspect raw JSON-RPC payloads. This is your smoke test — it confirms your server is reachable and your schemas are well-formed. Do this after every new tool you add.

Layer 3: Mock the LLM for Integration Tests

Real LLM API calls are slow, flaky, and expensive in CI pipelines. The AI SDK ships a MockLanguageModelV1 in ai/test specifically for this:

import { MockLanguageModelV1 } from 'ai/test';
import { generateText } from 'ai';

const mockModel = new MockLanguageModelV1({
  doGenerate: async () => ({
    finishReason: 'tool-calls',
    toolCalls: [{
      toolCallType: 'function',
      toolCallId: 'call-1',
      toolName: 'get-weather',
      args: JSON.stringify({ location: 'Bengaluru' }),
    }],
    rawCall: { rawPrompt: null, rawSettings: {} },
    usage: { promptTokens: 10, completionTokens: 5 },
  }),
});

const { toolResults } = await generateText({
  model: mockModel,
  tools: mcpTools,
  prompt: 'What is the weather in Bengaluru?',
});

This tests your entire AI agent pipeline — tool registration, execution, result parsing — without a single API call.

Layer 4: Evaluate Tool Selection Accuracy

The hardest problem to test is: will the LLM choose the right tool? A tool with a vague description might get ignored. A poorly scoped tool might be called when it shouldn't be. Use mcp-evals for structured grading:

import { evalTool } from 'mcp-evals';

const result = await evalTool({
  prompt: 'Find all open GitHub issues labeled bug',
  expectedTool: 'list-github-issues',
  grader: 'openai/gpt-4o',
});

console.log(`Score: ${result.score}, Passed: ${result.passed}`);

Run these evals whenever you change a tool's name, description, or input schema — those are the highest-risk moments.

The One Rule That Saves Hours of Debugging

Always call await mcpClient.close() after every test. Leaving MCP connections open causes port conflicts, zombie processes, and flaky tests in CI. Wrap every test suite in a beforeAll/afterAll block:

beforeAll(async () => { mcpClient = await createMCPClient({ ... }); });
afterAll(async () => { await mcpClient.close(); });

What to Test at Each Layer

Layer	Speed	Cost	Tests
`tool.execute()` directly	Fast	Free	Logic, output schema, error handling
MCP Inspector	Manual	Free	Schema validity, tool discoverability
`MockLanguageModelV1`	Fast	Free	Full agent pipeline, tool routing
`mcp-evals` grading	Slow	LLM cost	Tool selection accuracy by description

Start with Layer 1 for every tool, use Layer 3 for CI, and run Layer 4 before any deployment that touches tool descriptions or names. Your future self — staring at a 3 AM production incident — will thank you.

Have questions about testing a specific tool type? Drop them in the comments below.

How do I calculate how many shares to buy based on ATR and risk management?

Shahid — Sun, 10 May 2026 06:42:51 +0000

One of the most common questions I see from traders is: "I like this setup — but how many shares should I buy?"

Most people guess. Or buy a round number. Or deploy whatever cash they have.

Here's the systematic answer using ATR.

The Framework

ATR(14) tells you how much a stock moves on an average day. Using that as your stop foundation means your stop is calibrated to the stock's actual volatility — not an arbitrary percentage.

Step 1 — Stop Distance
Stop Distance = ATR × Multiplier

2× ATR → short-term / swing trades
3× ATR → positional / long-term (recommended)
4× ATR → very wide, for high-volatility stocks

Step 2 — Risk Budget
Risk Budget = Capital × Risk %
Standard: 1% of capital per trade.
₹1,00,000 capital → ₹1,000 max loss per trade

Step 3 — Position Size
Units = Risk Budget ÷ Stop Distance

Example (round numbers)

Stock price: ₹500 | ATR(14): ₹5 | Capital: ₹1,00,000

ATR Mult	Stop Dist	Stop Price	Units	Deployed	Max Loss
2×	₹10	₹490	100	₹50,000	₹1,000
3× ★	₹15	₹485	66	₹33,000	₹990
4×	₹20	₹480	50	₹25,000	₹1,000

Notice the max loss stays ~₹1,000 across all levels. The multiplier controls stop tightness — not your risk amount. Your position size automatically adjusts.

The YOLO trap

Buying 200 units (full ₹1L deployed) with a 3× ATR stop risks:
200 × ₹15 = ₹3,000 = 3% of capital in one trade.

Across 4 simultaneous positions that's 12% exposure. One bad week is devastating.

ATR position sizing keeps each trade capped at 1% regardless of entry price or volatility level.

Free Calculator

I built a browser-based tool that does all this math instantly — enter your ATR, entry price, capital and risk %, and it simulates across all multiplier levels with a comparison table and charts.

🔗 https://trade-atr.sk7.workers.dev/

No login, no signup — runs entirely in your browser.

npm vs pnpm: The Ultimate Command Comparison Cheat Sheet

Shahid — Fri, 22 Aug 2025 13:49:58 +0000

pnpm and npm are both package managers for JavaScript, but they handle dependency installation and management differently. Direct command translation between npm and pnpm is nearly 1:1—most operations you run in npm can be run in pnpm with the same arguments, but under the hood, pnpm is typically faster and far more disk-efficient due to its unique content-addressable storage approach and symlinking strategy.

Below is a direct, command-by-command comparison between npm and pnpm for common package management tasks. The table uses npm as the reference, with the equivalent pnpm command, and notes any important behavioral differences.

Task	npm Command	pnpm Command	Notes
Initialize project	`npm init`	`pnpm init`	Both create `package.json`; behavior identical.
Install all dependencies	`npm install`	`pnpm install`	pnpm uses a global store and symlinks for speed/space; npm duplicates packages.
Add dependency	`npm add <package>`	`pnpm add <package>`	Both save to `package.json` by default; options like `--save-dev` work the same.
Add dev dependency	`npm add -D <package>`	`pnpm add -D <package>`	Both add to `devDependencies`.
Add optional dependency	`npm add -O <package>`	`pnpm add -O <package>`	Both add to `optionalDependencies`.
Add global package	`npm add -g <package>`	`pnpm add -g <package>`	pnpm's global store is more efficient.
Remove package	`npm remove <package>`	`pnpm remove <package>`	Both remove from `package.json` and `node_modules`.
Update package	`npm update <package>`	`pnpm update <package>`	pnpm updates from its global store, often faster.
Check outdated packages	`npm outdated`	`pnpm outdated`	Both show outdated packages.
Run script	`npm run <script>`	`pnpm <script>`	pnpm does not require `run` keyword if script exists in `package.json`.
Run command	`npx <command>`	`pnpm dlx <command>`	pnpm uses `dlx` to download and run commands like `npx`.
Prune node_modules	`npm prune`	`pnpm prune`	pnpm always removes extraneous/orphaned packages, no package args allowed.
List installed packages	`npm ls`	`pnpm ls`	Both list dependency trees.
Audit for vulnerabilities	`npm audit`	`pnpm audit`	Both check for security issues.
Install pnpm globally	`npm install -g pnpm`	–	`pnpm` can be installed via npm or other methods.

Key Differences Under the Hood

Installation Speed & Disk Space: pnpm is typically much faster and uses far less disk space than npm, especially in large projects, because it stores each package version once globally and symlinks into project node_modules.
Dependency Resolution: pnpm enforces strict dependency resolution, which can help avoid "phantom" dependencies (packages not listed in package.json but still accessible). npm’s flattened node_modules can sometimes allow this.
Monorepo/Workspaces: pnpm has built-in, optimized support for monorepos and workspaces; npm requires extra configuration for similar features.
Ecosystem: npm has the largest ecosystem and widest compatibility; pnpm’s is growing but smaller.
Global Store: pnpm’s global store is a major architectural difference—reducing duplication across all projects on your system.

When to Use Which

Use npm if you want maximum ecosystem compatibility, are working on small projects, or need the broadest community support.
Use pnpm if you value disk space, installation speed, strict dependency isolation, or are managing large projects/monorepos.

Summary

For most day-to-day commands, just replace npm with pnpm. The key differences are internal (speed, disk usage, dependency resolution), not in the command syntax. However, pnpm’s architecture means your projects will install faster, use less disk space, and be more strictly isolated—benefits that grow with project size and complexity.

If you need a specific npm command translated to pnpm that isn’t listed above, just ask—the mapping is nearly always straightforward!

From Zero to AI-Powered Developer: Your Complete Claude Code CLI Setup Guide

Shahid — Wed, 06 Aug 2025 06:43:45 +0000

Setting up your development environment with AI assistance used to be a pipe dream. Today, it's a 10-minute process that could transform how you write code forever. Here's everything you need to know to get Claude Code running on your system—from installation to your first AI-powered commit.

The landscape of software development is shifting rapidly, and at the center of this transformation is Claude Code—Anthropic's command-line AI assistant that brings enterprise-level coding capabilities directly to your terminal. Whether you're a seasoned developer or just starting your coding journey, this comprehensive guide will get you up and running with one of 2025's most powerful development tools.

Why Claude Code Setup Matters More Than Ever

Before diving into the technical details, it's worth understanding what makes Claude Code different from other AI coding tools. Unlike browser-based chatbots or IDE plugins that work in isolation, Claude Code operates as a full-fledged development partner that can read your entire codebase, understand your project architecture, and make coordinated changes across multiple files simultaneously.

The setup process might seem straightforward, but getting it right from the beginning can mean the difference between a seamless development experience and hours of troubleshooting down the line.

Pre-Flight Check: System Requirements That Actually Matter

The Baseline Requirements

Before you begin, ensure your system meets these essential requirements:

Operating Systems: macOS 10.15+, Ubuntu 20.04+/Debian 10+, or Windows 10+ (with WSL 1, WSL 2, or Git for Windows)
Hardware: 4GB+ RAM minimum

Software: Node.js 18+ (LTS version strongly recommended)
Network: Stable internet connection for authentication and AI processing
Shell Environment: Works optimally with Bash, Zsh, or Fish
Geographic Location: Must be in an Anthropic-supported country

The Often-Overlooked Details

What the documentation doesn't emphasize enough is that your shell choice can significantly impact your experience. While Claude Code works across different shells, Bash and Zsh users report the most stable experience, particularly when integrating with IDE workflows and managing complex project structures.

Installation Methods: Choosing Your Path to Success

Method 1: NPM Installation (The Reliable Standard)

For most developers, the NPM route provides the most predictable setup experience:

npm install -g @anthropic-ai/claude-code

Critical Warning: Never use sudo with this command. The sudo npm install -g approach can create permission issues and security vulnerabilities that will plague your entire setup. If you encounter permission errors, configure your npm permissions properly or consider the local installation method instead.

This approach works best when you have a properly configured Node.js environment and npm permissions set up correctly on your system.

Method 2: Native Binary Installation (The Cutting-Edge Choice)

For developers who want access to the latest features or need to avoid npm permission complexities entirely, the native binary installation offers a compelling alternative.

For macOS, Linux, and WSL:

# Install stable version (recommended for most users)
curl -fsSL https://claude.ai/install.sh | bash

# Install latest version (for early adopters)
curl -fsSL https://claude.ai/install.sh | bash -s latest

# Install specific version (for compatibility requirements)
curl -fsSL https://claude.ai/install.sh | bash -s 1.0.58

For Windows PowerShell:

# Install stable version
irm https://claude.ai/install.ps1 | iex

# Install latest version
& ([scriptblock]::Create((irm https://claude.ai/install.ps1))) latest

The native binary installation often provides better performance and eliminates dependency conflicts, making it particularly attractive for developers working in complex environments.

Method 3: Local Installation Migration

If you already have a global npm installation and are experiencing autoupdater permission issues, Claude Code provides a seamless migration path:

claude migrate-installer

This command transitions your installation to a local setup that avoids common permission pitfalls. Some users may be automatically migrated to this method during updates.

Platform-Specific Considerations That Make or Break Your Setup

Windows: Navigating the Complexity

Windows users have two primary paths, each with distinct advantages:

Option 1: WSL Integration (Strongly Recommended)
Both WSL 1 and WSL 2 are fully supported, but the experience is significantly smoother within a Linux subsystem. Install Ubuntu 20.04+ or Debian 10+ through WSL, then follow the standard Linux installation process.

Option 2: Native Windows with Git Bash
This approach requires Git for Windows and additional configuration. For portable Git installations, you'll need to specify the bash path:

$env:CLAUDE_CODE_GIT_BASH_PATH="C:\Program Files\Git\bin\bash.exe"

Linux and macOS: The Straightforward Path

Installation on Unix-based systems is typically seamless using either the npm or native binary methods. The primary consideration is ensuring your Node.js version meets the LTS requirements.

Post-Installation Verification: Ensuring Everything Works

After installation, verification is crucial to avoid discovering setup issues during critical development moments:

# Check installation health and configuration
claude doctor

# Verify global availability and version
claude --version

If you used the native binary installation method, you might need to add Claude to your system PATH:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.profile

Remember to restart your terminal or source your profile for PATH changes to take effect.

Authentication: Your Gateway to AI-Powered Development

Claude Code offers three distinct authentication approaches, each suited to different use cases:

Option 1: Anthropic Console (Default Path)

Requires an active billing account at console.anthropic.com
Uses OAuth for secure authentication
Navigate to your project directory and run claude to begin the authentication flow

Option 2: Claude App Integration (Pro/Max Plans)

Perfect for developers with existing Claude Pro or Max subscriptions
Provides unified billing and account management
Log in with your Claude.ai credentials during the initial launch

Option 3: Enterprise Platforms

Designed for organizations using Amazon Bedrock or Google Vertex AI
Requires additional configuration for cloud infrastructure integration
Ideal for enterprise environments with existing AI platform investments

First Session: Making Contact with Your AI Development Partner

Your first Claude Code session sets the foundation for all future interactions:

Navigate to your project directory:

cd /path/to/your/project

Launch Claude Code:

claude

Complete the authentication flow following the prompts
You'll be greeted with the welcome interface:

✻ Welcome to Claude Code!
...
> Try "create a util logging.py that..."

This welcome prompt isn't just ceremonial—it's your first indication that Claude Code has successfully connected to Anthropic's servers and is ready to assist with your development workflow.

Essential Configuration for Maximum Effectiveness

Environment Variables for Advanced Users

While not required for basic operation, setting up environment variables can enhance your Claude Code experience:

# For direct API access (add to ~/.bashrc, ~/.zshrc, or ~/.profile)
export ANTHROPIC_API_KEY="your-api-key-here"

# For Amazon Bedrock integration
export CLAUDE_CODE_USE_BEDROCK=1

# For Google Vertex AI integration
export CLAUDE_CODE_USE_VERTEX=1

Project-Level Context: The CLAUDE.md Secret Weapon

One of Claude Code's most powerful features is its ability to maintain project context through a CLAUDE.md file placed in your project root. This file acts as a persistent briefing document that Claude Code references for every interaction:

# Project: Web Application Backend

## Structure
- `src/` - Main application code
- `tests/` - Test suites and fixtures
- `docs/` - Project documentation
- `config/` - Configuration files

## Conventions
- Use TypeScript for all new files
- Follow REST API naming conventions
- Implement comprehensive error handling

This context file dramatically improves Claude Code's understanding of your project, resulting in more accurate suggestions and fewer misaligned implementations.

Command Reference: Your Daily Development Arsenal

Understanding Claude Code's command structure is essential for effective usage:

Command	Purpose	Use Case
`claude`	Start interactive mode	Beginning a development session
`claude "task"`	Execute one-time task	Quick fixes or implementations
`claude -p "query"`	Run query and exit	Getting explanations or guidance
`claude -c`	Continue recent conversation	Resuming interrupted work
`claude -r`	Resume previous conversation	Returning to earlier discussions
`claude commit`	Create Git commit	Automated commit message generation
`/clear`	Clear conversation history	Starting fresh within a session
`/help`	Show available commands	Discovering new capabilities
`/config`	Configure settings	Customizing your experience

IDE Integration: Bringing AI Into Your Editor

VS Code Integration Made Simple

Claude Code's VS Code integration transforms your editor into an AI-powered development environment:

Start Claude Code from your VS Code terminal:

claude

Enable IDE integration:

> /ide

Install the extension when prompted Claude Code will automatically detect VS Code and guide you through extension installation. Alternatively, you can manually install the claude-code.vsix file from your installation directory.

Support for Alternative IDEs

Claude Code also integrates with Cursor and other modern editors using a similar process—start Claude Code from the editor's terminal and use the /ide command to enable integration.

Troubleshooting: Solving Common Setup Challenges

Permission Errors

Use the local installation method: claude migrate-installer
Never use sudo with npm installation
Configure npm permissions properly for your user account

Windows Compatibility Issues

Prioritize WSL for the best experience
Ensure Git for Windows is properly installed for native usage
Configure the correct Git Bash path for portable installations

Authentication Problems

Run claude doctor to diagnose authentication status
Re-authenticate using claude /login
Verify you're accessing Claude Code from a supported geographic region

PATH Configuration Issues

Add Claude to your PATH following the post-installation instructions
Remove outdated aliases or symlinks that might conflict
Restart your terminal session after PATH modifications

Beyond Setup: What Comes Next

With Claude Code properly installed and configured, you're positioned to leverage one of the most sophisticated AI development tools available today. The setup process we've covered here creates the foundation for:

Multi-file debugging and refactoring across complex codebases
Intelligent code generation that understands your project's patterns
Automated testing and documentation that stays in sync with your code
Architecture-aware suggestions that respect your existing design decisions

The Investment in Your Development Future

Setting up Claude Code properly isn't just about getting a tool running—it's about establishing a development workflow that can adapt and scale with your projects. The time invested in understanding authentication options, configuring environment variables, and creating comprehensive project context pays dividends in every subsequent coding session.

Whether you're building your next startup, contributing to open source, or tackling enterprise-scale applications, Claude Code's CLI interface provides a consistent, powerful foundation for AI-assisted development.

Your development environment is ready. Your AI coding partner is waiting. The only question remaining is: what will you build first?

Ready to take your development workflow to the next level? With Claude Code properly configured, you're just one claude command away from experiencing the future of software development.

Generate Full Stack React Native Expo project in Seconds ⌚🚀

Shahid — Thu, 17 Jul 2025 07:46:32 +0000

Generate Full Stack React Native project in Seconds.

Run the below command and get relax npx rn-new@latest rn-nw-rnr2 --react-navigation --nativewind --npm --i18next --firebase --drawer --tabs --import-alias --no-install

Ready-made React & Next.js blocks, Framer Motion FX

Shahid — Thu, 17 Jul 2025 07:28:15 +0000

Elevate your next project with a curated suite of minimalist, production-ready UI components crafted in Tailwind CSS, React, and Next.js. Copy-and-paste landing pages, portfolios, and full-stack templates—complete with seamless Supabase integration—let you launch in minutes. Built-in Framer Motion animations, mobile-first responsiveness, and WCAG-focused accessibility ensure every site looks polished and performs flawlessly. Ship professional, scalable web experiences faster than ever.
Visit https://skiper-ui.com

DEV Community: Shahid

The Most Overlooked Part in Docker Compose

Running Is Not Ready

Basic Health Check

Choose the Right Option

Option 1: curl

Option 2: Node.js

Option 3: wget

Option 4: PostgreSQL

Startup Order Matters

Test Before You Trust It

Health Checks Do Not Restart Containers

Final Compose Example

PostgreSQL psql Backslash Commands: A Practical Guide

Getting started

Help and exiting

Show all psql commands

Get help for SQL commands

Exit psql

Databases and connections

List all databases

Connect to another database

Show the current connection

Show or change client encoding

Schemas and tables

List schemas

List tables

Describe a table

List all relations

Views, indexes, sequences, and functions

List views

List materialized views

List indexes

List sequences

List functions

Users, roles, and permissions

List users and roles

Show table privileges

Show object descriptions

Viewing table data

Improving query output

Toggle expanded output

Show query execution time

Show only rows without headers

Change the output format

Running SQL files

Execute a SQL file

Redirect output to a file

Export data with \copy

Query history and editing

Show command history

Clear the current query buffer

Edit the current query

Execute the query buffer

Shell and file-system commands

Run an operating-system command

Change the client working directory

Variables and prompts

List psql variables

Automatic query execution

Repeat a query

Execute query output as SQL

A complete inspection workflow

Common mistakes

Using a backslash command outside psql

Adding a semicolon incorrectly

Expecting tables from another database

Not seeing a table

Quick reference

Transfer files between devices with light — zero network, zero pairing, 100% offline.

Similar projects

Managing Git Remotes: Deleting, Updating, and Switching Origins

Why You'd Change a Remote

Checking Your Current Remote

Updating the Remote URL (Recommended Method)

Removing and Re-adding the Remote (Alternative Method)

Handling Multiple Remotes

Pushing After the Switch

Deleting a Remote Branch

Git Remote Cheatsheet

Show all `psql` commands

Exit `psql`

Export data with `\copy`

List `psql` variables

Using a backslash command outside `psql`