DEV Community: Md Abu Musa

Getting Started with MongoDB and Laravel 13 on Ubuntu 24.04: A Practical Setup Guide

Md Abu Musa — Sun, 18 Oct 2026 16:21:19 +0000

Relational databases are the default for most Laravel projects, and for good reason. But many real systems also hold data that does not fit neatly into rows and columns: product catalogs with varying attributes, event logs, user activity feeds, and content with nested structures. MongoDB's document model handles these cases naturally, and the official Laravel integration lets you work with it using the Eloquent patterns you already know.

This guide walks through a complete, working practice environment on a fresh Ubuntu 24.04 machine: MongoDB 8.0, the PHP MongoDB extension, a new Laravel 13 project, and your first CRUD and aggregation queries. It also covers the one build error that trips up many developers during the extension install, so you can avoid losing an hour to it.

What You Will Build

By the end, you will have:

MongoDB 8.0 running as a system service
The PHP mongodb extension compiled and enabled
A Laravel 13 project connected to MongoDB through mongodb/laravel-mongodb
A Product model with create, read, update, and delete operations working
A first aggregation pipeline running from Laravel

Prerequisites: Ubuntu 24.04, a user with sudo access, and basic familiarity with PHP and the terminal. Ubuntu 24.04 ships with PHP 8.3, which satisfies Laravel 13's requirements.

Step 1: Install MongoDB 8.0

MongoDB is not in Ubuntu's default repositories, so add the official MongoDB repository first.

sudo apt-get update && sudo apt-get install -y gnupg curl

curl -fsSL https://www.mongodb.org/static/pgp/server-8.0.asc | \
  sudo gpg -o /usr/share/keyrings/mongodb-server-8.0.gpg --dearmor

echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg ] https://repo.mongodb.org/apt/ubuntu noble/mongodb-org/8.0 multiverse" | \
  sudo tee /etc/apt/sources.list.d/mongodb-org-8.0.list

sudo apt-get update
sudo apt-get install -y mongodb-org
sudo systemctl enable --now mongod

Verify that the service is running and responding:

systemctl status mongod --no-pager
mongosh --eval 'db.runCommand({ ping: 1 })'

You should see Active: active (running) and { ok: 1 }. If mongod fails to start, sudo journalctl -u mongod -n 50 will show why.

Step 2: Prepare PHP

Install the PHP packages Laravel needs, plus the build tools required to compile the MongoDB extension.

sudo apt install -y php8.3-cli php8.3-xml php8.3-mbstring php8.3-curl \
  php8.3-zip php8.3-sqlite3 php8.3-dev php-pear libssl-dev pkg-config unzip

Install Composer if you do not already have it:

sudo apt install -y composer

Step 3: Install the PHP MongoDB Extension

The Laravel package is built on the official mongodb PHP extension, so nothing works without it. Install it through PECL:

sudo pecl channel-update pecl.php.net
yes '' | sudo pecl install mongodb

Then enable it:

echo "extension=mongodb.so" | sudo tee /etc/php/8.3/mods-available/mongodb.ini
sudo phpenmod mongodb
php --ri mongodb

If the last command prints MongoDB support => enabled along with a version number, the extension is ready.

The Pitfall: Do Not Answer "yes" to PECL's Prompts

During installation, PECL asks several configuration questions. The safe approach is to accept the default for every one of them by pressing Enter, which is exactly what yes '' does above.

A common mistake is answering yes to these three:

Enable developer flags? This turns on strict compiler settings that can turn harmless warnings into build failures.
Enable code coverage? Unnecessary for normal use.
Use system libraries for libbson, libmongoc, and libmongocrypt? This is the one that breaks most builds. Ubuntu's packaged libbson is older than the version the extension requires, so the build stops with an error like Could not find system library for libbson >= 2.5.6.

With the defaults, the extension compiles against its own bundled libraries and builds cleanly. If you already ran the install with the wrong answers, run sudo phpdismod mongodb to silence the load warnings, clear the cache with sudo pecl clear-cache, and reinstall with the defaults.

Also note that the PHP CLI and PHP-FPM read separate configuration. If you later serve the app through FPM or Apache, restart that service after enabling the extension.

Step 4: Create the Laravel Project

composer create-project laravel/laravel mongo-practice
cd mongo-practice
composer require mongodb/laravel-mongodb

Composer selects a compatible version of the package automatically. If it reports a version conflict with Laravel 13, check the package's releases page for the supported version range.

Step 5: Configure the Connection

Add your connection details to .env:

MONGODB_URI=mongodb://127.0.0.1:27017
MONGODB_DATABASE=practice

Then add a mongodb connection to the connections array in config/database.php:

'mongodb' => [
    'driver'   => 'mongodb',
    'dsn'      => env('MONGODB_URI', 'mongodb://127.0.0.1:27017'),
    'database' => env('MONGODB_DATABASE', 'practice'),
],

Leave DB_CONNECTION set to sqlite for now. Laravel's sessions, cache, and migrations will keep using the default database, while only the models you explicitly point at MongoDB will use the mongodb connection. This separation keeps a practice project simple and avoids surprises.

Step 6: Create Your First Model

php artisan make:model Product

Replace the generated class with a MongoDB-aware model:

<?php

namespace App\Models;

use MongoDB\Laravel\Eloquent\Model;

class Product extends Model
{
    protected $connection = 'mongodb';
    protected $collection = 'products';
    protected $fillable = ['name', 'price', 'category', 'tags', 'specs'];
}

The key difference from a standard Eloquent model is the base class. Import MongoDB\Laravel\Eloquent\Model instead of Illuminate\Database\Eloquent\Model. Everything else, including $fillable, casts, and query builder methods, will feel familiar.

MongoDB creates the database and collection automatically on the first write, so there is no migration to run.

Step 7: Practice with Tinker

Open Laravel's REPL:

php artisan tinker

Create

use App\Models\Product;

Product::create([
    'name'     => 'Laptop',
    'price'    => 85000,
    'category' => 'electronics',
    'tags'     => ['work', 'portable'],
    'specs'    => ['ram' => '16GB', 'storage' => '512GB'],
]);

Notice that tags is an array and specs is a nested object. In a relational database, these would typically need extra tables or JSON columns. Here they are first-class values.

Read

Product::where('price', '>', 50000)->get();
Product::where('specs.ram', '16GB')->first();   // dot notation for nested fields
Product::whereIn('tags', ['work'])->get();      // match inside arrays

Update and Delete

Product::where('name', 'Laptop')->update(['price' => 80000]);
Product::where('name', 'Laptop')->delete();

Verify in the MongoDB Shell

Open a second terminal and inspect the raw documents:

mongosh
use practice
db.products.find().pretty()

This is the most valuable habit for learning. Run a query in Laravel, then look at what actually landed in MongoDB. Seeing both sides builds an accurate mental model of how documents are stored.

Step 8: Your First Aggregation Pipeline

Aggregation is where MongoDB becomes a serious analytics tool. A pipeline passes documents through ordered stages, each transforming the data. This example calculates the average price per category:

Product::raw(fn ($collection) => $collection->aggregate([
    ['$group' => [
        '_id' => '$category',
        'avgPrice' => ['$avg' => '$price'],
        'count' => ['$sum' => 1],
    ]],
    ['$sort' => ['avgPrice' => -1]],
]))->toArray();

The $group stage buckets documents by category and computes the aggregates, and $sort orders the results. From here, the stages worth learning next are $match (filtering early, which improves performance), $project (reshaping output), $unwind (flattening arrays), and $lookup (joining collections).

Troubleshooting Reference

Symptom	Likely Cause and Fix
`Class "MongoDB\Client" not found`	The extension is not enabled for the PHP binary you are using. Run `sudo phpenmod mongodb` and restart FPM if applicable.
`pecl install` fails with a libbson error	You answered `yes` to the system-libraries prompt. Reinstall using the defaults.
PHP warns it cannot load `mongodb.so`	The `.ini` file exists but the extension was never built. Run `sudo phpdismod mongodb`, then reinstall.
`mongod` will not start	Check `sudo journalctl -u mongod -n 50` for the specific error.
Queries return nothing	Confirm the database name in `.env` matches the one you are inspecting in `mongosh`.

Where to Go Next

With a working environment, the most productive next steps are:

Data modeling. Learn when to embed documents versus reference them. This decision shapes performance more than any other.
Indexing. Create indexes for your query patterns and use explain() to confirm they are used.
Deeper aggregation. Build multi-stage pipelines with $match, $lookup, and $unwind against realistic seeded data.
Transactions and replica sets. Multi-document transactions require a replica set, even in local development.

Conclusion

Setting up MongoDB with Laravel on Ubuntu comes down to three moving parts: the database service, the PHP extension, and the Laravel package. Most of the friction sits in the extension build, and it disappears once you accept PECL's defaults. From there, you work with documents through the same Eloquent interface you already use every day, while gaining flexible schemas, nested data, and a powerful aggregation framework.

Mastering Redis from the Command Line: A Hands-On Practice Guide

Md Abu Musa — Tue, 13 Oct 2026 12:51:02 +0000

The fastest way to learn Redis is to type commands, watch the replies, and break things on purpose.

Getting started

Open a terminal, run redis-cli, and confirm the server answers. Use FLUSHDB between sections for a clean slate, but only on a practice instance.

PING                  # PONG
INFO server
INFO memory
INFO keyspace
SELECT 1              # switch to database 1
DBSIZE
CONFIG GET maxmemory

Two shell flags are worth learning on day one: redis-cli -n 2 PING targets a specific database, and redis-cli --raw GET key prints values without quoting or escaping.

Core data types

Most real Redis usage is built from six structures. Run every command, and note each return value: OK, (integer), or nil.

Strings

SET user:1:name "Musa"
GET user:1:name
SET counter 10
INCR counter              # 11
INCRBY counter 5          # 16
APPEND user:1:name " Abu"
MSET a 1 b 2 c 3
MGET a b c
SET lock:x 1 NX EX 30     # only if absent, 30s TTL
SET k v XX                # only if present
GETEX k EX 60

Keys and expiry

EXISTS user:1:name
TYPE user:1:name
EXPIRE user:1:name 60
TTL user:1:name
PERSIST user:1:name
UNLINK k                  # asynchronous delete
SCAN 0 MATCH user:* COUNT 100
OBJECT ENCODING counter   # int, embstr or raw

Compare KEYS * with SCAN, and never use KEYS in production: it blocks the server while it walks the whole keyspace. Then set a 5-second TTL and run TTL repeatedly to watch the key expire.

Hashes

HSET user:1 name Musa age 30 city Dhaka
HGET user:1 name
HMGET user:1 name city
HGETALL user:1
HINCRBY user:1 age 1
HEXISTS user:1 city
HDEL user:1 city
HSCAN user:1 0

Lists

RPUSH queue job1 job2 job3
LPUSH queue job0
LRANGE queue 0 -1
LPOP queue
LTRIM queue 0 99
BLPOP queue 10            # blocking pop; try from a second terminal
LMOVE queue processing LEFT RIGHT

For a reliable queue, move each job with LMOVE queue processing, process it, then remove it with LREM processing 1 job.

Sets

SADD tags:post1 redis db cache
SADD tags:post2 redis golang
SISMEMBER tags:post1 redis
SINTER tags:post1 tags:post2
SUNION tags:post1 tags:post2
SDIFF tags:post1 tags:post2
SPOP tags:post1

Sorted sets

ZADD leaderboard 100 alice 250 bob 175 carol
ZRANGE leaderboard 0 -1 WITHSCORES
ZRANGE leaderboard 0 2 REV WITHSCORES    # top 3 (Redis 6.2+)
ZRANK leaderboard alice
ZINCRBY leaderboard 50 alice
ZRANGEBYSCORE leaderboard 100 200
ZREM leaderboard carol

Sorted sets are the most versatile structure on this list: leaderboards, priority queues, time-ordered indexes and rate limiters all reduce to them.

Beyond the basics

These structures trade generality for extreme efficiency, and each solves one problem very well.

Bitmaps, HyperLogLog and geo

Bitmaps track yes/no flags per user ID in a few bytes each. HyperLogLog counts unique items approximately in about 12 KB, however many there are. Geo commands store coordinates and answer distance and radius queries.

SETBIT login:2026-10-12 1001 1
GETBIT login:2026-10-12 1001
BITCOUNT login:2026-10-12
BITOP AND active:both login:day1 login:day2

PFADD visitors:today u1 u2 u3 u1
PFCOUNT visitors:today          # 3
PFMERGE visitors:week visitors:d1 visitors:d2

GEOADD shops 90.4125 23.8103 "dhaka-a" 91.8123 22.3569 "ctg-a"
GEODIST shops dhaka-a ctg-a km
GEOSEARCH shops FROMLONLAT 90.4 23.8 BYRADIUS 50 km ASC

Streams

Streams are an append-only log with consumer groups, which makes them the durable alternative to Pub/Sub and lists for event processing.

XADD orders * user 1 amount 500
XLEN orders
XRANGE orders - +
XREAD BLOCK 5000 STREAMS orders $

XGROUP CREATE orders workers $ MKSTREAM
XREADGROUP GROUP workers w1 COUNT 1 STREAMS orders >
XACK orders workers <id>
XPENDING orders workers
XCLAIM orders workers w2 60000 <id>
XTRIM orders MAXLEN ~ 1000

Use two terminals: one producer, one consumer-group worker. Kill the worker before it runs XACK, then recover the unacknowledged message with XPENDING and XCLAIM. That exercise teaches more about delivery guarantees than any documentation page.

Messaging and atomicity

Redis is single-threaded for command execution, so a single command is always atomic. The tools below extend that guarantee to groups of commands.

Pub/Sub

In terminal A, subscribe. In terminal B, publish.

# Terminal A
SUBSCRIBE news
PSUBSCRIBE news:*

# Terminal B
PUBLISH news "hello"
PUBSUB CHANNELS
PUBSUB NUMSUB news

Pub/Sub is fire-and-forget: a subscriber that connects late misses earlier messages. Confirm this yourself, then contrast it with Streams, which keep history.

Transactions

MULTI
SET balance 100
DECRBY balance 30
EXEC

WATCH balance             # optimistic locking
MULTI
DECRBY balance 10
EXEC                      # nil if another client changed balance

Trigger a WATCH failure by modifying balance from a second terminal before EXEC. Also note that Redis transactions have no rollback: if one command fails at runtime, the others still run.

Lua scripting

A Lua script runs as one atomic unit, which is the right tool for read-modify-write logic that WATCH makes clumsy.

EVAL "return redis.call('GET', KEYS[1])" 1 user:1:name

# Safe unlock: delete only if the token matches
EVAL "if redis.call('get',KEYS[1])==ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end" 1 lock:x token123

SCRIPT LOAD "return 'hi'"
EVALSHA <sha> 0

Running Redis

Knowing the commands is half the job. The other half is knowing how Redis behaves when memory fills, a process restarts, or a client misbehaves.

Persistence

CONFIG GET save
BGSAVE
LASTSAVE
CONFIG SET appendonly yes
BGREWRITEAOF
INFO persistence

Set a key, run SHUTDOWN SAVE, restart with sudo systemctl restart redis-server, and check that the key survived. Then repeat with persistence disabled and watch the data disappear.

Memory and eviction

CONFIG SET maxmemory 10mb
CONFIG SET maxmemory-policy allkeys-lru
MEMORY USAGE user:1
INFO stats                # evicted_keys, keyspace_hits, keyspace_misses

redis-cli --bigkeys
redis-cli --memkeys

Fill memory with a loop and watch evicted_keys climb. Try noeviction, volatile-lru and allkeys-lfu to see how each policy changes which keys survive.

Monitoring and debugging

MONITOR                   # live command stream; development only
SLOWLOG GET 10
CONFIG SET slowlog-log-slower-than 1000
CLIENT LIST
LATENCY DOCTOR

redis-cli --latency
redis-cli --stat
redis-benchmark -q -n 100000 -c 50

Security and ACLs

CONFIG SET requirepass strongpass
AUTH strongpass
ACL SETUSER reader on >readpass ~cache:* +get +mget
ACL LIST
AUTH reader readpass

Log in as reader and confirm that SET fails with NOPERM. Least-privilege users are one of the cheapest hardening steps Redis offers.

Replication on one machine

Copy the config, change the port, data directory and pidfile, then start a replica:

sudo cp /etc/redis/redis.conf /etc/redis/redis-6380.conf
redis-server /etc/redis/redis-6380.conf --replicaof 127.0.0.1 6379

INFO replication
WAIT 1 100
REPLICAOF NO ONE          # promote the replica

Write on the primary and read on the replica. Then try writing to the replica to see the read-only error.

Real-world patterns

Once the commands feel natural, combine them into the patterns production systems actually use.

Pattern	Commands
Cache-aside	`GET product:5`; on a miss, `SET product:5 <json> EX 300`
Fixed-window rate limiter	`INCR rate:user1:202610121530`, then `EXPIRE` it to 60 seconds; reject above the limit
Distributed lock	`SET lock:order:9 <token> NX PX 10000`; release with the Lua compare-and-delete script
Leaderboard	`ZINCRBY` to score, `ZRANGE ... REV` to read the top N
Session store	Hash `session:<id>`, with `EXPIRE` refreshed on each request
Unique visitors	`PFADD` and `PFCOUNT`
Daily active users	One bitmap per date, combined with `BITOP`
Job queue	List with `BLPOP`, or Streams with consumer groups
Idempotency key	`SET idem:<key> 1 NX EX 86400`

The distributed lock deserves special care. Always store a unique token as the value and release with the Lua script, so one client can never delete a lock another client now holds.

Challenges

Try these without looking anything up. Each one forces you to combine commands you have already met.

Build a sliding-window rate limiter with a sorted set, using ZADD, ZREMRANGEBYSCORE and ZCARD.
Keep a "recently viewed, last 10 items" list per user with LPUSH and LTRIM.
Implement a delayed job queue with a sorted set scored by run timestamp.
Build autocomplete with ZRANGEBYLEX.
Write a Lua script that decrements stock atomically and refuses to go below zero.
Compare the memory used by 10,000 small keys against one hash with 10,000 fields, using MEMORY USAGE.

The last exercise tends to surprise people: small hashes use a compact encoding, so the single hash is often far cheaper.

Conclusion

Redis rewards hands-on practice more than reading. Work through the sections in order, break things deliberately (kill a worker mid-stream, fill memory, fail a WATCH), and finish with the challenges.

Zero-Downtime Schema Changes in PostgreSQL: Adding Columns and Indexes to a 200M-Row Table

Md Abu Musa — Thu, 08 Oct 2026 06:05:46 +0000

You have a PostgreSQL table with 200 million rows. It's serving live traffic. Now you need to add a column or an index.

Run the wrong command and every INSERT, UPDATE, and DELETE hangs until it finishes. On a table this size, that can be hours. Here is how to do it safely.

The core problem: locks

Every DDL statement (CREATE, ALTER, DROP, TRUNCATE) takes a lock on the table. What matters is which lock and for how long.

Analogy: You need to install a divider on a busy highway. Closing the entire road (an ACCESS EXCLUSIVE lock) causes a traffic jam. Working one lane at a time (light locks, small batches) keeps traffic moving.

There is a second, sneakier danger: the lock queue.

If your ALTER TABLE waits behind a long-running query, every new query queues up behind your ALTER. A harmless migration can freeze the whole application.

Part 1: Adding a column

Case 1: Nullable column, no default (safest)

ALTER TABLE orders ADD COLUMN notes text;

This only changes catalog metadata. No rows are rewritten, so it finishes in milliseconds, even with 200M rows.

Case 2: Column with a default

On PostgreSQL 11+, a constant default is also instant:

ALTER TABLE orders ADD COLUMN status text DEFAULT 'pending';

Postgres stores the default in the catalog and serves it virtually when reading old rows.

Two caveats:

On PG 10 or older, this rewrites the entire table. Use the batch approach below.
Volatile defaults such as now() or gen_random_uuid() still trigger a full rewrite on any version.

Case 3: Adding a NOT NULL column

Don't do ADD COLUMN ... NOT NULL directly. Do it in steps:

-- 1. Add nullable column (instant)
ALTER TABLE orders ADD COLUMN region_id bigint;

-- 2. Start writing the value for new rows from your application

-- 3. Backfill old rows in batches (see below)

-- 4. Add a CHECK constraint without scanning the table
ALTER TABLE orders
  ADD CONSTRAINT region_id_not_null
  CHECK (region_id IS NOT NULL) NOT VALID;

-- 5. Validate it. This scans the table but does not block writes.
ALTER TABLE orders VALIDATE CONSTRAINT region_id_not_null;

-- 6. On PG 12+, SET NOT NULL is now instant because a validated CHECK exists
ALTER TABLE orders ALTER COLUMN region_id SET NOT NULL;

-- 7. Drop the redundant CHECK
ALTER TABLE orders DROP CONSTRAINT region_id_not_null;

Backfilling old rows

Never run one giant UPDATE on 200M rows. It creates a huge transaction, bloats the WAL, causes replication lag, and leaves a pile of dead tuples.

Update in small batches instead:

UPDATE orders
SET region_id = 1
WHERE id IN (
  SELECT id FROM orders
  WHERE region_id IS NULL
  LIMIT 10000
  FOR UPDATE SKIP LOCKED
);

Run it in a loop until zero rows are affected. Here's a Go example:

for {
    res, err := db.Exec(`
        UPDATE orders SET region_id = 1
        WHERE id IN (
            SELECT id FROM orders
            WHERE region_id IS NULL
            LIMIT 10000
            FOR UPDATE SKIP LOCKED
        )`)
    if err != nil {
        log.Fatal(err)
    }

    n, _ := res.RowsAffected()
    if n == 0 {
        break
    }

    time.Sleep(100 * time.Millisecond) // let autovacuum and replicas breathe
}

The short sleep between batches keeps replication lag and vacuum pressure under control.

Part 2: Adding an index

The wrong way

CREATE INDEX idx_orders_user_id ON orders(user_id);

This takes a SHARE lock, which blocks all writes for the entire build. On 200M rows, that can mean hours of effective downtime.

The right way: `CONCURRENTLY`

CREATE INDEX CONCURRENTLY idx_orders_user_id ON orders(user_id);

Postgres scans the table twice and picks up changes made in between, without blocking writes. It takes roughly 2-3x longer, but your app keeps running.

Rules for `CONCURRENTLY`

Rule	Why it matters
Cannot run inside a transaction block	Many migration tools wrap migrations in a transaction by default, so you must disable that
A failed build leaves an INVALID index	It slows writes and is useless for reads, so clean it up
Uses a lot of CPU and I/O	Run it off-peak

Laravel example (disable the wrapping transaction):

class AddUserIdIndexToOrders extends Migration
{
    public $withinTransaction = false;

    public function up()
    {
        DB::statement(
            'CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_orders_user_id ON orders(user_id)'
        );
    }

    public function down()
    {
        DB::statement('DROP INDEX CONCURRENTLY IF EXISTS idx_orders_user_id');
    }
}

Cleaning up a failed build

-- Find invalid indexes
SELECT indexrelid::regclass, indisvalid
FROM pg_index
WHERE NOT indisvalid;

-- Drop and retry
DROP INDEX CONCURRENTLY idx_orders_user_id;
CREATE INDEX CONCURRENTLY idx_orders_user_id ON orders(user_id);

Unique indexes

CREATE UNIQUE INDEX CONCURRENTLY idx_orders_ref ON orders(reference_no);

-- Optionally attach it as a constraint (instant)
ALTER TABLE orders
  ADD CONSTRAINT uniq_orders_ref UNIQUE USING INDEX idx_orders_ref;

Part 3: Production safety checklist

1. Always set `lock_timeout`

This is the single most important habit. It prevents the lock-queue disaster:

SET lock_timeout = '3s';
ALTER TABLE orders ADD COLUMN notes text;

If the lock isn't acquired within 3 seconds, the ALTER fails on its own instead of freezing your app. Then you simply retry.

For a long CREATE INDEX CONCURRENTLY, also make sure statement_timeout won't kill it:

SET statement_timeout = 0;

2. Check for long-running transactions first

SELECT pid, now() - xact_start AS duration, state, query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY duration DESC
LIMIT 10;

An old open transaction can make your DDL wait, and everyone queues behind it.

3. Monitor index build progress

SELECT phase, blocks_done, blocks_total,
       round(100.0 * blocks_done / nullif(blocks_total, 0), 1) AS pct
FROM pg_stat_progress_create_index;

4. Check disk space and replication

Make sure you have enough free disk. An index on 200M rows can be several GB or more.
Watch replication lag if you have replicas.
Temporarily raising maintenance_work_mem speeds up the build:

SET maintenance_work_mem = '2GB';

5. Rehearse first

Run the migration on a staging copy with production-sized data and time it before touching production.

Part 4: When the simple way isn't enough

Everything above works because PostgreSQL can do those changes online. But some changes force a full table rewrite that PostgreSQL cannot do without blocking writes: changing a column's data type, re-partitioning a table, or reclaiming heavy bloat.

For these, use the shadow table pattern (also called an online schema change). Tools like gh-ost, pg-osc, pgroll, and pg_repack are built on this idea.

Analogy: You want to renovate a shop that can't close. You build an identical new shop next door with the improvements, move the stock over gradually while mirroring every new sale into both shops, and then swap the signboards in one quick moment.

Step 1: Create the copy with the change applied

CREATE TABLE orders_new (LIKE orders INCLUDING DEFAULTS INCLUDING CONSTRAINTS);
ALTER TABLE orders_new ADD COLUMN region_id bigint;  -- or change a column type, etc.

The table is empty, so this is instant. Don't create indexes yet.

Step 2: Mirror live changes with a trigger

Before copying any data, make sure every new write to orders is also applied to orders_new:

CREATE FUNCTION orders_sync() RETURNS trigger AS $$
BEGIN
  IF TG_OP = 'DELETE' THEN
    DELETE FROM orders_new WHERE id = OLD.id;
    RETURN OLD;
  ELSE
    INSERT INTO orders_new (id, user_id, total /* , ...all columns */)
    VALUES (NEW.id, NEW.user_id, NEW.total)
    ON CONFLICT (id) DO UPDATE
      SET user_id = EXCLUDED.user_id, total = EXCLUDED.total;
    RETURN NEW;
  END IF;
END $$ LANGUAGE plpgsql;

CREATE TRIGGER orders_sync_trg
AFTER INSERT OR UPDATE OR DELETE ON orders
FOR EACH ROW EXECUTE FUNCTION orders_sync();

The trigger comes first so no change can slip through the gap while you copy. Note that the ON CONFLICT (id) clause requires a primary key or unique index on id in orders_new, which INCLUDING CONSTRAINTS does not copy. Create that one index up front.

Step 3: Backfill old rows in small batches

INSERT INTO orders_new (id, user_id, total)
SELECT id, user_id, total
FROM orders
WHERE id > :last_id
ORDER BY id
LIMIT 10000
ON CONFLICT (id) DO NOTHING;

Loop with a short sleep, moving last_id forward each time. ON CONFLICT DO NOTHING ensures the trigger's newer version of a row is never overwritten by an older copied one.

Step 4: Build the remaining indexes on the new table

It's faster to build indexes after the data is loaded. Nobody reads from orders_new yet, so a plain CREATE INDEX is fine here, with no CONCURRENTLY needed.

Step 5: Verify

Compare row counts and spot-check data. Run ANALYZE orders_new so the query planner has fresh statistics.

Step 6: Swap in one short transaction

BEGIN;
SET LOCAL lock_timeout = '3s';
LOCK TABLE orders IN ACCESS EXCLUSIVE MODE;
ALTER TABLE orders RENAME TO orders_old;
ALTER TABLE orders_new RENAME TO orders;
COMMIT;

This takes milliseconds. If it times out, just retry. Afterward, drop the trigger and keep orders_old for a few days as a rollback option.

What makes this tricky

Sequences and ownership: the new table needs the same sequence for id, with correct ownership.
Foreign keys: other tables pointing to orders must be re-pointed, and adding FKs can itself be slow (use NOT VALID, then VALIDATE).
Views, permissions, triggers, partitions: all must be recreated on the new table.
Write overhead: every write happens twice during the process.
Disk space: you temporarily need roughly double the table size, plus indexes.
Hard-coded table names or prepared plans in application code can be affected by the rename.

Should you use it?

For adding a plain column or index, no. It adds risk and cost with no benefit.

Situation	Best approach
Nullable column, or column with constant default	Plain `ALTER TABLE` (instant)
Add an index	`CREATE INDEX CONCURRENTLY`
Change a column's type, or any change that forces a full rewrite	Shadow table
Reclaim heavy table bloat	Shadow table (`pg_repack` works this way)
Re-partition a large table	Shadow table

The shadow table is the heavy tool for changes PostgreSQL can't do online by itself. Reach for it only when the simple way isn't enough.

Cheat sheet

Task	Safe approach
Nullable column	Plain `ADD COLUMN` (instant)
Column with constant default	Plain `ADD COLUMN` on PG 11+ (instant)
NOT NULL column	Add nullable, batch backfill, `CHECK ... NOT VALID`, `VALIDATE`, `SET NOT NULL`
Index	Always `CREATE INDEX CONCURRENTLY`
Any DDL	Set `lock_timeout` first
Bulk data change	Small batches with a short sleep, never one giant `UPDATE`
Column type change, re-partitioning, heavy bloat	Shadow table: copy, mirror with a trigger, swap names

Takeaway

Small locks, small transactions, small batches.

Zero-downtime migrations are not about clever tricks. They are about never holding a heavy lock for long, and never letting your DDL wait in a queue that blocks everyone else.

[Boost]

Md Abu Musa — Sat, 13 Jun 2026 11:28:45 +0000

How to Remove AWS CLI Configuration from Ubuntu - DEV Community

Introduction The AWS Command Line Interface (AWS CLI) is a powerful tool that enables...

dev.to

How to Remove AWS CLI Configuration from Ubuntu

Md Abu Musa — Sat, 13 Jun 2026 11:20:29 +0000

Introduction

The AWS Command Line Interface (AWS CLI) is a powerful tool that enables developers and system administrators to interact with Amazon Web Services directly from the terminal. During setup, users typically configure AWS CLI using the aws configure command, which stores credentials and default settings locally on the system.

There are situations where you may need to remove or update your AWS configuration, such as rotating credentials, switching AWS accounts, decommissioning a development environment, or enhancing security. This guide explains how to safely remove AWS CLI configuration from an Ubuntu system.

Understanding AWS CLI Configuration Files

When you run:

aws configure

AWS CLI stores configuration data in the following files:

~/.aws/credentials
~/.aws/config

credentials file

Contains sensitive authentication information:

[default]
aws_access_key_id = YOUR_ACCESS_KEY
aws_secret_access_key = YOUR_SECRET_KEY

config file

Contains region and output preferences:

[default]
region = ap-northeast-2
output = json

Method 1: Remove All AWS CLI Configuration

If you want to completely remove all configured AWS credentials and settings, delete both files:

rm -f ~/.aws/credentials ~/.aws/config

This will remove:

AWS Access Key ID
AWS Secret Access Key
Default Region
Output Format Preferences

Verify Removal

Run:

aws configure list

If the configuration has been removed successfully, AWS CLI will no longer display configured credentials or region information.

Method 2: Remove a Specific AWS Profile

AWS CLI supports multiple profiles for managing different AWS accounts.

View Existing Profiles

Check your configuration files:

cat ~/.aws/credentials
cat ~/.aws/config

Edit the Files

Open the files with a text editor:

nano ~/.aws/credentials
nano ~/.aws/config

Remove the profile section you no longer need.

Example:

[development]
aws_access_key_id = EXAMPLE
aws_secret_access_key = EXAMPLE

Save the file after removing the profile.

Method 3: Uninstall AWS CLI from Ubuntu

If you no longer need AWS CLI, you can uninstall it completely.

Determine Installation Method

First, check the AWS CLI installation path:

which aws

Check the installed version:

aws --version

Remove AWS CLI Installed via APT

sudo apt remove awscli

Remove AWS CLI Installed via AWS Installer

sudo rm -rf /usr/local/aws-cli
sudo rm -f /usr/local/bin/aws

Security Best Practices

When removing AWS credentials:

Rotate credentials if they were exposed or shared.
Use IAM roles whenever possible instead of long-term access keys.
Regularly audit configured AWS profiles.
Avoid storing credentials in scripts or source code repositories.
Use AWS Secrets Manager or environment variables for sensitive workloads.

Conclusion

Removing AWS CLI configuration on Ubuntu is a straightforward process. Whether you need to clear credentials, delete a specific profile, or uninstall AWS CLI entirely, understanding where AWS stores its configuration helps maintain a secure and organized development environment. Regular credential management is an essential part of AWS security best practices and helps protect your cloud resources from unauthorized access.

cURL: The Swiss Army Knife of Data Transfer

Md Abu Musa — Mon, 26 Jan 2026 06:30:13 +0000

Introduction

curl (Client URL) is one of the most powerful and widely used command-line tools in software engineering. It enables data transfer between a client and a server using various network protocols. From testing REST APIs to downloading files, debugging HTTP requests, and automating workflows, curl is an essential tool for developers, system administrators, and DevOps engineers.

This blog explores what curl is, how it works, its most common use cases, and practical examples that you can apply in real-world scenarios.

What Is cURL?

curl is an open-source command-line tool and library (libcurl) used to transfer data to or from a server using URLs. It supports a wide range of protocols, including:

HTTP / HTTPS
FTP / FTPS
SCP / SFTP
SMTP / POP3 / IMAP
LDAP
MQTT
FILE

The tool is available by default on most Linux and macOS systems and can be installed easily on Windows.

Why cURL Is Important

curl is popular because it is:

Lightweight and fast
Scriptable (perfect for automation)
Protocol-agnostic
Widely supported
Ideal for API testing and debugging

In backend development and DevOps, curl is often the first tool used to verify whether a service or endpoint is working correctly.

Basic cURL Syntax

curl [options] URL

Example:

curl https://example.com

This sends a basic HTTP GET request and prints the response body to the terminal.

Common HTTP Operations with cURL

1. GET Request

curl https://api.example.com/users

Used to retrieve data from a server.

2. POST Request

curl -X POST https://api.example.com/users \
     -H "Content-Type: application/json" \
     -d '{"name":"Musa","email":"musa@example.com"}'

Used to send data to the server, commonly for creating resources.

3. PUT Request

curl -X PUT https://api.example.com/users/1 \
     -H "Content-Type: application/json" \
     -d '{"name":"Updated Name"}'

Used to update existing resources.

4. DELETE Request

curl -X DELETE https://api.example.com/users/1

Used to delete a resource.

Working with Headers

Send Custom Headers

curl -H "Authorization: Bearer TOKEN" \
     -H "Accept: application/json" \
     https://api.example.com/profile

View Response Headers

curl -i https://example.com

Authentication with cURL

Basic Authentication

curl -u username:password https://api.example.com

Bearer Token Authentication

curl -H "Authorization: Bearer YOUR_TOKEN" https://api.example.com

Handling JSON Responses

To pretty-print JSON responses, combine curl with jq:

curl https://api.example.com/users | jq

This is extremely useful when debugging APIs.

File Upload and Download

Download a File

curl -O https://example.com/file.zip

Upload a File

curl -F "file=@image.png" https://api.example.com/upload

Debugging and Verbose Mode

Verbose Output

curl -v https://example.com

This shows:

Request headers
Response headers
TLS handshake details

Very useful for debugging network issues.

Timeouts and Retries

Set Timeout

curl --max-time 10 https://example.com

Retry on Failure

curl --retry 3 https://example.com

Following Redirects

curl -L https://example.com

By default, curl does not follow redirects unless explicitly told.

Using cURL in Automation and Scripts

curl is commonly used in:

CI/CD pipelines
Health checks
Cron jobs
Shell scripts
Server monitoring

Example health check:

curl -f https://api.example.com/health || exit 1

Security Best Practices

Avoid exposing tokens in terminal history
Use environment variables for credentials
Prefer HTTPS over HTTP
Validate SSL certificates (avoid -k in production)

cURL vs Postman

Feature	cURL	Postman
Command-line	✅	❌
Automation	✅	Limited
GUI	❌	✅
Lightweight	✅	❌
CI/CD friendly	✅	❌

Best practice: Use Postman for exploration and curl for automation and production debugging.

Conclusion

curl is an indispensable tool for modern software engineering. Its simplicity, flexibility, and power make it ideal for API testing, system administration, and automation tasks. Mastering curl significantly improves your ability to debug, test, and interact with network services efficiently.

Whether you are a backend engineer, DevOps professional, or software architect, curl deserves a permanent place in your toolkit.

Ubuntu Server Resource Monitoring via Command Line

Md Abu Musa — Sat, 13 Dec 2025 14:52:54 +0000

Monitoring system resources is a critical responsibility for backend engineers, DevOps engineers, and system administrators. Whether you are running a Laravel API, Node.js app, Docker containers, or an AWS EC2 instance, understanding how your Ubuntu server consumes CPU, memory, disk, and network resources helps you:

Detect performance bottlenecks early
Prevent unexpected downtime
Optimize application performance
Make informed scaling decisions

This blog provides a professional, practical, and production-oriented guide to checking system resource usage on an Ubuntu Server using only command-line tools.

1. Why Resource Monitoring Matters

In real-world production environments, issues like:

Slow API responses
Sudden 504 Gateway Timeout errors
Random application crashes
Server freeze or reboot

are often symptoms of resource exhaustion rather than application bugs.

Regular monitoring helps answer critical questions:

Is CPU overloaded?
Is RAM exhausted or swapping?
Is disk space full?
Is disk I/O causing delays?
Which process is consuming the most resources?

2. Quick System Health Overview

Command

uptime

What it shows

System running time
Number of logged-in users
Load average (1, 5, 15 minutes)

How to interpret load average

If your server has 4 CPU cores:

Load average ≈ 4 → normal
Load average > 4 → CPU under pressure
Load average >> 4 → serious performance issue

This is the fastest health check command you should use first.

3. Real-Time CPU and Memory Monitoring

Using `top`

top

Key metrics

%CPU → CPU usage per process
%MEM → Memory usage per process
load average → overall CPU load

Useful shortcuts

Shift + P → sort by CPU usage
Shift + M → sort by memory usage
q → quit

top is available by default on all Ubuntu servers.

Using `htop` (Recommended)

sudo apt install htop
htop

Why `htop` is better

Color-coded CPU and memory bars
Easy process killing
Tree view of processes
Mouse support

For daily production monitoring, htop is strongly recommended.

4. Memory (RAM) Usage Analysis

Command

free -h

Key fields explained

total → Total RAM
used → Used memory
available → Memory available for new processes

⚠️ Important: Always focus on available, not free. Linux uses free memory for caching, which is normal and healthy.

If available memory is very low, your server may start swapping or killing processes.

5. Disk Usage Monitoring

Overall disk usage

df -h

Shows:

Total disk size
Used space
Available space
Mount points

⚠️ If disk usage reaches 90%+, services like MySQL, Redis, or Docker may fail.

Directory-wise disk usage

du -sh /path/to/directory

Example:

du -sh /var/www
du -sh /var/log

This helps identify which folders are consuming disk space.

6. CPU Information and Core Count

Command

lscpu

Provides:

CPU architecture
Number of cores
Threads per core
CPU model

Knowing the core count is essential for correctly interpreting load average.

7. Network Usage Monitoring

Basic network statistics

ip -s link

Shows transmitted and received packets per network interface.

Real-time network monitoring

sudo apt install nload
nload

Useful when:

APIs feel slow
Upload/download speed is suspicious
External service calls timeout

8. Disk I/O Performance (Often Overlooked)

High disk I/O wait can slow down applications even when CPU and RAM look normal.

Command

sudo apt install sysstat
iostat

Look for:

High %iowait
Slow read/write rates

This is critical for database-heavy applications.

9. Identify Resource-Hungry Processes

Top memory-consuming processes

ps aux --sort=-%mem | head

Top CPU-consuming processes

ps aux --sort=-%cpu | head

This is extremely useful during production incidents.

10. One-Command Live Summary

Command

vmstat 1

Updates every second and shows:

CPU usage
Memory usage
Swap activity
Disk I/O

A powerful command for advanced troubleshooting.

11. Recommended Monitoring Workflow (Production)

uptime → Quick health check
htop → Live CPU & memory monitoring
free -h → Memory availability
df -h → Disk usage
iostat → Disk I/O issues
ps aux → Identify problematic processes

12. Conclusion

Command-line monitoring tools are lightweight, fast, and reliable, making them perfect for Ubuntu servers in production.

By mastering these commands, you can:

Debug performance issues confidently
Reduce downtime
Communicate system health clearly to your team
Grow from a backend engineer into a strong DevOps-aware professional

Regular monitoring is not optional — it is a core engineering habit.

[Boost]

Md Abu Musa — Fri, 12 Dec 2025 03:32:21 +0000

Why Your EC2 Server Suddenly Stops Responding — And How to Bulletproof Laravel & Node Apps - DEV Community

Managing multiple Laravel and Node.js applications on a single EC2 instance is common in small and...

dev.to

Why Your EC2 Server Suddenly Stops Responding — And How to Bulletproof Laravel & Node Apps

Md Abu Musa — Tue, 09 Dec 2025 16:50:34 +0000

Managing multiple Laravel and Node.js applications on a single EC2 instance is common in small and mid-sized teams. However, when several applications share the same resources, one heavy operation can freeze the entire server — causing all domains to go down at the same time.

Recently, we faced a similar issue:
all test and development domains stopped responding simultaneously, even though no code changes were deployed on some of them. The root cause was not immediately clear.

After detailed inspection, the problem turned out to be resource exhaustion caused by a Node build process running directly on the server.

This article explains why this happens, how to diagnose it, and what steps you should take to prevent it permanently.

What Actually Happened?

According to the internal investigation, the issue was caused by:

“The server was unable to load the build and hung the system.”

When someone runs npm run build or yarn build directly inside an EC2 instance — especially an instance with limited RAM (1–2GB) — Node consumes a large amount of memory to compile and optimize frontend assets.

As memory usage increases, the server begins to:

Swap aggressively
Kill processes
Freeze PHP-FPM
Stall Nginx worker processes
Hang SSH access
Stop responding to all HTTP requests

Because all Laravel apps, Node apps, queue workers, and socket services run under the same OS, the entire system becomes unresponsive.

Why a Node Build Freezes Small EC2 Instances

Node.js build tools like Vite, Webpack, or Next.js require high memory to:

Minify large JS bundles
Optimize images
Handle TypeScript
Perform tree-shaking
Build multiple targets

On servers with low memory, this triggers:

1. 100% CPU consumption

Node compilers go full throttle.

2. RAM exhaustion

Node often needs 512 MB – 2 GB per build.
This is too heavy for small EC2 instances.

3. Out-of-Memory (OOM) kills

The kernel automatically kills PHP-FPM or MySQL first instead of Node.

4. Nginx stops responding

Since PHP-FPM dies, Nginx returns 502/504 or hangs completely.

5. SSH becomes slow

If swap memory also fills up, the OS stops scheduling tasks.

This chain reaction brings down every domain hosted on the server.

How to Prevent This Problem in the Future

Here are practical and immediate measures to avoid similar outages.

1. Never Build Frontend Code on Production or Test Servers

Instead:

Build locally
Build in CI/CD
Upload only the final dist/ or build/ folder
Deploy the compiled assets

This alone prevents 80% of such incidents.

2. Add a 2GB Swap File

If you're using a small EC2 instance (t2.micro, t3.small, etc.), create a swap file:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo "/swapfile swap swap defaults 0 0" | sudo tee -a /etc/fstab

Swap helps the OS avoid crashing when memory runs out.

3. Limit Node.js Memory Usage (PM2 Protection)

If apps are running under PM2, apply memory protection:

pm2 restart <app> --max-memory-restart=300M

Or apply to all:

pm2 restart all --max-memory-restart=300M

This prevents any single Node app from consuming all memory.

4. Restart PHP-FPM & Nginx During High Load

If the server slows down or freezes:

sudo systemctl restart php8.1-fpm
sudo systemctl restart nginx

This often restores service instantly.

5. Monitor Real-Time Resource Usage with htop

Install:

sudo apt install htop

Run:

htop

This lets you identify:

Which process is consuming CPU
Which service is consuming RAM
Stuck or zombie processes

6. Use PM2 Startup to Ensure Node Apps Auto-Restart on Reboot

pm2 startup
pm2 save

This ensures Node apps come back automatically after a server reboot.

7. Use a Deployment Pipeline

The most reliable long-term solution:

GitHub Actions
GitLab CI
Bitbucket Pipelines
Jenkins

Build assets before deploying, not on the server.

Conclusion

When multiple applications share a single EC2 instance, one heavy task — such as a Node build — can overload system resources and freeze the entire machine. This can bring down all domains and services at once.

To prevent this, teams should:

Avoid running builds directly on servers
Add swap memory
Limit Node memory usage
Monitor resource consumption
Use CI/CD pipelines

By applying these preventive measures, you ensure stable performance and avoid sudden downtime in development, test, or even production environments.

[Boost]

Md Abu Musa — Thu, 02 Oct 2025 13:04:28 +0000

How I Optimized a Laravel API 287x Faster: From 27s to Under 100ms - DEV Community

Transforming a sluggish patient list API into a lightning-fast, production-ready endpoint through...

dev.to

How I Optimized a Laravel API 287x Faster: From 27s to Under 100ms

Md Abu Musa — Thu, 02 Oct 2025 13:01:22 +0000

Transforming a sluggish patient list API into a lightning-fast, production-ready endpoint through strategic database optimization and response streamlining.

The Problem: A Performance Nightmare

Picture this: You're working on a healthcare application with a patient list API that's taking 27+ seconds to load just 600 patients. Users are frustrated, the database is overwhelmed, and your server costs are skyrocketing. This was the reality I faced when analyzing our patientList API.

Initial Performance Metrics (The Bad News)

Response Time: 27.43 seconds 😱
Database Queries: 4,440+ queries
Model Instantiations: 5,320+ objects
Memory Usage: 20MB
User Experience: Completely unusable

The API was suffering from the classic N+1 query problem on steroids, with additional issues like unnecessary data transfer and missing database indexes.

The Investigation: Root Cause Analysis

1. The N+1 Query Monster

// The problematic code (simplified)
foreach($patientData as $key => $pd) {
    $pd->userInfo->user_uuid;           // Query 1 per patient
    $pd->officeInfo->office_name;       // Query 2 per patient
    $this->findPatientDefaultData(...); // Query 3 per patient
    $this->findPatientInsurance(...);   // Query 4 per patient
    // ... and so on
}

For 600 patients, this meant 4,440+ individual database queries just in the foreach loop!

2. Unnecessary Data Transfer

The API was returning 27+ fields per patient, including:

Personal details (SSN, addresses, BMI, weight)
Insurance information
Questionnaire data
Profile assets
Referral information

Most of this data wasn't being used by the frontend.

3. Missing Database Indexes

Critical columns lacked proper indexing, causing full table scans on every query.

The Solution: A Multi-Layered Optimization Strategy

Phase 1: Eliminate N+1 Queries with Eager Loading

// Before: N+1 queries
foreach($patientData as $key => $pd) {
    $pd->userInfo->user_uuid; // Individual query per patient
}

// After: Batch loading with eager loading
$query = PatientUnderOffice::with([
    'userInfo:id,user_uuid,email,type',
    'officeInfo:id,office_name'
])->where('dentist_office_id', $dentist_office_id);

// Only load clinical visits in batch (for last_clinical_visit field)
$clinicalVisits = VisitFormMiscellaneousNote::select('patient_profile_id', 'date')
    ->whereIn('patient_profile_id', $patientProfileIds)
    ->whereIn('id', function($query) use ($patientProfileIds) {
        $query->select(DB::raw('MAX(id)'))
            ->from('visit_form_miscellaneous_notes')
            ->whereIn('patient_profile_id', $patientProfileIds)
            ->groupBy('patient_profile_id');
    })->get()->keyBy('patient_profile_id');

Phase 2: Streamline Response Structure

I identified that the frontend only needed 15 essential fields out of 42 total fields. Here's what I removed:

// Removed 27 unnecessary fields:
$removedFields = [
    'referred_by', 'assets', 'referral_type', 'referred_time', 'referred_note',
    'dentist_office', 'gender', 'marital_status', 'height', 'ssn',
    'address_one', 'address_two', 'city', 'state', 'zipCode', 'email',
    'bmi', 'weight', 'self_pay_status', 'created_at', 'updated_at',
    'employer_details', 'questionnaire_id', 'symptoms', 'epworth',
    'treatment', 'history', 'insurance', 'temp_updated_value'
];

// Kept only essential fields:
$essentialFields = [
    'id', 'user_id', 'user_uuid', 'patient_profile_id', 'dentist_office_id',
    'title', 'first_name', 'middle_name', 'last_name', 'preferred_name',
    'type', 'dob', 'phone_numbers', 'status', 'last_clinical_visit'
];

Phase 3: Add Strategic Database Indexes

// Migration: Add performance indexes
Schema::table('patient_under_offices', function (Blueprint $table) {
    $table->index('dentist_office_id');
    $table->index('status');
    $table->index('created_at');
    $table->index(['first_name', 'last_name']);
    $table->index(DB::raw('phone_numbers(50)'));
    $table->index('patient_profile_id');
});

Schema::table('users', function (Blueprint $table) {
    $table->index('email');
    $table->index('user_uuid');
});

// ... and more strategic indexes

Phase 4: Optimize Model Relationships

// Optimized relationships with selective field loading
public function userInfo()
{
    return $this->belongsTo('App\Models\User', 'user_id', 'id')
        ->select('id', 'user_uuid', 'email', 'type');
}

public function officeInfo()
{
    return $this->belongsTo('App\Models\DentistOfficeProfile', 'dentist_office_id', 'id')
        ->select('id', 'office_name');
}

The Results: From Nightmare to Dream

Performance Transformation

Metric	Before	After	Improvement
Response Time	27.43s	95.72ms	99.7% faster
Database Queries	4,440+	10	99.8% reduction
Model Instantiations	5,320+	1,796	66% reduction
Memory Usage	20MB	8MB	60% reduction
Response Size	Large	~2KB	70% smaller

Real-World Impact

User Experience: From completely unusable to instant loading
Server Costs: Massive reduction in database load
Scalability: Can now handle 10x more concurrent users
Maintenance: Cleaner, more focused codebase

Key Lessons Learned

1. Always Profile Before Optimizing

Use Laravel Debugbar or similar tools to identify the real bottlenecks. Don't guess!

2. N+1 Queries Are Performance Killers

Eager loading and batch queries should be your first optimization targets.

3. Less Data = Better Performance

Only return what the frontend actually needs. Every unnecessary field costs bandwidth and processing time.

4. Database Indexes Are Critical

Proper indexing can make the difference between a query taking 1ms vs 1000ms.

5. Measure Everything

Before and after metrics are crucial for proving the value of your optimizations.

Tools and Techniques Used

Laravel Debugbar: For performance profiling
Eager Loading: with() method for relationship optimization
Batch Queries: whereIn() for bulk data loading
Selective Field Loading: select() to limit data transfer
Database Indexes: Strategic indexing for query optimization
Response Streamlining: Removing unnecessary data fields

Conclusion

This optimization transformed a completely unusable API into a lightning-fast, production-ready endpoint. The key was taking a systematic approach:

Profile to identify bottlenecks
Eliminate N+1 queries with eager loading
Streamline the response structure
Index the database properly
Measure the results

The result? An API that's 287x faster and uses 99.8% fewer database queries. Sometimes the biggest performance wins come from the simplest optimizations.

Deploy Laravel on AWS EC2 with RDS MySQL and NGINX

Md Abu Musa — Tue, 05 Aug 2025 16:50:13 +0000

Setting up a Laravel application on AWS is a powerful way to scale your web applications in a secure and cloud-native environment. This guide walks you through deploying Laravel on an Ubuntu-based EC2 instance, connecting it to an Amazon RDS MySQL database, and using NGINX as the web server.

Prerequisites

Make sure you have the following:

✅ AWS EC2 instance (Ubuntu 22.04+ recommended)
✅ Amazon RDS MySQL database (accessible to EC2)
✅ Security Groups properly configured (EC2 <-> RDS: port 3306)
✅ NGINX installed on EC2
✅ SSH terminal access to EC2 (e.g., Termius)
✅ Laravel knowledge (Composer installed)

Step 1: Update Your Server & Install PHP and Required Extensions

sudo apt update && sudo apt upgrade -y
sudo apt install php php-fpm php-mysql php-xml php-mbstring php-curl php-zip unzip curl git -y

Step 2: Install Composer (PHP Dependency Manager)

cd ~
curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer
composer --version

Step 3: Create Laravel Project

cd /var/www/
sudo composer create-project laravel/laravel myapp
sudo chown -R ubuntu:ubuntu myapp

Tip: Replace myapp with your desired app folder name.

Step 4: Configure Laravel to Use Amazon RDS

Edit the .env file:

nano /var/www/myapp/.env

Update the DB connection settings:

DB_CONNECTION=mysql
DB_HOST=your-rds-endpoint.amazonaws.com
DB_PORT=3306
DB_DATABASE=yourdbname
DB_USERNAME=yourdbuser
DB_PASSWORD=yourdbpassword

Step 5: Generate Laravel App Key & Run Migration

Ensure the Laravel CLI (artisan) has permission to write logs:

sudo chown -R ubuntu:ubuntu /var/www/myapp

Then run:

cd /var/www/myapp
php artisan key:generate
php artisan migrate

✅ You should see success messages for both.

Step 6: Stop Apache (If Installed) & Configure NGINX

Apache often comes pre-installed — stop and disable it:

sudo systemctl stop apache2
sudo systemctl disable apache2

Create a new NGINX config:

sudo nano /etc/nginx/sites-available/laravel

Paste the following (replace <your-ip> and php8.3 if needed):

server {
    listen 80;
    server_name <your-ec2-public-ip>;

    root /var/www/myapp/public;

    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    location ~ /\.ht {
        deny all;
    }
}

Enable the Laravel site:

sudo ln -s /etc/nginx/sites-available/laravel /etc/nginx/sites-enabled/
sudo rm /etc/nginx/sites-enabled/default

Test and restart NGINX:

sudo nginx -t
sudo systemctl restart nginx

Step 7: Set Folder Permissions for Runtime

sudo chown -R www-data:www-data /var/www/myapp
sudo chmod -R 775 /var/www/myapp/storage
sudo chmod -R 775 /var/www/myapp/bootstrap/cache

Step 8: Visit Your Application

Go to your EC2 public IP in a browser:

http://<your-ec2-public-ip>

You should see the Laravel welcome page.

DEV Community: Md Abu Musa

Getting Started with MongoDB and Laravel 13 on Ubuntu 24.04: A Practical Setup Guide

What You Will Build

Step 1: Install MongoDB 8.0

Step 2: Prepare PHP

Step 3: Install the PHP MongoDB Extension

The Pitfall: Do Not Answer "yes" to PECL's Prompts

Step 4: Create the Laravel Project

Step 5: Configure the Connection

Step 6: Create Your First Model

Step 7: Practice with Tinker

Create

Read

Update and Delete

Verify in the MongoDB Shell

Step 8: Your First Aggregation Pipeline

Troubleshooting Reference

Where to Go Next

Conclusion

Mastering Redis from the Command Line: A Hands-On Practice Guide

Getting started

Core data types

Strings

Keys and expiry

Hashes

Lists

Sets

Sorted sets

Beyond the basics

Bitmaps, HyperLogLog and geo

Streams

Messaging and atomicity

Pub/Sub

Transactions

Lua scripting

Running Redis

Persistence

Memory and eviction

Monitoring and debugging

Security and ACLs

Replication on one machine

Real-world patterns

Challenges

Conclusion

Zero-Downtime Schema Changes in PostgreSQL: Adding Columns and Indexes to a 200M-Row Table

The core problem: locks

Part 1: Adding a column

Case 1: Nullable column, no default (safest)

Case 2: Column with a default

Case 3: Adding a NOT NULL column

Backfilling old rows

Part 2: Adding an index

The wrong way

The right way: CONCURRENTLY

Rules for CONCURRENTLY

Cleaning up a failed build

Unique indexes

Part 3: Production safety checklist

1. Always set lock_timeout

2. Check for long-running transactions first

3. Monitor index build progress

4. Check disk space and replication

5. Rehearse first

Part 4: When the simple way isn't enough

Step 1: Create the copy with the change applied

Step 2: Mirror live changes with a trigger

Step 3: Backfill old rows in small batches

Step 4: Build the remaining indexes on the new table

Step 5: Verify

Step 6: Swap in one short transaction

What makes this tricky

Should you use it?

Cheat sheet

Takeaway

[Boost]

How to Remove AWS CLI Configuration from Ubuntu - DEV Community

How to Remove AWS CLI Configuration from Ubuntu

Introduction

Understanding AWS CLI Configuration Files

credentials file

The right way: `CONCURRENTLY`

Rules for `CONCURRENTLY`

1. Always set `lock_timeout`

Using `top`

Using `htop` (Recommended)

Why `htop` is better