DEV Community: devTalk

Laravel Migrations: Add Foreign Keys Without Locking

devTalk — Fri, 02 Oct 2026 14:44:59 +0000

Part 1 covered indexes and Part 2 covered columns. The next Laravel migrations most teams get wrong are the ones that tie two tables together: foreign keys and check constraints.

A foreign key looks like metadata — a rule the database enforces, not data it stores. But adding one to an existing table means scanning every row in the child table to prove the rule already holds, and that scan happens under a lock. On a busy orders table referencing a busy customers table, that's two tables at risk from one migration.

Schema::table('orders', function (Blueprint $table) {
    $table->foreignId('customer_id')->constrained();
});

This article covers what that migration actually does on MySQL and PostgreSQL, the two-step pattern that avoids blocking writes, and the cascading-delete mistake that has nothing to do with locking at all.

PostgreSQL: a lighter lock than you'd expect, still a full scan

Adding a foreign key constraint in Postgres doesn't take the heaviest lock available. Most forms of ADD CONSTRAINT take an ACCESS EXCLUSIVE lock, but ADD FOREIGN KEY specifically only requires SHARE ROW EXCLUSIVE — and it takes that same lock on both tables, the one gaining the constraint and the one it references.

SHARE ROW EXCLUSIVE still blocks every INSERT, UPDATE, and DELETE on both tables for the duration of the scan, even though it's lighter than ACCESS EXCLUSIVE. On a large orders table, that scan is the whole problem: Postgres has to walk every existing row to confirm it satisfies the new constraint before it can finish adding it.

The fix is the same shape as the NOT NULL pattern from Part 2: split the constraint from its validation.

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Support\Facades\DB;

return new class extends Migration
{
    public function up(): void
    {
        // Step 1: add the constraint without checking existing rows.
        // Still takes SHARE ROW EXCLUSIVE, but only briefly — no scan.
        DB::statement('
            ALTER TABLE orders
            ADD CONSTRAINT orders_customer_id_foreign
            FOREIGN KEY (customer_id) REFERENCES customers (id)
            NOT VALID
        ');

        // Step 2: validate separately. This does the actual scan,
        // but only takes SHARE UPDATE EXCLUSIVE — it does not block writes.
        DB::statement('ALTER TABLE orders VALIDATE CONSTRAINT orders_customer_id_foreign');
    }

    public function down(): void
    {
        DB::statement('ALTER TABLE orders DROP CONSTRAINT orders_customer_id_foreign');
    }
};

Run step 1 as part of your normal deploy — it's fast. Run step 2 separately, during a quiet period if the table is large enough that the scan takes real time, since it's safe to run any time after step 1 without blocking the app.

Laravel's schema builder doesn't currently expose a fluent NOT VALID modifier for foreign keys the way it does online() for indexes, so this one stays as raw DB::statement() calls regardless of Laravel version.

MySQL: online by default, with one setting you'll likely need

MySQL's story here is better news. Adding a foreign key on InnoDB can use the same ALGORITHM=INPLACE, LOCK=NONE online DDL from Part 1:

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    public function up(): void
    {
        if (Schema::hasColumn('orders', 'customer_id') && $this->hasForeignKey()) {
            return;
        }

        DB::statement('SET SESSION lock_wait_timeout = 5');

        // Adding a foreign key needs foreign_key_checks off for this
        // session, or ALGORITHM=INPLACE is rejected outright.
        DB::statement('SET SESSION foreign_key_checks = 0');

        try {
            DB::statement('
                ALTER TABLE orders
                ADD CONSTRAINT orders_customer_id_foreign
                FOREIGN KEY (customer_id) REFERENCES customers (id),
                ALGORITHM=INPLACE, LOCK=NONE
            ');
        } finally {
            DB::statement('SET SESSION foreign_key_checks = 1');
            DB::statement('SET SESSION lock_wait_timeout = DEFAULT');
        }
    }

    public function down(): void
    {
        DB::statement('
            ALTER TABLE orders
            DROP FOREIGN KEY orders_customer_id_foreign,
            ALGORITHM=INPLACE, LOCK=NONE
        ');
    }

    private function hasForeignKey(): bool
    {
        return DB::table('information_schema.table_constraints')
            ->where('table_schema', DB::getDatabaseName())
            ->where('table_name', 'orders')
            ->where('constraint_name', 'orders_customer_id_foreign')
            ->exists();
    }
};

The foreign_key_checks = 0 line is the part most examples skip. Without it, MySQL rejects ALGORITHM=INPLACE on a foreign key addition outright with an error, because validating referential integrity against existing rows is exactly the check that algorithm normally skips doing inline. Turning checks off for the session lets the in-place algorithm proceed; MySQL still builds the constraint correctly, it just doesn't re-verify every existing row against it in the same blocking way a COPY-algorithm rebuild would.

Setting foreign_key_checks = 0 is a session-level setting in the code above, not a global one — it only affects the connection running this migration, not concurrent queries from your application.

The metadata lock trap from Part 1 applies here too, and arguably matters more: a foreign key's ALTER has to coordinate with two tables, so a long-running transaction on either orders or customers can stall it.

Check constraints: the same two-step pattern

Check constraints follow Postgres's general rule rather than the foreign-key exception: adding one with ADD CONSTRAINT ... CHECK (...) takes a full ACCESS EXCLUSIVE lock if you validate it immediately, because by default Postgres scans the table to confirm every row passes. NOT VALID works here too, and the same two-step split applies:

-- Step 1: instant, no scan.
ALTER TABLE orders
ADD CONSTRAINT orders_total_positive
CHECK (total >= 0) NOT VALID;

-- Step 2: does the scan, takes SHARE UPDATE EXCLUSIVE only.
ALTER TABLE orders VALIDATE CONSTRAINT orders_total_positive;

This is the same mechanism Part 2 used to add NOT NULL to an existing column without a blocking scan — a CHECK (col IS NOT NULL) constraint, validated separately, then promoted. Foreign keys, check constraints, and NOT NULL all converge on the same underlying trick in Postgres: separate "define the rule" from "prove existing data follows it."

The gotcha that isn't about locking: cascading deletes on hot tables

Once the foreign key exists, onDelete('cascade') changes what a single DELETE does at runtime, every time, for the life of the constraint:

Schema::table('orders', function (Blueprint $table) {
    $table->foreignId('customer_id')
        ->constrained()
        ->onDelete('cascade');
});

Deleting one customer with 50,000 historical orders now deletes 50,001 rows in a single transaction, each one individually checked and logged. On MySQL that's one long-held lock on the orders table for the whole cascade; on Postgres it's one long transaction that can block autovacuum and hold back replication while it runs. Neither database warns you about this at migration time — the constraint itself is cheap to add, and the cost only shows up the first time someone deletes a parent row with a lot of children.

For high-volume child tables, onDelete('restrict') (the default) paired with an explicit, chunked application-level delete is usually safer than cascade, precisely because it puts the pacing under your control instead of the database's.

Quick reference

Operation	Lock taken	Safe pattern
Add FK (PostgreSQL)	SHARE ROW EXCLUSIVE on both tables, held for the scan	NOT VALID, then VALIDATE CONSTRAINT separately
Add CHECK constraint (PostgreSQL)	ACCESS EXCLUSIVE if validated immediately	NOT VALID, then VALIDATE CONSTRAINT separately
Add FK (MySQL/InnoDB)	None, with ALGORITHM=INPLACE, LOCK=NONE	Requires foreign_key_checks=0 for the session
onDelete('cascade') on a hot table	Long-held lock/transaction at delete time, not add time	Prefer restrict() + chunked application deletes

Before you run it in production

Run php artisan migrate --pretend and confirm NOT VALID or ALGORITHM=INPLACE, LOCK=NONE appears in the SQL. On Postgres, run the VALIDATE CONSTRAINT step as its own migration so you control when the table scan happens. On MySQL, remember foreign_key_checks = 0 is required for the in-place algorithm to be accepted at all. Before adding onDelete('cascade') to a high-volume relationship, ask what a single parent delete will actually do to the child table at 2am, not just whether the migration runs cleanly.

Originally published on DEV Talk.

Laravel Migrations: Add & Change Columns Without Downtime

devTalk — Thu, 01 Oct 2026 18:10:27 +0000

Part 1 covered indexes. The next place teams get surprised in production is the up() method sitting right above the index migration: adding a column, backfilling it, and eventually making it required. Each of those three steps can lock a table for a different reason, and the fix for one can be the wrong fix for another.

This part covers what's actually safe to run directly, what needs to be split into stages, and why ->change() deserves more suspicion than ->index() ever did.

Adding a column: usually cheap, except when it isn't

A plain nullable column with no default is the safe case everywhere. Postgres treats it as a metadata-only change; recent MySQL and MariaDB can add it "instantly" without touching existing rows.

Schema::table('orders', function (Blueprint $table) {
   $table->string('tracking_number')->nullable();
});

Two things turn this cheap operation into a table rewrite:

ANOT NULLcolumn with no default, on old MySQL/MariaDB. MySQL 8.0.12+ and MariaDB 10.3.2+ support ALGORITHM=INSTANT for this case, so it's fast. Anything older rewrites the whole table under a lock while every row gets a value, which blocks reads and writes for minutes on a large table.

A volatile default on PostgreSQL. ADD COLUMN approved_at TIMESTAMPTZ DEFAULT now() looks as trivial as DEFAULT false, but it isn't. A constant default (false, 0, a literal string) is metadata-only on Postgres 11+: the value is returned lazily until the table is rewritten anyway. A volatile default — now(), random(), a subquery — returns a different value per row, so Postgres has no choice but to rewrite every row immediately, under an ACCESS EXCLUSIVE lock, on every version.

The safe pattern for both cases is the same: split the default out of the column addition.

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
   public function up(): void
   {
       // Step 1: add the column with no default, no NOT NULL.
       // Metadata-only on Postgres and modern MySQL/MariaDB.
       Schema::table('orders', function (Blueprint $table) {
           $table->timestampTz('approved_at')->nullable();
       });

       // Step 2: set the default for *future* inserts only.
       // Existing rows stay NULL — no rewrite, no backfill here.
       DB::statement('ALTER TABLE orders ALTER COLUMN approved_at SET DEFAULT NULL');
   }

   public function down(): void
   {
       Schema::table('orders', function (Blueprint $table) {
           $table->dropColumn('approved_at');
       });
   }
};

Backfilling the existing rows is a separate concern — covered in Part 5 of this series — because looping an UPDATE over millions of rows in a migration's up() has its own locking and transaction-length problems.

Instant column operations (Laravel 12/13, MySQL)

Laravel's schema builder can now ask MySQL explicitly for its instant algorithm:

Schema::table('orders', function (Blueprint $table) {
   $table->string('tracking_number')->nullable()->instant();
});

Chaining instant() onto a column requests MySQL's INSTANT algorithm, which performs certain schema changes without a full table rebuild regardless of table size. It only works for columns appended to the end of the table, so it can't be combined with after() or first(), and not every column type or operation supports it — if the operation is incompatible, MySQL raises an error rather than silently falling back to a slower algorithm.

It can be combined with lock() the same way index operations can:

$table->string('tracking_number')->nullable()->instant()->lock('none');

This doesn't change anything about PostgreSQL, which has no equivalent concept — on Postgres, "fast" simply means metadata-only, as described above.

->change(): the one that looks safe and usually isn't

change() is the method most likely to cause an incident, because the code reads like a one-line fix:

Schema::table('users', function (Blueprint $table) {
   $table->string('bio', 1000)->change(); // was VARCHAR(255)
});

Three separate problems hide behind that one line.

1. It silently drops every modifier you don't repeat

As of Laravel 11, changing a column requires you to include every modifier you want to keep — any attribute not explicitly restated is dropped, even if a previous migration set it. This is a behavior change from Laravel 10, where unlisted modifiers were retained.

// If `votes` was unsigned, had a default of 0, and a comment —
// and you only write this — all three are gone after the migration runs.
Schema::table('users', function (Blueprint $table) {
   $table->integer('votes')->nullable()->change();
});

// Correct: restate everything you want to keep.
Schema::table('users', function (Blueprint $table) {
   $table->integer('votes')->unsigned()->default(0)->comment('my comment')->nullable()->change();
});

This isn't a locking issue, it's a data-definition footgun, but it belongs in this article because it's the thing most likely to bite you the first time you touch change() in a Laravel 11+ app. Laravel 11 also removed the doctrine/dbal dependency that older versions needed for change() to work at all — if you're upgrading from Laravel 10 or earlier, you can drop that package from composer.json once you're on 11+.

2. It's usually a full table rewrite

Changing a column's type — string to text, integer to bigInteger, resizing a varchar — forces most databases to rewrite every row to verify the new type fits, under an exclusive lock for the duration. There's no CONCURRENTLY or LOCK=NONE equivalent for a type change in either MySQL or PostgreSQL; this is one of the few operations covered in this series that doesn't have an online-DDL escape hatch within plain SQL.

The practical workaround is to not change the column's type in place at all: add a new column with the correct type, backfill it, cut the application over to it, then drop the old column in a later migration. That's slower to ship but it never blocks the table.

3. PostgreSQL needs an explicit cast for some type changes

When the new type can't be implicitly cast from the old one, Postgres needs to be told how to convert each existing value, using the using modifier:

Schema::table('users', function (Blueprint $table) {
   $table->date('birthday')->using('birthday::date')->change();
});

Leaving this off when the implicit cast doesn't exist fails the migration outright — which is actually the safer failure mode, since you find out in CI rather than mid-table-rewrite in production.

Adding NOT NULL to an existing column

This is a different operation from adding a new NOT NULL column, and it's the one most commonly underestimated because the column already exists and already has data.

MySQL: ALTER TABLE ... MODIFY COLUMN ... NOT NULL scans the table to confirm no existing row is null, and on InnoDB this is an online operation in modern versions — but it still has to scan, so it takes time proportional to table size and can still be blocked by the metadata lock issue from Part 1.

PostgreSQL: SET NOT NULL scans the entire table to verify no nulls exist, holding the lock for the whole scan. On Postgres 12+, there's a two-step way around this: add a NOT VALID check constraint first (which doesn't scan existing rows), validate it separately (which scans but only takes a lighter lock that doesn't block writes), then SET NOT NULL — which, once a validated check constraint already proves the column has no nulls, skips its own table scan entirely.

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Support\Facades\DB;

return new class extends Migration
{
   public $withinTransaction = false;

   public function up(): void
   {
       // Step 1: add the constraint without checking existing rows.
       DB::statement("
           ALTER TABLE orders
           ADD CONSTRAINT orders_status_not_null
           CHECK (status IS NOT NULL) NOT VALID
       ");

       // Step 2: validate separately — scans the table, but only
       // takes a SHARE UPDATE EXCLUSIVE lock, not an exclusive one.
       DB::statement('ALTER TABLE orders VALIDATE CONSTRAINT orders_status_not_null');

       // Step 3: now cheap, because the validated constraint already
       // proves no row is null.
       DB::statement('ALTER TABLE orders ALTER COLUMN status SET NOT NULL');

       // Step 4: the CHECK constraint is now redundant.
       DB::statement('ALTER TABLE orders DROP CONSTRAINT orders_status_not_null');
   }

   public function down(): void
   {
       DB::statement('ALTER TABLE orders ALTER COLUMN status DROP NOT NULL');
   }
};

Run steps 1–2 in one migration and steps 3–4 in a later one if the table is large enough that you want the validation to happen during a quiet period, separately from the final constraint change.

MySQL's lock modifier applies here too

The lock() modifier from Part 1 isn't index-specific — it applies to column and foreign key definitions as well, with the same four modes: none (concurrent reads and writes), shared (reads only), exclusive (nothing), and default (MySQL picks). If the requested lock mode is incompatible with the specific operation, MySQL raises an error rather than silently using a stricter lock.

$table->string('tracking_number')->nullable()->lock('none');

As with inplace() on indexes, this is explicit opt-in: MySQL won't downgrade an operation to fit your requested lock level, it'll just fail, which is what you want in a migration you're about to run against production.

Renaming and dropping columns: the deploy-ordering problem

This isn't a database locking problem — it's a rolling-deploy problem, and it catches teams who've already solved the locking issues above.

Dropping a column the application still queries doesn't break the database. It breaks whichever of your app's processes are still running old code that references the now-gone column, during the window between when the migration runs and when every server has picked up the new deploy.

The sequence that avoids this:

Deploy code that stops reading or writing the old column.
Wait until every old process has fully drained — confirm via your deploy tooling, not a guess.
Only then ship the migration that drops the column.

Renaming a column is the same problem twice: it's effectively a drop of the old name and an add of the new one from the point of view of any code still running the old version.

// Don't do this in one step on a live table:
Schema::table('users', function (Blueprint $table) {
   $table->renameColumn('full_name', 'display_name');
});

The safer sequence: add display_name as a new column, write to both columns from the application for one deploy cycle, backfill display_name from full_name, switch all reads to display_name, then drop full_name in a later migration once old code has drained.

Quick reference

Operation	Risk	Safe pattern
Add nullable column, no default	None	Run directly
Add column with constant default	None on Postgres 11+/modern MySQL	Run directly
Add column with volatile default (now())	Full table rewrite	Add column first, set default separately
Add NOT NULL column, no default	Full rewrite on MySQL < 8.0.12	Add nullable, backfill, then constrain
->change() type change	Full table rewrite, dropped modifiers	New column → backfill → cutover → drop old
SET NOT NULL on existing column	Full table scan under exclusive lock (Postgres)	NOT VALID check → VALIDATE → SET NOT NULL
Drop/rename column	Breaks old app processes mid-deploy	Stop referencing → drain → drop, in that order

Before you run it in production

Run php artisan migrate --pretend and read the generated SQL for every modifier you expect to still be there after a change(). Split any volatile default into "add column" then "set default" as two statements. For NOT NULL on an existing Postgres column, use the NOT VALID constraint path rather than a bare SET NOT NULL. Never drop or rename a column in the same deploy that stops using it — give old processes time to drain first.

Related reading: if you haven't locked down index creation yet, start with Part 1: Adding Indexes to Large Tables in Laravel Without Locking Them, which covers CREATE INDEX CONCURRENTLY and MySQL's ALGORITHM=INPLACE, LOCK=NONE in detail.

Originally published on DEV Talk.

🚨 Laravel developers: adding an index to a large production table isn't always harmless.

devTalk — Sun, 27 Sep 2026 16:49:52 +0000

A simple:

$table->index(...)

can lead to locking, slow queries, and application impact when the table has millions of rows.

I wrote about safer approaches to adding indexes without unnecessarily blocking your Laravel app.

👇 Read the guide:

Adding Indexes to Large Tables in Laravel Without Locking Them

Learn how to add indexes to large MySQL and PostgreSQL tables in Laravel without locking production — with working migration code and gotchas.

dev-talk.com

Stop repeating your where() clauses in Laravel 🔁

devTalk — Thu, 13 Aug 2026 13:06:14 +0000

If you've ever needed multiple aggregate queries (count, sum, avg) on the same filtered data, you've probably copy-pasted the same where() chain over and over.

The problem? Laravel's query builder is mutable. Once you run one query, chaining more methods onto it doesn't give you a "fresh" copy of your filters.

The fix: PHP's clone keyword.

$query = Event::where('status', 'active')
    ->where('created_at', '>=', now()->subDays(30));

$totalCount = (clone $query)->count();

$groupedCount = (clone $query)
    ->selectRaw('count(*) as count')
    ->groupBy('event')
    ->get();

Same filters, zero repetition, no leftover state messing up your results.

Small trick, but it keeps analytics/reporting code a lot cleaner.

Full write-up with more examples 👇
Read Article

🚀 Laravel 13.24 Added a Small Rule That Solves a Really Common API Headache

devTalk — Thu, 13 Aug 2026 02:50:24 +0000

Ever had a client send extra, unexpected keys inside a filter or settings array? A typo, stale frontend field, or someone poking at your validation?

Laravel finally has a clean, built-in way to lock this down: Rule::arrayKeys().

'filter' => Rule::arrayKeys([
'status',
'author',
'tag',
]),

Send anything outside status, author, or tag, and validation fails — with a message that actually tells you what went wrong (not just a vague "must be an array").

In the article I cover:
🔹 How array_keys differs from the old array:key1,key2 syntax (and why the old error messages were misleading)
🔹 Pairing it with required_array_keys() when some keys must be present
🔹 Using the :unexpected placeholder for genuinely helpful error responses
🔹 A full real-world example validating an API filter payload

No more writing custom Rule classes just to check array shapes.

Full writeup + code here: Link

What's your go-to approach for validating nested array payloads in Laravel? Curious if anyone's been doing this a different way.

Argon2 vs Bcrypt: The Modern Standard for Secure Passwords

devTalk — Tue, 11 Aug 2026 14:24:45 +0000

Password hashing is one of those "everyone knows it matters, nobody wants to research it at midnight" topics. This post breaks down Bcrypt vs Argon2 in plain English — no crypto degree required — and gives you a clear answer on which one to use in 2026, plus a zero-downtime migration path if you're still on Bcrypt.

Read full article

Preventing Password Reuse in Laravel 🔐

devTalk — Thu, 30 Jul 2026 16:16:08 +0000

Wrote up how I built laravel-password-history — a Composer package that stops users from recycling old passwords, using a polymorphic history table so it works with any Eloquent model, not just User.

Covers the validation rule, the auto-pruning logic, a scheduled cleanup command, and a service-provider bug I ran into (translations silently failing outside the console context).

📖 Full post: Article
📦 composer require devdasun/password-history
🔗 Repo

Feedback and PRs welcome, especially from anyone using non-standard auth setups.

MySQL WITH Clause & CTEs - A Complete Guide with Examples

devTalk — Sat, 06 Jun 2026 11:08:30 +0000

Stop Nesting Subqueries — Use CTEs Instead 🧠

Ever written a SQL query so deeply nested you couldn't
remember what the outer SELECT was even doing?

Yeah. We've all been there.

Common Table Expressions (CTEs) — introduced in MySQL 8.0
via the WITH keyword — are the clean, readable alternative
you've been looking for.

What you'll learn in this guide

🔹 What a CTE actually is (no fluff)
🔹 Basic WITH clause syntax
🔹 CTEs vs Subqueries — side by side
🔹 Chaining multiple CTEs in one query
🔹 WITH RECURSIVE for hierarchies & org charts
🔹 Real-world examples: running totals, deduplication, DELETE
🔹 Pitfalls to avoid (infinite loops, indexing, MySQL version)

The core idea in 10 seconds

WITH big_orders AS (
    SELECT order_id, customer_id, total_amount
    FROM   orders
    WHERE  total_amount > 500
)
SELECT c.customer_name, b.order_id, b.total_amount
FROM   big_orders b
JOIN   customers c ON c.customer_id = b.customer_id;

That's it. You named a query block big_orders and used it
like a table. No nested mess. No repeated logic.

Ready to level up your SQL?

👉 Read the full guide

─────────────────────────────
💬 Do you already use CTEs in your projects?
What's the most complex CTE you've written?
Share it below — let's learn from each other! 👇
─────────────────────────────

Redis Is Not Just a Cache — 8 Use Cases With Real Code

devTalk — Sun, 24 May 2026 08:56:59 +0000

Everyone learns Redis as a cache on day one.
Most developers never go further.

But here's the truth — the teams building at scale
use Redis for session storage, real-time leaderboards,
distributed locks, AI vector search, and a lot more.

In this post I break down 8 real Redis use cases
with actual commands and code so you can start
applying them today.

What's inside:

⚡ 8 production-grade Redis use cases explained clearly
💻 Real Redis commands for every use case
🤖 How Redis powers modern AI systems (Redis Iris)
📊 Quick reference table at the end

Whether you're a beginner just getting started or
a backend dev looking to level up — this one's for you.

Drop a ❤️ if you found it useful and comment
which use case surprised you the most 👇
READ ARTICLE

🔍 Struggling with slow search in your app?

devTalk — Sun, 17 May 2026 10:44:59 +0000

I just published a beginner-friendly guide on Elasticsearch —
the search engine powering GitHub, Netflix, and Uber.

Here's what you'll learn in 3 minutes:

✅ What Elasticsearch is (and when NOT to use it)
✅ Core concepts — Index, Document, Shard, Replica
✅ How to install it locally with Docker in 1 command
✅ Writing your first search query (with fuzzy/typo support!)
✅ Real-world use cases — e-commerce, logs, site search

💡 The biggest mistake beginners make?
Using Elasticsearch as their primary database. It's not.
Use it alongside PostgreSQL/MySQL — and watch your search fly.

👇 Full beginner guide here

Elasticsearch #BackendDevelopment #WebDevelopment

OpenSource #ELKStack #SearchEngine #Programming #DevCommunity

AWK vs MAWK: Differences, Performance & Real-World Examples

devTalk — Thu, 14 May 2026 11:35:10 +0000

TL;DR — There are two popular AWK implementations
on Linux and most developers only know one of them.

MAWK processes a 500MB file in 3.1 seconds.
GAWK takes 8.4 seconds for the same task.

Same syntax. No script changes needed.
Just a faster engine under the hood.

Quick decision rule I now follow:

→ Start with mawk for speed
→ Switch to gawk only if you need extensions
→ Your scripts stay portable either way

Read article

🔥 Laravel devs — stop using DB::enableQueryLog()

devTalk — Thu, 14 May 2026 11:31:25 +0000

I just published a quick but powerful tip that most
Laravel developers overlook completely.

Did you know Laravel has 6 built-in Eloquent query
debugging methods?

Most of us write this the hard way:

DB::enableQueryLog();
$users = User::where('active', 1)->get();
dd(DB::getQueryLog());

When you can just do this:

User::where('active', 1)
    ->orderBy('created_at', 'desc')
    ->ddRawSql();

One line. Full raw SQL. No setup. No package needed.

Here's the full toolkit:

Method	What it does
->dd()	Dump results and die
->dump()	Dump results, continue execution
->ddRawSql()	Full raw SQL with bindings, then die
->dumpRawSql()	Full raw SQL, continue execution
->toSql()	SQL string with ? placeholders
->getBindings()	Array of all binding values

I covered all 6 methods with real Artisan Tinker
examples in my latest article.

👉 Read it here

Drop a 🔥 if you didn't know about ->ddRawSql()!