Why the database should reject bad data
A Postgres CHECK constraint example is the simplest way to stop invalid data from entering your system. Instead of trusting application code to validate every input, you define the rules directly in the schema. If a value violates the rule, the database rejects the transaction immediately. This shifts the burden of correctness from the application layer to the storage layer. For a solo developer running multiple products, this reduction in cognitive load is significant. You do not have to remember to validate every field in every endpoint. The database enforces the invariant for you, regardless of which process is writing to it.
Partial indexes for specific states
Standard indexes cover all rows, which can be wasteful if only a fraction of your data is active at any given time. Partial indexes solve this by indexing only rows that meet a specific condition. In Pracandy’s stack, the single PostgreSQL 16 database serves both the Next.js app and Instalaz. Instalaz manages Instagram scheduling, where posts have states like drafted, scheduled, and posted. A unique constraint on the post ID is necessary, but a unique index on the scheduled timestamp is not, because only future posts need to be looked up for execution. By creating a partial index on rows where the status is scheduled, the database remains fast and the index size stays minimal. This is cheaper than maintaining a full index on a column that is mostly null or historical.
Constraints as a safety net
Application code changes. Databases persist. When you rely solely on JavaScript or TypeScript validation, a bug in one code path can corrupt the data for all other paths. A CHECK constraint is a hard boundary. For instance, an invoice generator like Invoiceful might have a field for discount percentage. The logic is simple: the percentage must be between 0 and 100. If the application layer fails to clamp this value, the database constraint prevents the write. The transaction fails, and the error is explicit. This is preferable to silent corruption, where a negative discount accidentally increases the total. The cost of writing the constraint is a single line of SQL. The cost of debugging a financial error caused by bad data is hours of time and potential user trust. For a free tool like Invoiceful, maintaining trust is critical, and database-level guarantees provide that stability without adding complexity to the frontend.
Practical implementation in a shared environment
In a setup where one database serves multiple services, constraints prevent cross-service pollution. The Next.js process handles PracandyFlix and walls.pracandy.com, while Instalaz runs as a separate Node process. Both write to the same PostgreSQL instance. If Instalaz introduces a bug that allows a negative ID, a CHECK constraint on the primary key ensures that invalid rows never enter the table. This is especially important when using systemd oneshot services for scheduled work. These timers trigger jobs that might run unattended. If a job fails mid-write, the database’s atomicity and constraints ensure that partial or invalid states do not persist. You do not need to monitor every write in real time. The database acts as a gatekeeper. For a small team or independent developer, this is a form of insurance. It is cheaper to write the constraint than to write tests that cover every possible edge case of bad input. The constraint is the test that never fails. It is always running, always correct, and requires no maintenance. By making invalid states impossible, you reduce the surface area for bugs. You spend less time writing defensive code in the application and more time building features. The database does the policing, so you can focus on the product. This approach applies to any system where data integrity is paramount. Whether it is a film publication or a wallpaper app, the principle remains the same: trust the schema, not just the code. The constraint is the final line of defense, and it is the most reliable one you have. See how this applies to content management at
PracandyFlix, where data consistency matters for publication schedules.