Month: March 2026

You push your Laravel project to production. Everything works fine for weeks. Then suddenly, performance slows down, queries start lagging and debugging turns into a detective job.

After hours of digging, you discover the real issues:

• A foreign key column without an index
• A table with 35 columns
• Prices stored as integers
• A VARCHAR (255) column that never needed to be that wide
• Tables missing timestamps

None of these are dramatic bugs. But together, they quietly damage database performance, maintainability and scalability.

That’s exactly the kind of problem DBStan was built to solve.

Instead of discovering database issues months later, DBStan analyzes your schema in minutes and flags structural, performance and architectural problems before they become production incidents.

What Is DBStan?

DBStan is a Laravel database schema analyzer that performs a comprehensive read-only inspection of your MySQL database structure. It detects design issues, missing indexes, performance risks and schema inconsistencies automatically.

The package is developed by IT Path Solutions and designed for Laravel developers, database administrators and DevOps teams who want better visibility into their database structure.

Think of it like PHPStan for your database schema.

Instead of analyzing PHP code, it analyzes how your database tables, indexes and relationships are structured.

The tool runs a full Laravel database architecture analysis. It produces a categorized report to help developers improve schema quality.

Technical Requirements

Component	Requirement
PHP	^8.1 | ^8.2 | ^8.3 | ^8.4
Laravel	^9.0 | ^10.0 | ^11.0 | ^12.0
Database	MySQL
Package Manager	Composer
Frontend Dashboard	Bootstrap 5.3.2 (CDN), Bootstrap Icons
License	MIT

These requirements allow DBStan to work across modern Laravel projects without additional dependencies.

The Real Problem

Common Database Mistakes Developers Make

Even experienced developers unintentionally introduce database design issues during development.

Laravel migrations make database creation easy, but that convenience sometimes hides structural problems.

Here are a few common mistakes DBStan catches automatically.

Missing Indexes on Foreign Keys

A column like user_id without an index might work fine initially. But once your application grows, query performance starts to degrade.

Prices Stored as INT Instead of DECIMAL

Storing monetary values as integers often causes rounding problems and inconsistent calculations.

Tables Without Timestamps

Laravel relies heavily on created_at and updated_at. Missing timestamps reduces traceability and data tracking.

Overusing VARCHAR (255)

Many developers default to VARCHAR (255) for almost everything. In reality, most fields don’t need that much space.

Weak Foreign Key Rules

Foreign keys without cascading rules can leave orphaned data after deletions.

Missing Soft Deletes

Critical tables without deleted_at make recovery impossible. Accidentally removed data cannot be restored.

These kinds of schema design issues accumulate quietly over time.

A Laravel database analysis tool like DBStan scans your entire schema and surfaces these risks instantly.

How DBStan works Internally

DBStan performs a read-only inspection of the database by querying MySQL metadata tables and Laravel’s database connection layer.

Internally, the analyzer collects schema information using:

• information_schema.tables
• information_schema.columns
• information_schema.statistics
• SHOW INDEX
• SHOW CREATE TABLE

This metadata is then passed through a set of modular rule checks that analyze:

• column types
• index coverage
• table width
• nullable ratios
• foreign key relationships
• storage size

Each rule produces a Finding object containing:

• severity
• description
• affected table
• suggested improvement

These findings are aggregated and displayed in two places:

This rule-based architecture makes DBStan easy to extend with custom checks.

How DBStan Helps

Four Categories of Database Checks

DBStan performs 26 automated checks grouped into four categories.

Instead of presenting raw database metadata, it translates technical issues into clear findings developers can act on.

1.Structure Checks

Is your table design clean?

Structure checks focus on table design, column types and schema conventions.

Examples include:

Check Name	What It Detects	Severity
Too Many Columns	Tables exceeding max_columns (default 25)	WARNING
Wide Varchar Columns	VARCHAR columns wider than 190	WARNING
Missing Timestamps	Tables missing created_at / updated_at	BEST PRACTICE
Missing Soft Deletes	Tables missing deleted_at column	BEST PRACTICE
Nullable Column Overuse	Columns marked nullable without justification	NULLABLE
Large TEXT Columns	Columns using TEXT type	PERF RISK
Data Type Appropriateness	“price” columns stored as INT not DECIMAL	DATA TYPE
Enum Overuse	Tables with >2 ENUM columns or ENUMs with >5 values	ENUM OVERUSE
Boolean Overuse	Tables with >4 boolean columns	ARCH WARNING
Pivot Table Structure	Pivot tables with unnecessary id or timestamps	PIVOT
Repeated Common Fields	Common field names across tables	REPEATED FIELD
Mixed Domain Columns	VARCHAR columns named “data”, “info”, “details”	DOMAIN MIX

These checks help enforce Laravel schema best practices, ensuring tables remain readable and maintainable.

2. Integrity Checks

Is your data safe?

Integrity checks verify relationships, constraints and data consistency.

Examples include:

Check	What It Detects	Severity
Foreign Key Naming	Columns like userid instead of user_id	NAMING
Duplicate Rows Risk	Tables without primary or unique keys	DATA INTEGRITY
Orphan Risk	_id columns without foreign key constraints	ORPHAN / HIGH RISK
Cascading Rules	Foreign keys using restrictive delete rules	INTEGRITY
Unique Constraint Violations	Duplicate values in email or slug columns	UNIQUE VIOLATION

These issues often go unnoticed until real data inconsistencies appear.

A Laravel database schema analyzer like DBStan identifies them early.

3. Performance Checks

Will your database scale?

Performance issues rarely show up during development. They appear when real traffic hits your application.

DBStan includes several checks focused on database performance.

Examples include:

Check	What It Detects	Severity
Missing Foreign Key Indexes	_id columns without indexes	ERROR
Large Table Size	Tables exceeding storage thresholds	SIZE ALERT
High NULL Ratio	Columns filled mostly with NULL values	DATA QUALITY
Status Column Indexing	Unindexed state or status columns	PERF
Log Table Indexing	Log tables missing indexes on created_at or user_id	PERFORMANCE
Unbounded Growth Risk	High-growth tables lacking indexing	GROWTH RISK

These checks form the core of DBStan’s Laravel database performance analysis, helping developers identify scalability risks early.

4. Architecture Checks

Are you designing for the long term?

Beyond structural and performance checks, DBStan also evaluates architectural patterns.

Examples include:

Check	What It Detects	Severity
JSON Column Overuse	Tables with too many JSON columns	WARNING
Audit Trail Check	Missing created_by, deleted_by or updated_by fields	AUDIT
Polymorphic Relation Overuse	Excessive polymorphic relationships	ARCH RISK

These checks help teams evaluate long-term maintainability and overall schema architecture.

Installation and Quick Start

Getting started with DBStan takes less than two minutes.

Step 1 – Install the Package

composer require itpathsolutions/dbstan

Step 2 – Run the Analysis

php artisan dbstan:analyze

DBStan scans your entire database schema and runs all enabled checks automatically.

Step 3 – Open the Web Dashboard

http://localhost:8000/dbstan

The dashboard provides a visual interface for exploring issues found during analysis.

What the Output looks like

DBStan prints a list of findings grouped by severity. This happens when you run the CLI command.

A typical report might look like this:

⚠️ WARNING – Table `orders` has 32 columns (exceeds limit of 25)

❌ ERROR – Column `user_id` in `posts` has no index

✅ BEST PRACTICE – Table `users` is missing `deleted_at`

All are categorized with a severity level. This helps developers know what to fix first.

Severity types include:

Label	Meaning	Action
ERROR	Critical schema problem	Fix immediately
WARNING	Design concern or anti-pattern	Review and address
BEST PRACTICE	Improvement recommendation	Consider adopting
PERFORMANCE	Potential performance bottleneck	Add index or optimize
HIGH RISK	Data integrity at serious risk	Fix immediately
SIZE ALERT	Table storage exceeds threshold	Archive/partition/optimize
NAMING	Column naming convention violation	Rename column
AUDIT	Missing audit trail columns	Add audit columns

This structured output turns raw schema inspection into actionable insight.

Web Dashboard for Visual Analysis

While the CLI command is useful for quick checks, DBStan also includes a web dashboard.

The dashboard is available only in local or staging environments, keeping production environments secure.

The interface includes:

• A left sidebar with category tabs
• Issue counts for each category
• Collapsible cards showing detailed findings
• A summary of schema problems

This makes DBStan useful not only for developers but also for teams reviewing database architecture together.

Securing the Dashboard

Because DBStan exposes schema information, the dashboard is intentionally restricted.

By default:

• The /dbstan route is disabled in production
• It works only in local or staging environments

For staging environments, you can add additional protection such as:

• authentication middleware
• IP whitelisting
• admin-only access

These safeguards prevent schema information from being exposed publicly.

Configurable for your Project

Every Laravel project has different database needs.

DBStan includes a configuration file that allows developers to customize thresholds and checks.

You can publish the configuration file using:

php artisan vendor:publish –tag=dbstan-config

Configuration options include:

Key	Type	Default	Description
max_columns	int	25	Tables with more columns trigger warning
max_varchar_length	int	190	VARCHAR columns wider trigger warning
max_json_columns	int	2	Tables with more JSON columns trigger warning
large_table_mb	int	100	Tables larger (MB) trigger size alert
null_ratio_threshold	float	0.5	Columns with NULL > ratio trigger warning
enabled_checks	array	all four	Remove a category to skip its checks

This flexibility makes DBStan a practical Laravel database optimization tool that can adapt to different application architectures.

Who should use DBStan?

DBStan is useful for more than just Laravel developers.

Solo Developers

Run it before deployment to catch schema issues early.

Development Teams

Use it during code reviews to enforce database standards.

DevOps Engineers

Integrate it into CI pipelines as part of automated quality checks.

Database Administrators

Audit existing Laravel databases for structural problems.

Open-Source Maintainers

Ensure consistent database architecture across contributors.

What DBStan does NOT do

To keep the tool safe and predictable, DBStan intentionally avoids certain actions.

It:

• does not modify your database
• supports MySQL only
• keeps the web dashboard disabled in production
• does not auto-fix issues

Instead, it focuses on reporting and analysis so developers remain in full control.

What’s Beneath the Code?

Your application logic can change. Your UI can evolve.

But your database schema becomes the foundation everything depends on.

Once bad design decisions enter production, fixing them becomes expensive.

DBStan helps teams run a quick Laravel database architecture analysis, identify schema problems early and maintain a healthier database structure over time.

If you’re serious about database quality, run your first analysis today.

You might be surprised by what your schema reveals.

GitHub: itpathsolutions/dbstan
Install: composer require itpathsolutions/dbstan

Your Laravel database deserves the same level of analysis as your code.

Run your first analysis in minutes!

Frequently Asked Questions

Does DBStan modify my database?

No. DBStan is completely read-only. It only reads schema metadata and row counts from your database to analyze structure, relationships and indexes. It never inserts, updates or deletes any data.

Is DBStan safe to run in production?

Yes. The Artisan command can safely run in any environment, including production.

However, it’s recommended to avoid running it during peak traffic because some checks query information_schema and table statistics, which may add minor overhead.

Also, the web dashboard is automatically disabled in production to prevent exposing database structure publicly.

Which databases are supported?

At the moment, DBStan supports MySQL only.

The analyzer relies on MySQL-specific commands such as:

• SHOW TABLES
• SHOW COLUMNS
• SHOW INDEX
• information_schema

Support for other databases may come in future versions.

Can I create my own custom checks?

Yes. DBStan is designed to be extendable.

You can create custom checks by adding a class inside the src/Checks/ directory and:

1. Extending BaseCheck
2. Implementing the required methods:
   a. run()
   b. name()
   c. category()

DBStan automatically discovers new check classes, so you don’t need to manually register them.

Can specific checks or categories be disabled?

Yes. DBStan allows you to control which checks run.

Open the configuration file:

config/dbstan.php

Inside the enabled_checks array, you can include only the categories you want to run. You might choose structure or performance or integrity or architecture.

This makes it easy to tailor the analysis according to the needs your project.

Why am I seeing issues on Laravel’s default tables?

DBStan scans every table in the database, including Laravel’s default tables like jobs, failed_jobs or password_resets.

Some checks may flag these tables for things like: missing timestamps, missing soft deletes, column structure warnings.

These warnings are meant for information. Use your own judgment before acting on them.

The /dbstan dashboard is not loading. What should I check?

If the dashboard route is not loading, check the following:

1. Make sure your .env file has
   APP_ENV=local or APP_ENV=staging
2. Clear cached configuration and routes
   php artisan config:clear
   php artisan route:clear
3. Confirm the package is installed
   composer show itpathsolutions/dbstan
   Once these are verified, the dashboard should load at:
   http://localhost:8000/dbstan

A complete Laravel application security blueprint covering authentication hardening, input validation, dependency auditing, CSP headers, secrets management, and CI/CD security scanning.

Laravel ships with strong security defaults. CSRF protection is built in. Password hashing uses bcrypt by default. Mass-assignment protection requires explicit fillable declarations. Most common web vulnerabilities are addressed out of the box if you use the framework as intended.

Enterprise applications need more than defaults. They need a layered security architecture that covers authentication hardening, input validation at every layer, dependency vulnerability management, secrets management separate from code, security headers, and automated security scanning in CI/CD. This article gives you that blueprint.

---

The Security Layers

A Quick Answer

A complete security blueprint for enterprise Laravel covers six layers: Authentication hardening (MFA, session management, Sanctum token rotation) Input validation at every layer (Form Requests, type declarations, parameterised queries) Dependency vulnerability management (composer audit, automated scanning) Secrets management (environment-based, rotated, never in code) Security response headers (CSP, HSTS, X-Frame-Options) Automated static analysis (Enlightn, Psalm, PHPStan) in CI/CD.

Layer 1: Authentication Hardening

Multi-Factor Authentication

Password-only authentication is insufficient for enterprise applications. Implement TOTP-based MFA using the pragmarx/google2fa-laravel package or the Spatie/laravel-google-authenticator equivalent. For higher assurance, WebAuthn hardware key support is available via the asbiin/laravel-webauthn package. Enforce MFA for administrative roles at minimum; consider enforcement for all users in high-risk applications.

Session Security

Configure session settings in config/session.php for production: encrypt=true (encrypts session payload at rest in Redis), secure=true (HTTPS-only cookies), same_site=strict (prevents CSRF via cross-site requests), http_only=true (prevents JavaScript access to session cookies). Set an appropriate session lifetime — not indefinite. Implement session invalidation on password change.

Account Lockout Policy

Laravel’s built-in RateLimiter can implement account lockout. After five failed login attempts within ten minutes from a specific IP plus email combination, lock the account temporarily. Log the lockout event. Alert the account owner via email. This prevents credential stuffing attacks without creating excessive friction for legitimate users.

Sanctum Token Security

For API authentication with Sanctum: implement token rotation (new token issued on each authentication, old token revoked), set token expiry via the expiration configuration, use token abilities to scope permissions per token, and log all token creation and revocation events.

Layer 2: Input Validation at Every Layer

HTTP Layer: Form Requests

Create a Form Request class for every controller method that accepts input. Never use $request->all() or $request->input() without explicit validation rules. Form Requests enforce validation before the controller method is called and provide a clean, testable location for validation logic. Validate strictly — use ‘required’, ‘string’, ‘max:255′, ’email:dns’ rather than permissive rules.

Application Layer: Typed Parameters

Service class methods should use typed parameters (string, int, float, bool, or Value Objects) rather than accepting raw arrays or mixed types. PHP 8.1’s readonly properties and enums provide additional type safety at the service layer. Typed parameters prevent class of injection attacks that bypass HTTP-layer validation.

Database Layer: Parameterised Queries Only

Eloquent’s query builder uses parameterised queries by default — SQL injection is prevented if you use the ORM correctly. The danger points are: raw query methods (DB::statement(), DB::select() with string interpolation), whereRaw() and orderByRaw() with user-controlled values, and direct use of $request->input() in query strings. Never interpolate user input into raw SQL expressions.

Layer 3: Dependency Vulnerability Management

Third-party packages are a significant attack surface. The 2021 Log4Shell vulnerability and numerous npm/Composer package vulnerabilities demonstrate that supply chain attacks are real and impactful.

composer audit

Run composer audit as part of every CI/CD pipeline. It queries the Packagist security advisories database and reports known vulnerabilities in installed packages. A build with known high-severity vulnerabilities should fail. Add composer audit –no-dev to your deployment pipeline — it checks production dependencies only.

Automated Dependency Updates

Use Dependabot or Renovate to automate minor and patch version updates for Composer packages. Configure review requirements for major version updates. Keeping dependencies current reduces the vulnerability window between package vulnerability disclosure and application update.

Layer 4: Secrets Management

Secrets — API keys, database credentials, encryption keys, third-party service tokens — must never live in code or version control. The .env file is a local development convention; it is not a secrets management system.

Production Secrets Management

For AWS deployments: AWS Secrets Manager with IAM role-based access. Secrets are fetched at application bootstrap and injected as environment variables. Rotation policies rotate credentials automatically without code changes. For non-AWS deployments: HashiCorp Vault provides equivalent functionality. For Kubernetes deployments: Kubernetes Secrets with sealed-secrets for encrypted storage in version control.

Secret Rotation Policy

Set rotation periods for all secrets: database passwords quarterly, API keys on any team member departure, encryption keys annually with key derivation function to transition encrypted data. Document the rotation procedure and test it — a rotation policy that has never been executed in testing will fail when executed under incident pressure.

Layer 5: Security Response Headers

Content Security Policy (CSP)

CSP is the most effective defence against Cross-Site Scripting (XSS) attacks that bypass CSRF protection. A CSP header tells the browser which sources of scripts, styles, images, and other content are permitted to load on your pages. Inline scripts from attacker-injected content are blocked even if the injection bypasses server-side sanitisation.

Spatie’s laravel-csp package provides a clean interface for building and testing CSP headers in Laravel. Start with a report-only CSP (violations are reported but not blocked) to identify legitimate inline scripts before enforcing. Enforce with strict-dynamic and nonce-based script loading.

HSTS, X-Frame-Options, and Referrer-Policy

Add a security headers middleware to your HTTP kernel: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload (HTTPS enforcement). X-Frame-Options: DENY (clickjacking prevention). X-Content-Type-Options: nosniff (MIME-type sniffing prevention). Referrer-Policy: strict-origin-when-cross-origin (referrer privacy). These four headers together close the most common browser-level attack vectors.

Laravel Security Audit We run a scored security audit on your existing or planned Laravel application. Request Security Audit

Layer 6: Automated Static Analysis

Enlightn

Enlightn is a Laravel-specific security and code quality analyser. Run php artisan enlightn to get a scored report covering: exposed debug information, CSRF configuration, CORS misconfiguration, SQL injection risk patterns, mass assignment vulnerabilities, and insecure session configuration. Integrate into CI/CD with a minimum score threshold.

PHPStan and Psalm

PHPStan and Psalm perform static type analysis, catching type errors, undefined method calls, and logic errors before they reach production. At level 6 or above, PHPStan catches the majority of type-related bugs that would otherwise manifest as runtime errors. Add to CI/CD as a blocking check.

Conclusion

Security is a layered discipline. No single control is sufficient, and the most sophisticated attack surface protections are irrelevant if MFA is not enforced or if secrets live in the codebase. Work through the six layers in order – authentication hardening and input validation deliver the most impact per hour of effort. Our Laravel development services include security architecture review and Enlightn-scored security audits on all enterprise engagements.

FAQ’s