When developers first learn backend development, they're often taught to validate incoming data in the application layer. Whether it's checking for empty fields, validating email addresses, or ensuring values fall within an acceptable range, application-level validation is essential.
But here's a question every backend engineer should ask:
What happens if invalid data reaches your database anyway?
The answer is simple: your database should reject it.
This is why experienced backend engineers don't rely solely on application validation. They also enforce rules directly in PostgreSQL using constraints. PostgreSQL itself is designed to support this approach through built-in constraint types such as NOT NULL, CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY.
The Application Layer Isn't the Source of Truth
Your Express.js, NestJS, Django, or Spring Boot application isn't the only thing that can write to your database.
Data can come from many places:
- Another backend service
- A background worker
- A scheduled job
- A migration script
- A database administration tool
- A third-party integration
- Future applications that share the same database
If your validation only exists in one application, every other system must remember to implement exactly the same rules.
Eventually, one of them won't.
That's how inconsistent data begins to appear.
PostgreSQL Is Your Last Line of Defense
Think of your application as the security guard at the front door.
Think of PostgreSQL as the vault.
Even if someone bypasses the security guard, they still shouldn't be able to access the vault without meeting the requirements.
Database constraints serve exactly this purpose.
They guarantee that invalid data simply cannot be stored.
It doesn't matter whether the request comes from your Express API, an internal microservice, a migration script, or someone running SQL manually.
The rules are always enforced because they're defined where the data actually lives.
Constraints Represent Facts About Your Data
Certain rules should never be optional because they're fundamental characteristics of your data.
For example:
- A user's email should be unique.
- A product price should never be negative.
- Every order should belong to an existing customer.
- A username shouldn't be missing.
- Every table should have a primary key.
These aren't application-specific decisions.
They're truths about the data itself.
That's exactly what PostgreSQL constraints are designed to enforce.
Application Validation and Database Constraints Have Different Jobs
Some developers think that adding constraints means they no longer need validation in their backend.
That's not true.
The two solve different problems.
The application layer is responsible for user experience.
For example:
- Showing friendly validation messages
- Validating email formats
- Enforcing password complexity
- Sanitizing input
- Returning meaningful HTTP status codes
The database layer is responsible for protecting the integrity of stored data.
For example:
- Preventing duplicate emails
- Preventing orphaned records
- Rejecting invalid numeric values
- Ensuring required fields are always present
Instead of replacing one another, they work together.
A Real-World Scenario
Imagine you're building an inventory management system.
Your Express.js API validates that product prices must be greater than or equal to zero.
Everything works perfectly.
Six months later, another developer writes an import script that inserts thousands of products directly into PostgreSQL.
They forget to validate prices.
Now your database contains products priced at -₱500.
Your reports become inaccurate.
Discount calculations break.
Profit analytics become meaningless.
Now imagine the table had a simple database constraint:
CHECK (price >= 0)
The import would fail immediately.
The bad data would never reach production.
One simple constraint prevents an entire class of bugs.
Multiple Applications Mean Multiple Risks
Modern systems rarely have a single application interacting with the database.
A production database might receive writes from:
- REST APIs
- Mobile applications
- Background workers
- Queue consumers
- ETL jobs
- Scheduled tasks
- Database migration scripts
- Internal administration tools
Should every one of these independently implement the exact same validation rules?
They can.
But they shouldn't have to.
The database should guarantee consistency regardless of who writes the data.
Defense in Depth
Experienced engineers rarely depend on a single layer of protection.
Security uses multiple layers.
Networking uses multiple layers.
Authentication uses multiple layers.
Backups use multiple layers.
Data validation should follow the same principle.
A robust system validates data:
- On the client, to improve user experience.
- In the application, to enforce business rules.
- In PostgreSQL, to guarantee data integrity.
Each layer catches failures the others might miss.
Constraints Improve Team Development
As projects grow, more developers begin interacting with the database.
Without constraints, every engineer has to remember every business rule.
With constraints, PostgreSQL becomes self-documenting.
The schema immediately communicates:
- Which fields are required
- Which values must be unique
- Which records depend on others
- Which values are considered valid
Instead of relying on tribal knowledge or documentation, the database enforces these rules automatically.
Not Every Rule Belongs in PostgreSQL
It's equally important to understand what doesn't belong in the database.
Examples include:
- Password confirmation
- CAPTCHA verification
- Email verification
- Authentication
- Authorization
- Rate limiting
- Payment workflows
- Multi-step approval processes
These are application concerns because they involve user behavior and business processes.
Database constraints should focus on protecting the validity of stored data.
Rule of thumb: If violating the rule would make the data invalid no matter how it was inserted, PostgreSQL should enforce it.
Final Thoughts
One of the best habits a backend engineer can develop is treating the database as the ultimate source of truth.
Application validation improves user experience.
Database constraints protect your data.
Both are necessary.
Great backend engineers don't ask: "Should I validate in the application or the database?"
They ask: "How many layers can I use to ensure bad data never becomes good data?"
By enforcing constraints directly in PostgreSQL, you're building systems that are more reliable, easier to maintain, and resilient against future changes—regardless of how many applications, developers, or services interact with your database.
References
- PostgreSQL Documentation – Constraints (https://www.postgresql.org/docs/current/ddl-constraints.html)
- PostgreSQL Documentation – Data Definition (https://www.postgresql.org/docs/current/ddl.html)
- PostgreSQL Documentation – CREATE TABLE (https://www.postgresql.org/docs/current/sql-createtable.html)
- Martin Fowler – Validation (https://martinfowler.com/articles/replaceThrowWithNotification.html)