Vibe Coding Is Fast. Engineering Still Matters.
What AIQuickPrompt's database audit teaches us about Lovable, PostgreSQL, security, scalability and profitable growth
Quick answer: What should you audit in a vibe-coded app?
A vibe-coded app should be reviewed regularly for database growth, background jobs, log retention, memory pressure, connection pooling, slow queries, access control, backups, recovery, security and unit economics. A polished interface can hide an unhealthy backend. The safest approach is to ask the AI builder for a read-only audit, verify the findings in the underlying platform, and approve fixes one at a time.
The AIQuickPrompt finding in one sentence: 230 MB of a 245.5 MB database - approximately 93.7% - came from old cron-job run history, while real application data remained under 2 MB.
A working app is not automatically an engineered product
Vibe coding has changed who can build software. A founder can describe an idea, connect a database, add authentication, integrate payments and launch a useful application without spending months writing every component by hand. That is a genuine shift, and tools such as Lovable make the process feel remarkably direct.
But speed creates a new blind spot: when the interface works, it is easy to assume the system behind it is healthy. The buttons respond. Sign-in succeeds. Users can save data. Nothing looks broken. Meanwhile, a scheduled job may be writing thousands of unnecessary records, an access policy may be too broad, or an inexpensive pricing tier may be quietly losing money on every heavy user.
This is why responsible vibe coding needs a second habit alongside prompting features: prompting for audits. AI should not only help build the product. It should also help question the architecture, expose assumptions and tell the founder what needs human verification.
The AIQuickPrompt case: five users, 245.5 MB, and one hidden problem
AIQuickPrompt is a secure cloud prompt vault designed to help people save, organise, version, optimise and reuse prompts across AI models. It is also a useful example of what happens when a vibe-coded SaaS product is treated as real software rather than a disposable prototype.
During an internal capacity and profitability review, the application was still at an early stage: five registered users, 142 prompts, 180 prompt versions, 430 login events and 35 AI optimisation runs. On the surface, there was no reason to expect a storage problem.
Snapshot note: these values describe the database at the time of the audit. They should not be treated as permanent capacity limits or guaranteed future performance.
Operational history can become larger than the product data itself when background jobs have no retention policy.
The real database problem was not traffic
The largest table was not prompts, users, subscriptions or AI results. It was cron.job_run_details, the execution history created by an old email-queue job that had run every minute. A per-minute schedule can produce 1,440 executions every day before any additional retries or related records are counted.
This behaviour is consistent with the official Supabase guidance for pg_cron, which explains that historical pg_cron records are not cleaned automatically and can grow into a very large cron.job_run_details table unless they are pruned.
That distinction matters. If the team had assumed the database was growing because more people were using the product, the obvious response would have been to upgrade compute or storage. That would have increased cost without removing the cause. The database would simply have continued filling a larger container.
What should happen after finding unbounded cron history?
Confirm whether the scheduled job is still required and identify everything that depends on it.
Disable or unschedule the obsolete job before cleaning its historical output.
Preserve any records required for debugging, compliance or business reporting.
Delete unnecessary run history in a controlled and reversible maintenance plan.
Create a retention rule so operational logs expire automatically after an appropriate period.
Monitor table growth after cleanup to prove the problem is actually resolved.
Plan space reclamation separately. Deleting rows does not always make the operating-system file shrink immediately.
PostgreSQL explains that standard VACUUM generally makes deleted-row space reusable inside the table, while VACUUM FULL can return more space to the operating system but is slower and takes an exclusive lock. That is why cleanup should be reviewed as a maintenance operation, not pasted into production casually.
Why 65% memory at idle deserves attention - but not panic
The memory reading was the second signal that stood out. Sixty-five percent usage with only five registered users sounds alarming, but one snapshot cannot tell the whole story. PostgreSQL deliberately uses memory for caches and buffers, so "used" memory is not automatically wasted memory.
The useful questions are about behaviour over time: Is committed memory rising? Is the server swapping? Do specific queries cause spikes? Are long-lived connections accumulating? Does memory remain stable after traffic falls? A trend across several days is more informative than a single percentage taken in isolation.
The Supabase database reports documentation describes the relevant views for memory, CPU, disk I/O, database size, connections and query performance. Those signals should be correlated before deciding that a compute upgrade is necessary.
Healthy connection counts today do not prove scalability tomorrow
Six connections out of 60 and one pool client out of 200 were comfortable at the time of measurement. That is good news, but it is evidence about the current workload, not a promise about launch day.
An application that suddenly receives hundreds of simultaneous requests can exhaust database connections even when its daily user count looks modest. Serverless and edge functions are especially important because they can create many short-lived connections during traffic bursts.
Supabase recommends its transaction-mode pooler for workloads with many transient connections, including serverless and edge functions. See the official database connection guidance. Connection pooling, sensible per-function limits and properly closed connections are part of the architecture - not an upgrade to remember after an outage.
Capacity decisions should combine memory, connections, disk, I/O and latency rather than relying on one dashboard number.
Daily active users are not a database capacity unit
The original capacity scenarios suggested that the current Tiny instance could comfortably support roughly 300 to 500 daily active users after the log problem was fixed, with a resize becoming likely beyond about 1,000 daily active users. That is a useful planning model, but it remains a model.
One daily active user might open the product once and run five reads. Another might create hundreds of prompt versions, search continuously and trigger multiple AI optimisation workflows. The database feels queries, writes, connections, row sizes and execution time - not a marketing dashboard's daily-active-user number.
A defensible capacity claim requires a load test that models real behaviour and measures peak concurrent users, queries per session, p95 and p99 latency, error rates, connection saturation, CPU, memory, I/O and slow queries. Until then, capacity bands should be labelled as estimates rather than guarantees.
Append-only tables quietly become tomorrow's problem
The cron history was the immediate issue, but the same pattern can appear elsewhere. Login events, prompt versions, AI run history, webhook logs, audit trails and notification attempts all tend to grow in one direction: forward.
At five users, 430 login events and 180 prompt versions are tiny. At 10,000 users, "keep everything forever" becomes a cost, privacy and performance decision. Every append-only table should have an owner and an explicit answer to four questions:
Why are we retaining this record?
How long is it useful or legally required?
Can older detail be aggregated, anonymised or archived?
Which product feature or investigation would break if it were removed?
Security is part of database engineering, not a launch checkbox
Database health is not only about speed and storage. A tiny, fast database can still be unsafe if one user can read another user's rows, an Edge Function trusts a client-supplied user ID, or a service-role secret appears in browser code.
Lovable can run automated database and security checks, including reviews of Row Level Security policies. Its own security documentation is clear that these tools support development but do not replace a thorough security review. Lovable also recommends verifying RLS so users can access only the rows they are allowed to read or modify.
A sensible review should also use an established application-security framework such as the OWASP Top 10 to examine broken access control, injection, insecure design, authentication failures and other common risks outside the database dashboard.
AI can accelerate the review, but the founder must still verify evidence, approve changes and protect recovery options.
How Emmanuel Abou Chabke approaches vibe-coded software
AIQuickPrompt founder Emmanuel Abou Chabke does not treat vibe coding as permission to ignore engineering. He continually considers the engineering and security sides of the product: how the database behaves, how users are separated, how costs change with usage, what could fail during growth, and what must be backed up before a risky change.
AI is part of that process too. It is used not only to create features, but also to inspect architecture, question assumptions, model growth and produce structured audit plans. The important boundary is that potentially destructive changes are not accepted blindly. The AI reports first; evidence is verified; then changes are approved individually.
That philosophy also informs the wider AI website development work at Market Me Global: visual experience, performance, integrations, security, measurement and future scalability should be considered as one connected system.
How often should a Lovable app be audited?
There is no universal schedule, but recurring reviews prevent small defects from becoming expensive incidents. A practical cadence for a young SaaS product is:
Weekly during active building: security findings, failed jobs, error spikes and database growth.
Monthly after launch: largest tables, retention, memory trends, slow queries, connections and third-party costs.
Before every major release: migrations, RLS, authentication, payments, backup status and rollback steps.
Before a campaign or expected traffic spike: load assumptions, connection pooling, rate limits, caching and scale triggers.
Quarterly: architecture, unit economics, disaster recovery and whether the current plan still fits the product.
Lovable's own guidance recommends using Plan mode for audits so the product can be analysed before code changes are made. Its project-aware planning workflow can inspect files, database context and logs, then propose an editable plan. See the official guidance on how to build a real product with Lovable and its debugging audit prompts.
Copy-and-paste AI audit prompts for Lovable
Use these prompts in Plan mode. The repeated phrase "report only, make no changes" is intentional. A database audit and a database cleanup are different operations.
Prompt 1 - Complete database health and capacity audit
Act as a senior PostgreSQL database engineer, SaaS architect and capacity-planning specialist.Perform a read-only audit of this application and its connected database. Do not modify the database, delete records, change policies, create migrations or alter the application.
Evaluate:
1. Total database size and the size of every major table and index.
2. The percentage of storage used by actual user data, operational logs, cron history, authentication events, version history and temporary data.
3. The fastest-growing tables and their estimated monthly growth.
4. Every scheduled or background job, its frequency, purpose, failure rate and generated log volume.
5. Whether cron and operational logs have appropriate retention policies.
6. Current memory, CPU, disk, I/O and connection usage.
7. Direct connections versus pooled connections and the risk of connection exhaustion.
8. Slow, repeated, duplicated or unnecessarily expensive database queries.
9. Missing, unused or inefficient indexes.
10. Tables that continuously accumulate records and need retention, archival or aggregation rules.
11. Row Level Security coverage and whether users can access another user's private records.
12. Backup, migration and recovery readiness.
13. Capacity under 100, 500, 1,000, 5,000 and 10,000 daily active users, using explicit behavioural assumptions.
14. Which conclusions are measured facts and which are estimates requiring load testing.For every issue, report severity, evidence, likely cause, current impact, future impact, recommended solution, and whether the solution carries deletion, downtime or data-loss risk.Finish with a prioritised action plan, but make no changes until I approve each action individually.
Prompt 2 - RLS, authentication and access-control audit
Act as a senior application-security engineer with PostgreSQL and Supabase expertise.Perform a read-only security review.
Do not change policies, secrets, functions, tables or code.
Check every public and sensitive table for Row Level Security.
Test the intended permissions for anonymous users, signed-in users, record owners, team members and administrators. Identify policies that are missing, overly broad, contradictory or dependent on client-supplied IDs.
Review database functions, SECURITY DEFINER usage, storage bucket permissions, Edge Function authentication, service-role usage, exposed secrets, rate limits, input validation and sensitive information in logs or error responses.
Map findings to relevant OWASP risks.For each finding, show the evidence, affected role, plausible abuse case, severity, recommended fix and regression tests. Report only.
Ask for approval before changing anything.
Prompt 3 - Data retention and database bloat audit
Act as a PostgreSQL data-lifecycle engineer.
Inventory every append-only or rapidly growing table, including cron history, login events, prompt versions, AI runs, webhook logs, notifications and audit trails.
Measure current size, row count, growth rate, index size and the oldest/newest record.For each dataset, explain the product, security, legal and debugging reason for keeping it.
Recommend a retention period, archival or aggregation approach, and a safe deletion process. Identify jobs that continue producing data without business value.
Estimate storage after 3, 6 and 12 months under current usage and three growth scenarios.
Distinguish measured facts from assumptions. Include backup, rollback, VACUUM and locking considerations. Do not delete or alter anything.
Prompt 4 - SaaS profitability and unit-economics audit
Act as a SaaS finance engineer and AI-infrastructure cost analyst.
Build a transparent unit-economics model for every free, monthly, yearly and top-up product.
Include payment-processing fees, database and hosting costs, storage, bandwidth, authentication, email, third-party APIs, AI cost per model/run, refunds, taxes where applicable and a support allowance.
Model light, typical, heavy and abusive users.
Calculate contribution margin per user, break-even paying users, gross margin by plan and the effect of growth at 100, 1,000 and 10,000 users.Flag plans where included usage can cost more than net revenue.
Recommend limits, fair-use protections, pricing changes or model routing.
Label every number as measured, contractually known or assumed. Do not change pricing or production configuration.
Prompt 5 - Growth-readiness and load-test plan
Act as a performance engineer preparing this app for a public campaign.Review the frontend, API, Edge Functions and database together.
Create realistic user journeys and estimate the reads, writes, AI calls, uploads and connections produced by each journey.
Design a staged load test for 10, 50, 100, 250 and 500 peak concurrent users.
Define pass/fail thresholds for p50, p95 and p99 latency, error rate, CPU, memory, I/O, database connections and pool saturation.Identify which reads can be cached, which queries need indexes, which actions require rate limits and which services need queues.
Recommend objective upgrade triggers rather than a vague daily-active-user limit.
Do not run destructive tests against production and do not make changes.
Prompt 6 - Backup, migration and recovery drill
Act as a database reliability engineer.
Perform a read-only recovery-readiness assessment.
Identify the available backups, retention period, restore process, Recovery Point Objective and Recovery Time Objective.
Verify whether storage objects, authentication configuration, secrets, Edge Functions and database migrations are covered or require separate recovery steps.
Review migration ordering and rollback options.
Propose a non-production restore drill with validation checks for record counts, authentication, file access, payments and critical user journeys.
List every step that could overwrite data, cause downtime or invalidate sessions.
Do not initiate a backup, restore, migration or configuration change without approval.
What these prompts can and cannot do
A detailed prompt improves the quality of the review, but it does not magically create missing telemetry. If the system has no historical metrics, the AI cannot honestly calculate a growth trend. If there has never been a restore drill, it cannot prove that recovery works. If production traffic has never been load-tested, it cannot guarantee a user limit.
The best AI audit clearly labels three categories: measured evidence, reasonable inference and untested assumption. That separation is more valuable than a confident answer built on invented precision.
A practical checklist before your vibe-coded app grows
Identify the largest tables and indexes, then explain why each one is large.
Find every scheduled job and confirm that it still has a purpose.
Set retention rules for logs, events, versions and job history.
Trend memory, CPU, I/O, disk and connections instead of reading one snapshot.
Use connection pooling appropriate to serverless or long-running workloads.
Review RLS, authentication, storage policies, secrets and Edge Functions.
Test backups by restoring outside production.
Load-test real user journeys before campaigns or major launches.
Model profitability for light, typical, heavy and abusive users.
Require audit reports before changes and approve risky actions individually.
Frequently asked questions
Is vibe coding safe for production software?
It can be, provided the product receives the same engineering controls as conventionally coded software: access control, testing, monitoring, backups, dependency review, incident planning and human approval for risky changes. The method used to generate code does not remove production responsibility.
Can Lovable audit my database?
Lovable can inspect connected project context, analyse database and log information, and run automated security checks. Those checks are useful, but Lovable states that they are not a complete security audit. Important findings should be verified in the underlying database and tested against real user roles.
Why did cron.job_run_details become so large?
pg_cron stores execution history, and historical records are not automatically removed. A job that runs every minute can generate a continuous stream of records even when user traffic is low. Without retention, the table can grow indefinitely.
Does deleting cron history immediately shrink PostgreSQL disk usage?
Not necessarily. Standard VACUUM generally marks space for reuse inside the table. Returning more space to the operating system can require operations such as VACUUM FULL, which is slower and takes an exclusive lock. Plan the maintenance window and recovery path first.
How many users can a Tiny database support?
There is no reliable answer based only on registered users or daily active users. Capacity depends on peak concurrency, queries per journey, write volume, row size, indexes, pooling, caching and query latency. Use a representative load test and define upgrade triggers from measured resource pressure.
How often should I ask Lovable to review the database?
During active development, review security findings, job failures and growth weekly. Perform a broader database and cost review monthly, and repeat recovery and load-readiness checks before major releases or traffic campaigns.
Should AI be allowed to clean the database automatically?
Not by default. Ask for a read-only report first. Confirm dependencies, backups, retention obligations, locking and rollback. Then approve narrowly scoped changes one at a time and verify the result.
Final takeaway: vibe coding needs an engineering rhythm
The most important lesson from AIQuickPrompt is not that a cron table became large. It is that the issue was discovered before growth made it expensive. Five users did not create the risk. An old automated process with no retention policy did.
That is the engineering mindset a vibe-coded product needs: look beyond the interface, measure what is happening, challenge neat capacity estimates, protect user boundaries, test recovery and connect product pricing to real infrastructure costs.
Vibe coding can remain fast. It simply becomes stronger when building and auditing are treated as two halves of the same process.
Explore AIQuickPrompt to save, version and improve the prompts behind your AI workflows. For a related guide, read Why AIQuickPrompt Is the Perfect Tool for Vibe Coders. Businesses planning a production-ready website or AI application can also review Market Me Global's custom website development services or begin with the free Google and ChatGPT visibility audit.
Sources and recommended backlinks
AIQuickPrompt - secure cloud prompt vault
Lovable - Debug and improve your app
Lovable - How to build a real product
Supabase - pg_cron upgrade guidance
Supabase - Database monitoring reports
Supabase - Connect to Postgres and use pooling